Комментарии 19
Так то уже есть https://github.com/antirez/linenoise и https://github.com/argtable/argtable3
Ух, большое спасибо за ссылки, не попадались мне при поиске. Отличный источник хороших идей
Консоль для ESP, где использованы обе либы, названные @AndyKorg:
https://github.com/espressif/esp-idf/tree/master/components/console
По поводу драйвера USART:
Шел 2021 год, мыши плакали .... программисты продолжали писать в регистры.
Я кайфую с этого :) Причем это отличный способ разобраться в деталях как все работает. Не люблю HAL и прочие нагромождения. LL разве только, но это просто обертки.
Микроконтроллеры программирую только в своих хобби проектах и их не нужно портировать на другие процы.
Это лично мои убеждения. В больших проектах писать драйвера на регистрах излишне, но тут можно и развлечься :)
Наверное стоит написать почему я пришел с этим убеждениям. Раньше я использовал HAL, но в новом проекте у меня перестал работать USART. Я потратил много времени на отладку и оказалось, что в HAL не правильно вычислялся baudrate (подробностей не помню, было давно).
После этого я соскочил с него.
Причем это отличный способ разобраться в деталях как все работает.
Поддерживаю. Более того, иногда это единственный способ сделать код ещё и быстрым.
не нужно портировать на другие процы.
если честно, не могу понять, кому вообще в здравом уме придет идея создавать новый проект под новый МК сохраняя при этом функциональность. Отсюда получается что HAL дико избыточен по своему функционалу. Есть у кого-то опыт, где реально был с десяток разных МК и прям нужно было переносить код (практически один к одному) и HAL в этом случае реально помог. Интересно было бы послушать.
У меня был такой опыт.
Поэтому всегда топлю за HAL с минимально возможными вставками регистровых обращений.
А все из за того, что на предыдущем месте работы в течении полугода силами нескольких человек приходилось перетаскивать наработки между семействами МК.
Вот представьте себе ситуацию, вы сделали какой то супер пупер прибор, у вас написаны свои драйвера и библиотечки для АЦП, Ethernet, гироскопов, модбасов и прочих МЭК протоколов, модули удаленного обновления ПО через протоколы верхнего уровня и пр и все это ну допустим под STM32F3. И тут к вам приходит заказ — сделать похожий прибор с теми же функциями, но с дисплеем и прочими плюшками. А это уже STM32F7. Срок 2-3 мес вместе с железом. Если все писать на регистрах и LL — то за 2-3 мес перенести можно, но потом нужно будет менять работников после выгорания.
Проекты, которые изначально написаны на HAL и не имеют прямых обращений к регистрам — переносятся одним человеком за пару дней.
Клиенту нужен рабочий прибор, а не оптимально написанный код на регистрах.
В хоббийных проектах хоть на асме можно писать, а коммерция — это всегда минимизация сроков и затрат на разработку, поэтому только HAL.
Спасибо, вполне реальный пример. Но на мой взгляд, переход между F3 и F7 не такой уж и сложный. Большая часть периферии все же конфигурируется одинаково. у ST только I2C да DMA сильно менялись при выходе новых моделей. GPIO\TIMER\SPI так вообще практически неизменны. (за исключением F1 серии, там все другое). А например переход между F1 и L4+ семействами был бы повеселее как мне кажется.
Клиенту нужен рабочий прибор, а не оптимально написанный код на регистрах.
Ещё и нужен вчера. Но тут как посмотреть, иногда ведь клиент хочет чтоб железка была маленькой и от батарейки работала вечно. Вот тут в оптимизацию топишь по максимуму. И тогда вместо F7 ставишь тот же F3, перечитывая историю одного байти).
Вот представьте себе ситуацию, вы сделали какой то супер пупер прибор, у вас написаны свои драйвера и библиотечки для АЦП, Ethernet, гироскопов, модбасов и прочих МЭК протоколов, модули удаленного обновления ПО через протоколы верхнего уровня и пр и все это ну допустим под STM32F3.
Это могу представить, у меня в работе как раз есть отдаленно похожая вещь. Есть прибор где связка nrf52840 + stm32l4r, а есть где просто nrf52840. В добавок некоторый код переносится с DSP. И особых проблем не испытываю.
драйвера и библиотечки для АЦП, Ethernet, гироскопов, модбасов и прочих МЭК протоколов
при написании этого добра, код должен зависеть только от трех функций ( в основном): прочить по шине, записать по шине, настроить шину для себя. И все. Интерфейс универсальный, реализация под каждый МК своя. Перенос делается одним человек за пару часов. Правда справедливости ради, перед этим на написании драйверов потрачено N-количество времени.
Я пробовал HAL от нордиков, когда подключал внешнюю NAND память. Да приятно и удобно, вызвал инит и забыл: оно работает само, правда на ките и только с 8 МБ памятью. Переход на больший объем оказался сложным, так как в HAL забыли добавить возможность отправки кастомной команды для перехода на 32-битную адресацию по шине. Недели две ушло на то, чтобы понять из какого места это правильно и безопасно сделать. Абстракция над абстракцией и абстракцией погоняет. Три или четыре уровня, с постоянным переименованием методов и переменных для вызова 6 строк записи в регистры. Это разве удобно?!
Ну вы не путайте HAL от STM и HAL от нордика.
У STM один уровень над железом и относительно устоявшимися именами функций.
А код либ для нордика какие то наркоманы пишут. Причем судя по всему они еще от версии к версии SDK забывают что там писали ранее и начинают выдумывать снова.
Поэтому любое обновление версий либ — это трэш лютейший.
Но в целом нордик мне нравится, под него действительно надо писать свои обертки на регистрах.
А что мешает открывать и закрывать сессии с помощью УП? Тогда выкидываем один провод и получаем универсальность. Можно использовать RS485, да хоть радиоканал.
Насколько помню, FreeRTOS и NuttX предоставляют в своих сборках/либах терминал. NuttX так вообще POSIX подобная RTOS.
Для решения этой проблемы вычисляется разница между текущей и следующей командами, и затираем хвосты в зависимости от её значения.
В своём похожем проекте я использовал УП ESC[K - очистить строку от курсора справа (курсор при этом в начале). Это делаю перед выводом команды из истории. Статью на тему своего терминального интерфейса я напишу в скором времени. А в целом ваша статья очень полезна. Даже редактирование команды в середине строки реализовано, чего я ещё пока не сделал. Считаю, что такие функции, как история и редактирование команд, должны быть возложены на терминал. Точнее, должен быть такой режим, как предварительный редактор. Если такого терминала не существует, его можно написать самому.
Консоль для микроконтроллера. Браво!
Пишем терминальный сервер для микроконтроллера на С