Комментарии 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 жду увидеть ;).
Выдайте ардиуно, покажу.
Простите, а как изменение переменной среды окружения что-то меняет? Она говорит какой у вас терминал софту, но сам терминал при этом не меняется же.
НЛО прилетело и опубликовало эту надпись здесь
Лучше чем putty?
НЛО прилетело и опубликовало эту надпись здесь
КМК, это достаточно неудобно — весь отладочный вывод заворачивать в escape-последовательности. А если заворачивать не все — форма будет искажаться. Отлаживать код, который должен помогать в отладке, это лишнее.
Собственно говоря я об этом и говорил в статье. Не слушайте тех кто говорит, что это не удобно Удобно, проверенно.
Когда-то тоже занимался подобным "украшательством" вывода в UART на самом MCU, чтобы проще было отлаживать. Затем просто стандартиризировал отладочный вывод и отказался от использования стандартных терминалов в пользу скриптов на Python + модуль Serial — гибкости нет придела.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Терминальная графика