Pull to refresh

Comments 69

Надо для Python подумать. Спасибо) как раз надо подключать датчик.

Никогда в плотную не работал с девайсами и особо не знаю всех проблем. Есть пара вопросов:
1) Почему бы не сделать микросервис который бы тупо буферизировал весь хлам из uart\com, или сохранял его в бд и т.д. Дальше отдавал бы все это по tcp\udp по некоему общему интерфейсу. Дальше уже эти данные переваривать в кому что удобно, хочешь выводи в консоль, хочешь нарисуй GUI и т.д.
2) В чем именно проблема переносимости?
PS не кидайтесь помидорами, я правда не писал и не делал ничего с такими самопальными игрушками. Хотя с удовольствием бы что то такое состряпал со стороны софта.
Вопрос где хранить БД? У контроллера может быть 256 БАЙТ ОЗУ. И всё остальное жёстко зашито. В 256 байтах (даже в килобайте) сложно развернутся.

UPD Не совсем понял вопроса сразу. Тем не менее — это всё лишние сложности, которые во время отладки не нужны.
1) уже. тысячи их. Даже девайсы специальные есть.
2) Памяти не очень много. Хотя я думаю что базовые библиотеки уже есть.
PS не кидайтесь помидорами, я правда не писал и не делал ничего с такими самопальными игрушками. Хотя с удовольствием бы что то такое состряпал со стороны софта.
Да легко! Ваше творение будет только с МЕГА версией на 8KiB памяти работать, или в минимальной версии с 1KiB памяти вы тоже микросервисы разведёте? Учтите что этой же памятью и все остальные подпрограммы должны, как бы, пользоваться.

Почему бы не сделать микросервис который бы тупо буферизировал весь хлам из uart\com, или сохранял его в бд и т.д.
Потому что если вы это хотите разводить не на самой железяке, то вы автоматически теряете возможность к ней подконнектится любым терминалом и, соответственно, делаете работу с железкой резко менее удобной, а если на ней, то… ну попробуйте…
Говоря про микросервис я имел ввиду что некая железка подключается к тому же обычному ПК по обычному UART или RS232. На этом ПК стоит микросервис который тупо дампит себе абсолютно все что приходит, хранит\буферизирует и просто ждет кто все это запросит уже на обычном tcp\udp. Дальше с этими данными уже делай что хочешь, хочешь напиши на java красивую вебморду которая будет запускаться на любой OS, хочешь напиши на питоне, да хоть на паскале.
Т.е. в понятие микросервиса выше я вложил смысл этакого драйвера который просто пишет себе все что выдала железка по uart на ПК складывая все в немного обработанном виде избавленном от совершенно точно лишней каши. Я не имел ввиду на самом МК колхозить такое.
Дело хорошее, но бывает избыточно, если нужно быстренько отловить проблемку. Взял мою програмку и отловил.
Ок, я на работе сталкиваюсь с УСПД к которому подключены кучи датчиков. УСПД в нашем случае выполняет роль того самого микросервиса, он просто тупо собирает и пишет в бд все что ему пришло а после отдает по tcp или udp на выбор куда угодно. Сами датчики все работают на rs232 и rs485. Датчики совершенно разные(естественно проприетарные прошивки внутри) но производитель сделал умную вещь. Любой датчик шлет данные в бинарном виде(есть документация), грубо говоря абсолютно без разницы что это за датчик т.к. поток бинарных данных имеет вид:
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 — вы не можете!

В тех случаях когда у вас есть возможность в дополнение к железяке разрабатывать докупать ещё (неважно — УСПД или компьютер) — да, это решение.

Но очень часто — это просто неудобно.
Пробовали ли вы запускать её под arduino ide? Что-то мне кажется, тамошний терминал не умеет escape-последовательностей.
Вообще странное решение. Для нахождения проблемы в коде, добавлять еще кода, который возможно принесет еще других проблем.
К сожалению так все и делают…
Для отладки это избыточно. Да и не всегда сработает: printf в UART достаточно медленная операция.
А если требуется постоянный вывод в uart — лучше парсить его в клиентском приложении, тогда с теми же затратами можно сделать и полноценную графику.
Имхо.
В тексте статьи я сказал, что printf использовать нельзя. А все координаты можно забить дефайнами и выводить готовые строки.

Парсить в приложении конечно хорошо, а если приложения не предвидится? Просто на этапе отладки.
http://we.easyelectronics.ru/Soft/formatnyy-vyvod-na-si-dlya-mikrokontrollerov.html
Есть, оказывается, разные реализации printf. Да и что значит нельзя, если вы его все равно используете? ;)
Ну я использовал такие штуки. Но всё же лучше обойтись без printf.

Да и что значит нельзя, если вы его все равно используете? ;)


Не рекомендую :). А мне было так проще.
В вашей программе, которая пример форматированного debug'а, я вижу printf, который вы же не рекомендуете. ;)
Его легко можно заменить ;)
Заменить, наверное можно. Хотя вы не заменили. Хотя другим не рекомендуете почему-то ;)
Легко — сомневаюсь.
Функция printf нужна для задания атрибутов цвета и gotoxy. Можно жёстко забить все атрибуты сразу функцией puts. С gotoxy немного сложнеее, но можно жёстко задать все координаты в дефайне и просто дёргать их.
Для того чтоб это обойти, на микроконтроллерах с DMA возможна отдельная порнография: сформировать буфер и выводить его на UART в обход ядра процессора. Занимался таким, вполне себе рабочий вариант, если DMA не забит другими задачами под завязку.
Все эти терминалы, даже классический HyperTerminal отвечают некоторым стандартам.

Стандартам VT* — VT52? VT100 и так далее.
https://en.wikipedia.org/wiki/VT100
Всё именно так. Просто не стал писать.

Преимущества готовых решений в адаптивности к терминалам с разными способностями (см. Termcap и Теrminfo). Если записать raw-escape последовательность в терминал, который её не поддерживает, то последствия неопределены — пропадаёт курсор, не печатается текст, слетает кодировка и т.д. Это хорошо видно на примерах скриптов-на-коленке, после запуска которых приходится выполнять reset в терминале.


Не умаляя ценности статьи и вспоминая принцип меньше значит больше, хочется спросить: если что-то не влазит по памяти, может оно там не нужно? На крайный случай всегда есть альтернатива.

Лично я столкнулся с проблемой отладкой множества коммутационных датчиков на разных пинах. Если делать листинг, то получается просто фарш. А вот в таком виде удобно.
Без сомнения, я очень благодарен за такие правки.
Ну, я могу предложить 2 варианта отладки в такой ситуации:
1. писать в лог не все подряд, а только то что нужно
2. писать все подряд, лог сбрасывать в файл, анализировать результаты отдельно.
32 датчика — все их писать. Нужно отслеживать в реальном времени. Решения дешевле и быстрее, чем сделать вывод на ESC-последовательностях не вижу.
Это еще отладка или уже рабочее использование? Если отладка — в терминал на 22" мониторе влазит 238 символов в ширину. Быстрее и дешевле построить велосипед, чем вывести все одним printf в одну строку? Если напрягает много одинаковых строк — выводить только те, что отличаются.
Как быть с аналоговыми датчиками? Удобно, когда значение меняется в одной ячейке.
А в чем проблема с аналоговыми датчиками? Вывод в таблицу с фиксированной шириной колонок придуман еще до C и егойного printf ;).
Смотрите, есть изменяемое значение. Я хочу его видеть в реальном времени в конткретном положении на экране, не изобретая велосипед с написанием софта на стороне ПК.
Если это задача одноразовая, убедиться что датчики работают — не вижу смысла строить велосипед ни со стороны ПК, ни со стороны контроллера.
Если же планируется режим отображения показаний на ПК — лучше делать велосипед визуализацию на ПК. Там больше ресурсов. Больше возможностей, например, графики сразу можно рисовать.
Каждый из нас в праве решать проблемы удобным ему способом :)

Я просто предложил один из вариантов, который нахожу удобным. Да и потом, я порой просто оставляю пасхалки в разных консольных программа, чисто джаст фо лулз.
лОл (англ. LOL — Lot Of Laugh). Извините, пожалуйста, за небольшое отступление от темы.
Обычно у девайса есть сохраняемые настройки. Их можно задавать с той же консоли. Обычно в этих настройках есть уровень выводимой отладочной информации (масками можно задавать даже их комбинации — выводить с датчика 1 и поступающие по Ethernet команды, к примеру).
А проблема переносимости, имхо, несколько надумана. Как часто у разработчика меняются терминалы? Что именно мешает использовать один и тот же ноутбук с одним и тем же Putty(по-моему лучший терминал, к тому же универсальный в плане протоколов, поддерживает цвета)?
Если вдруг никогда не видели — запустите ffplay на машине без иксов (наверное, достаточно будет их убить на время). И вы офигеете!
Вообще, у вас получился просто интерфейс отображения данных средствами терминала. Который, в отличие от журналов (логов) отладки, не содержит информации об истории событий. А именно история является самой важной при разборе полетов.
Для каждой задачи свой интерфейс. Я ещё раз говорю, что в реальном времени работать с логами не очень удобно. Логи и так по умолчанию идут.
Логи и так по умолчанию идут.

Куда они идут, если com порт занят рисованием формы?
Очень, очень, очень плохой текст.

Почему? Потому что автор утверждает, что есть ESC-Последовательность, которая что-то делает. Одна.

На самом деле нет. И term в первом приближении может быть xterm, linux или screen. Или vt100, или dump. И его надо поддерживать.

Для этого и именно для этого нужна ncurses. Чтобы не париться о том, «каким esc-кодом рисовать».

Если вы такой умный, покажите мне вывод вашей программы на терминале с помощью python-vt100. С переменной среды окружения TERM=vt100. Ncurses и остальные программы, которые писались в реальном мире, это обработают правильно и адаптируются к плохому терминалу. Хардкоженные последовательности — нет.
Очень хороший комментарий, не смотря на то что написан в такой хамской форме. И я полностью с ним согласен!

Есть некоторые последовательности, которые корректно работают практически везде. Вот вы можете сказать, какие конкретно используемые в моём коде последовательности будут отличаться во всех приведённых вами случаях?

Но тем не менее, я говорил в тексте и скажу здесь, что ncurses — это лучшее решение! Но если хочется быстро, качественно, не дорого и под МК — вот вариант.

Прежде чем писать, погуглил, ncurses для 8бит avr. Сходу не нашлось. Так что остаётся либо писать консольное приложение, обрабатывающие полученные данные с порта, либо реализовывать вариант, что предложил я. Питоном там не пахнет.
Все, управляющие цветом, не будут поддерживаться на vt100 (кроме bright). Просто потому, что vt100 — черно-белый. При этом там есть свои esc-последовательности для выделения текста (bright/underline, вроде бы, ещё и bold, но я не помню).
Они просто будут чёрно-белыми и будут работать.
Это с чего вы взяли? Я тут ничего такого близко не вижу: http://www.csie.ntu.edu.tw/~r92094/c++/VT100.html
Мне стало интересно. Назовите эмулятор vt100 терминала, я попробую.
https://www.vandyke.com/products/securecrt/terminal_emulation_vt100.html

Я не пробовал, но, вроде, оно.
TERM=vt100
export TERM



Время и дата в подтверждение.
В arduino ide жду увидеть ;).
Выдайте ардиуно, покажу.
Подключите любой другой контроллер и запустите монитор COM порта. UART он везде UART.
Считайте я проверил — работает.
Скриншот не получилось сделать?
Вы программу переделайте для ардуино, и откройте её в minicom. Всё будет работать.
Не верю.
Я проверил — в dumb терминале, встроенном в Arduino IDE, escape последовательности отрисовываются квадратиками.
arduino

Ожидалось такое вот:
xterm
Ну дык, это не терминал, а просто компортовая плевалка. Явно не vt52
Простите, а как изменение переменной среды окружения что-то меняет? Она говорит какой у вас терминал софту, но сам терминал при этом не меняется же.
Не прощу!

Ну это я бегло погуглил, как можно сделать.
UFO landed and left these words here
UFO landed and left these words here
КМК, это достаточно неудобно — весь отладочный вывод заворачивать в escape-последовательности. А если заворачивать не все — форма будет искажаться. Отлаживать код, который должен помогать в отладке, это лишнее.
Собственно говоря я об этом и говорил в статье. Не слушайте тех кто говорит, что это не удобно Удобно, проверенно.
Удобно, ну и ладно ;) У всех свои понятия про удобство, какие действия выполнять во время отладки, и зачем она воще нужна. Слава труду, короче ;)
UFO landed and left these words here

Когда-то тоже занимался подобным "украшательством" вывода в UART на самом MCU, чтобы проще было отлаживать. Затем просто стандартиризировал отладочный вывод и отказался от использования стандартных терминалов в пользу скриптов на Python + модуль Serial — гибкости нет придела.

Only those users with full accounts are able to leave comments. Log in, please.