Comments 69
Надо для Python подумать. Спасибо) как раз надо подключать датчик.
Никогда в плотную не работал с девайсами и особо не знаю всех проблем. Есть пара вопросов:
1) Почему бы не сделать микросервис который бы тупо буферизировал весь хлам из uart\com, или сохранял его в бд и т.д. Дальше отдавал бы все это по tcp\udp по некоему общему интерфейсу. Дальше уже эти данные переваривать в кому что удобно, хочешь выводи в консоль, хочешь нарисуй GUI и т.д.
2) В чем именно проблема переносимости?
PS не кидайтесь помидорами, я правда не писал и не делал ничего с такими самопальными игрушками. Хотя с удовольствием бы что то такое состряпал со стороны софта.
1) Почему бы не сделать микросервис который бы тупо буферизировал весь хлам из uart\com, или сохранял его в бд и т.д. Дальше отдавал бы все это по tcp\udp по некоему общему интерфейсу. Дальше уже эти данные переваривать в кому что удобно, хочешь выводи в консоль, хочешь нарисуй GUI и т.д.
2) В чем именно проблема переносимости?
PS не кидайтесь помидорами, я правда не писал и не делал ничего с такими самопальными игрушками. Хотя с удовольствием бы что то такое состряпал со стороны софта.
Вопрос где хранить БД? У контроллера может быть 256 БАЙТ ОЗУ. И всё остальное жёстко зашито. В 256 байтах (даже в килобайте) сложно развернутся.
UPD Не совсем понял вопроса сразу. Тем не менее — это всё лишние сложности, которые во время отладки не нужны.
UPD Не совсем понял вопроса сразу. Тем не менее — это всё лишние сложности, которые во время отладки не нужны.
1) уже. тысячи их. Даже девайсы специальные есть.
2) Памяти не очень много. Хотя я думаю что базовые библиотеки уже есть.
2) Памяти не очень много. Хотя я думаю что базовые библиотеки уже есть.
PS не кидайтесь помидорами, я правда не писал и не делал ничего с такими самопальными игрушками. Хотя с удовольствием бы что то такое состряпал со стороны софта.Да легко! Ваше творение будет только с МЕГА версией на 8KiB памяти работать, или в минимальной версии с 1KiB памяти вы тоже микросервисы разведёте? Учтите что этой же памятью и все остальные подпрограммы должны, как бы, пользоваться.
Почему бы не сделать микросервис который бы тупо буферизировал весь хлам из uart\com, или сохранял его в бд и т.д.Потому что если вы это хотите разводить не на самой железяке, то вы автоматически теряете возможность к ней подконнектится любым терминалом и, соответственно, делаете работу с железкой резко менее удобной, а если на ней, то… ну попробуйте…
Говоря про микросервис я имел ввиду что некая железка подключается к тому же обычному ПК по обычному UART или RS232. На этом ПК стоит микросервис который тупо дампит себе абсолютно все что приходит, хранит\буферизирует и просто ждет кто все это запросит уже на обычном tcp\udp. Дальше с этими данными уже делай что хочешь, хочешь напиши на java красивую вебморду которая будет запускаться на любой OS, хочешь напиши на питоне, да хоть на паскале.
Т.е. в понятие микросервиса выше я вложил смысл этакого драйвера который просто пишет себе все что выдала железка по uart на ПК складывая все в немного обработанном виде избавленном от совершенно точно лишней каши. Я не имел ввиду на самом МК колхозить такое.
Т.е. в понятие микросервиса выше я вложил смысл этакого драйвера который просто пишет себе все что выдала железка по uart на ПК складывая все в немного обработанном виде избавленном от совершенно точно лишней каши. Я не имел ввиду на самом МК колхозить такое.
Дело хорошее, но бывает избыточно, если нужно быстренько отловить проблемку. Взял мою програмку и отловил.
Ок, я на работе сталкиваюсь с УСПД к которому подключены кучи датчиков. УСПД в нашем случае выполняет роль того самого микросервиса, он просто тупо собирает и пишет в бд все что ему пришло а после отдает по tcp или udp на выбор куда угодно. Сами датчики все работают на rs232 и rs485. Датчики совершенно разные(естественно проприетарные прошивки внутри) но производитель сделал умную вещь. Любой датчик шлет данные в бинарном виде(есть документация), грубо говоря абсолютно без разницы что это за датчик т.к. поток бинарных данных имеет вид:
УСПД принимает весь этот поток безобразия и просто складывает в базу, при приеме естественно откидывает битые пакеты отдельно для дебага и истории. Отдает их дальше в таком же виде уже клиентской стороне которая ковыряется и десериализует все это.
К чему я все это, все гениально и просто, датчики и МК в них шлют просто данные не занимаясь больше ничем что вполне правильно на мой взгляд и побережет ресурсы которых и так не особо много. На клиентской стороне эти пакеты элементарно по документации разбираются абсолютно любым удобным ЯП и показываются клиенту.
Когда нам надо проверить какойто датчик, берем обычный узбшный rs232\485, подключаем это безобразие, на ноутбуке есть самописная утилита(писал не я а кто то очень давно), в ней элементарно принимается поток, бьется на эти пакеты, в програмке есть «шаблонизатор» в котором просто прописываются шаблоны пакетов по типу packet_type=5{байт такойто это гироскоп, за ним байт показывающий темпереатуру, тут 6 байт подряд которые чары и т.д.}.
Интерфейс, как по мне, максимально удобно выглядит, удобен, не требует горожения колхозов и т.д., хочу работаю по TCP через УСПД, хочу напрямую цепляю датчик и вижу тоже самое.
Разве это не более универсальное решение, темболее я сильно сомневаюсь что никто до такого не догадался, производитель железок дорогих почему то именно такой способ выбрал и я думаю совсем не спроста а из соображений универсальности.
Поправьте если ход мыслей не правильный.
typedef struct {
int16_t data_len;
int16_t packet_type;
int16_t data;
int16_t crc;
}
УСПД принимает весь этот поток безобразия и просто складывает в базу, при приеме естественно откидывает битые пакеты отдельно для дебага и истории. Отдает их дальше в таком же виде уже клиентской стороне которая ковыряется и десериализует все это.
К чему я все это, все гениально и просто, датчики и МК в них шлют просто данные не занимаясь больше ничем что вполне правильно на мой взгляд и побережет ресурсы которых и так не особо много. На клиентской стороне эти пакеты элементарно по документации разбираются абсолютно любым удобным ЯП и показываются клиенту.
Когда нам надо проверить какойто датчик, берем обычный узбшный rs232\485, подключаем это безобразие, на ноутбуке есть самописная утилита(писал не я а кто то очень давно), в ней элементарно принимается поток, бьется на эти пакеты, в програмке есть «шаблонизатор» в котором просто прописываются шаблоны пакетов по типу packet_type=5{байт такойто это гироскоп, за ним байт показывающий темпереатуру, тут 6 байт подряд которые чары и т.д.}.
Интерфейс, как по мне, максимально удобно выглядит, удобен, не требует горожения колхозов и т.д., хочу работаю по TCP через УСПД, хочу напрямую цепляю датчик и вижу тоже самое.
Разве это не более универсальное решение, темболее я сильно сомневаюсь что никто до такого не догадался, производитель железок дорогих почему то именно такой способ выбрал и я думаю совсем не спроста а из соображений универсальности.
Поправьте если ход мыслей не правильный.
Поправьте если ход мыслей не правильный.Он неправильный в самом начале: вы предполагаете, что ваш микроконтроллер постоянно к чему-то подключён. Однако огромное число микроконтроллеров (возможно даже подавляющее число) — работают автономно и ни к чему «на постоянной основе» не подключены.
Куда-то подключаются они когда нужно систему перенастроить или, просто, разобраться с тем, что происходит. То есть выделенного УСПД, подключённого к микроконтроллеру на постоянной основе — просто нет.
производитель железок дорогих почему то именно такой способ выбрал и я думаю совсем не спроста а из соображений универсальности.Он выбрал такой способ потому, что мог его себе позволить. Стоимость STM32 — порядка полудоллара. Стоимость конечной хрени, на нём собранной, может быть 3-5 долларов. Ну хорошо — 10 долларов, от силы (это уже дорого).
Вы уверены что при таких ценах вам захочется докупать к этому устройству УСПД?
Я понял. Но почему даже просто без УСПД не унифицировать сам интерфейс данных и иметь 1 программу с возможностью писать шаблоны данных скриптами?
Одну программу для чего, я извиняюсь? Эмуляция VT52 есть в десятках вариантах под десятки операционных систем. Уже даже Windows этому научилась! putty скоро останется не у дел!
А вашу программу кто будет ставить себе? И зачем? Чтобы отлаживать ваш микроконтроллер? Ну так мы снова получаем проблему: вам нужен выделенный компьютер, с установленными «микросервисами», воткнуть в произвольный комп провод и использовать штатные средства, встроенные в OS — вы не можете!
В тех случаях когда у вас есть возможность в дополнение к железяке разрабатывать докупать ещё (неважно — УСПД или компьютер) — да, это решение.
Но очень часто — это просто неудобно.
А вашу программу кто будет ставить себе? И зачем? Чтобы отлаживать ваш микроконтроллер? Ну так мы снова получаем проблему: вам нужен выделенный компьютер, с установленными «микросервисами», воткнуть в произвольный комп провод и использовать штатные средства, встроенные в OS — вы не можете!
В тех случаях когда у вас есть возможность в дополнение к железяке разрабатывать докупать ещё (неважно — УСПД или компьютер) — да, это решение.
Но очень часто — это просто неудобно.
Пробовали ли вы запускать её под arduino ide? Что-то мне кажется, тамошний терминал не умеет escape-последовательностей.
Вообще странное решение. Для нахождения проблемы в коде, добавлять еще кода, который возможно принесет еще других проблем.
Для отладки это избыточно. Да и не всегда сработает: printf в UART достаточно медленная операция.
А если требуется постоянный вывод в uart — лучше парсить его в клиентском приложении, тогда с теми же затратами можно сделать и полноценную графику.
Имхо.
А если требуется постоянный вывод в uart — лучше парсить его в клиентском приложении, тогда с теми же затратами можно сделать и полноценную графику.
Имхо.
В тексте статьи я сказал, что printf использовать нельзя. А все координаты можно забить дефайнами и выводить готовые строки.
Парсить в приложении конечно хорошо, а если приложения не предвидится? Просто на этапе отладки.
Парсить в приложении конечно хорошо, а если приложения не предвидится? Просто на этапе отладки.
http://we.easyelectronics.ru/Soft/formatnyy-vyvod-na-si-dlya-mikrokontrollerov.html
Есть, оказывается, разные реализации printf. Да и что значит нельзя, если вы его все равно используете? ;)
Есть, оказывается, разные реализации printf. Да и что значит нельзя, если вы его все равно используете? ;)
Ну я использовал такие штуки. Но всё же лучше обойтись без printf.
Не рекомендую :). А мне было так проще.
Да и что значит нельзя, если вы его все равно используете? ;)
Не рекомендую :). А мне было так проще.
Для того чтоб это обойти, на микроконтроллерах с DMA возможна отдельная порнография: сформировать буфер и выводить его на UART в обход ядра процессора. Занимался таким, вполне себе рабочий вариант, если DMA не забит другими задачами под завязку.
Все эти терминалы, даже классический HyperTerminal отвечают некоторым стандартам.
Стандартам VT* — VT52? VT100 и так далее.
https://en.wikipedia.org/wiki/VT100
Преимущества готовых решений в адаптивности к терминалам с разными способностями (см. Termcap и Теrminfo). Если записать raw-escape последовательность в терминал, который её не поддерживает, то последствия неопределены — пропадаёт курсор, не печатается текст, слетает кодировка и т.д. Это хорошо видно на примерах скриптов-на-коленке, после запуска которых приходится выполнять reset в терминале.
Не умаляя ценности статьи и вспоминая принцип меньше значит больше, хочется спросить: если что-то не влазит по памяти, может оно там не нужно? На крайный случай всегда есть альтернатива.
Лично я столкнулся с проблемой отладкой множества коммутационных датчиков на разных пинах. Если делать листинг, то получается просто фарш. А вот в таком виде удобно.
Без сомнения, я очень благодарен за такие правки.
Без сомнения, я очень благодарен за такие правки.
Ну, я могу предложить 2 варианта отладки в такой ситуации:
1. писать в лог не все подряд, а только то что нужно
2. писать все подряд, лог сбрасывать в файл, анализировать результаты отдельно.
1. писать в лог не все подряд, а только то что нужно
2. писать все подряд, лог сбрасывать в файл, анализировать результаты отдельно.
32 датчика — все их писать. Нужно отслеживать в реальном времени. Решения дешевле и быстрее, чем сделать вывод на ESC-последовательностях не вижу.
Это еще отладка или уже рабочее использование? Если отладка — в терминал на 22" мониторе влазит 238 символов в ширину. Быстрее и дешевле построить велосипед, чем вывести все одним printf в одну строку? Если напрягает много одинаковых строк — выводить только те, что отличаются.
Как быть с аналоговыми датчиками? Удобно, когда значение меняется в одной ячейке.
А в чем проблема с аналоговыми датчиками? Вывод в таблицу с фиксированной шириной колонок придуман еще до C и егойного printf ;).
Смотрите, есть изменяемое значение. Я хочу его видеть в реальном времени в конткретном положении на экране, не изобретая велосипед с написанием софта на стороне ПК.
Если это задача одноразовая, убедиться что датчики работают — не вижу смысла строить велосипед ни со стороны ПК, ни со стороны контроллера.
Если же планируется режим отображения показаний на ПК — лучше делатьвелосипед визуализацию на ПК. Там больше ресурсов. Больше возможностей, например, графики сразу можно рисовать.
Если же планируется режим отображения показаний на ПК — лучше делать
Каждый из нас в праве решать проблемы удобным ему способом :)
Я просто предложил один из вариантов, который нахожу удобным. Да и потом, я порой просто оставляю пасхалки в разных консольных программа, чисто джаст фо лулз.
Я просто предложил один из вариантов, который нахожу удобным. Да и потом, я порой просто оставляю пасхалки в разных консольных программа, чисто джаст фо лулз.
лОл (англ. LOL — Lot Of Laugh). Извините, пожалуйста, за небольшое отступление от темы.
Таки офтоп
Обычно у девайса есть сохраняемые настройки. Их можно задавать с той же консоли. Обычно в этих настройках есть уровень выводимой отладочной информации (масками можно задавать даже их комбинации — выводить с датчика 1 и поступающие по Ethernet команды, к примеру).
А проблема переносимости, имхо, несколько надумана. Как часто у разработчика меняются терминалы? Что именно мешает использовать один и тот же ноутбук с одним и тем же Putty(по-моему лучший терминал, к тому же универсальный в плане протоколов, поддерживает цвета)?
А проблема переносимости, имхо, несколько надумана. Как часто у разработчика меняются терминалы? Что именно мешает использовать один и тот же ноутбук с одним и тем же Putty(по-моему лучший терминал, к тому же универсальный в плане протоколов, поддерживает цвета)?
Если вдруг никогда не видели — запустите ffplay на машине без иксов (наверное, достаточно будет их убить на время). И вы офигеете!
Вообще, у вас получился просто интерфейс отображения данных средствами терминала. Который, в отличие от журналов (логов) отладки, не содержит информации об истории событий. А именно история является самой важной при разборе полетов.
Очень, очень, очень плохой текст.
Почему? Потому что автор утверждает, что есть ESC-Последовательность, которая что-то делает. Одна.
На самом деле нет. И term в первом приближении может быть xterm, linux или screen. Или vt100, или dump. И его надо поддерживать.
Для этого и именно для этого нужна ncurses. Чтобы не париться о том, «каким esc-кодом рисовать».
Если вы такой умный, покажите мне вывод вашей программы на терминале с помощью python-vt100. С переменной среды окружения TERM=vt100. Ncurses и остальные программы, которые писались в реальном мире, это обработают правильно и адаптируются к плохому терминалу. Хардкоженные последовательности — нет.
Почему? Потому что автор утверждает, что есть ESC-Последовательность, которая что-то делает. Одна.
На самом деле нет. И term в первом приближении может быть xterm, linux или screen. Или vt100, или dump. И его надо поддерживать.
Для этого и именно для этого нужна ncurses. Чтобы не париться о том, «каким esc-кодом рисовать».
Если вы такой умный, покажите мне вывод вашей программы на терминале с помощью python-vt100. С переменной среды окружения TERM=vt100. Ncurses и остальные программы, которые писались в реальном мире, это обработают правильно и адаптируются к плохому терминалу. Хардкоженные последовательности — нет.
Очень хороший комментарий, не смотря на то что написан в такой хамской форме. И я полностью с ним согласен!
Есть некоторые последовательности, которые корректно работают практически везде. Вот вы можете сказать, какие конкретно используемые в моём коде последовательности будут отличаться во всех приведённых вами случаях?
Но тем не менее, я говорил в тексте и скажу здесь, что ncurses — это лучшее решение! Но если хочется быстро, качественно, не дорого и под МК — вот вариант.
Прежде чем писать, погуглил, ncurses для 8бит avr. Сходу не нашлось. Так что остаётся либо писать консольное приложение, обрабатывающие полученные данные с порта, либо реализовывать вариант, что предложил я. Питоном там не пахнет.
Есть некоторые последовательности, которые корректно работают практически везде. Вот вы можете сказать, какие конкретно используемые в моём коде последовательности будут отличаться во всех приведённых вами случаях?
Но тем не менее, я говорил в тексте и скажу здесь, что ncurses — это лучшее решение! Но если хочется быстро, качественно, не дорого и под МК — вот вариант.
Прежде чем писать, погуглил, ncurses для 8бит avr. Сходу не нашлось. Так что остаётся либо писать консольное приложение, обрабатывающие полученные данные с порта, либо реализовывать вариант, что предложил я. Питоном там не пахнет.
Все, управляющие цветом, не будут поддерживаться на vt100 (кроме bright). Просто потому, что vt100 — черно-белый. При этом там есть свои esc-последовательности для выделения текста (bright/underline, вроде бы, ещё и bold, но я не помню).
Они просто будут чёрно-белыми и будут работать.
Это с чего вы взяли? Я тут ничего такого близко не вижу: http://www.csie.ntu.edu.tw/~r92094/c++/VT100.html
Мне стало интересно. Назовите эмулятор vt100 терминала, я попробую.
TERM=vt100
export TERM
Время и дата в подтверждение.
export TERM
Время и дата в подтверждение.
В arduino ide жду увидеть ;).
Выдайте ардиуно, покажу.
Простите, а как изменение переменной среды окружения что-то меняет? Она говорит какой у вас терминал софту, но сам терминал при этом не меняется же.
UFO just landed and posted this here
Лучше чем putty?
UFO just landed and posted this here
КМК, это достаточно неудобно — весь отладочный вывод заворачивать в escape-последовательности. А если заворачивать не все — форма будет искажаться. Отлаживать код, который должен помогать в отладке, это лишнее.
Собственно говоря я об этом и говорил в статье. Не слушайте тех кто говорит, что это не удобно Удобно, проверенно.
Когда-то тоже занимался подобным "украшательством" вывода в UART на самом MCU, чтобы проще было отлаживать. Затем просто стандартиризировал отладочный вывод и отказался от использования стандартных терминалов в пользу скриптов на Python + модуль Serial — гибкости нет придела.
Sign up to leave a comment.
Терминальная графика