Обновить

Прошивка 8-битных МК по одному проводу: как устроен бутлоадер в vm5277

Уровень сложностиСредний
Время на прочтение20 мин
Охват и читатели12K
Всего голосов 9: ↑9 и ↓0+13
Комментарии38

Комментарии 38

Прошивка 8-битных МК 

А 8-битные МК еще где-то используются в разработке?

Используются, и в огромных объемах. В серийной коммерческой разработке (от автопрома до бытовой техники и копеечных датчиков) у 8-битных МК есть пул критических преимуществ:

  • Цена в серии: При больших партиях разница даже в 10–20 центов за чип экономит компании огромные бюджеты.

  • Физические размеры: Есть корпуса вроде SOT-23-6 (как у ATtiny10).

  • Энергопотребление: Микроскопический ток в режиме глубокого сна и мгновенное пробуждение.

  • Надежность: Они гораздо более устойчивы к ESD (электростатике) и помехам по питанию.

  • Мощные пины: Больший допустимый ток входов/выходов и полноценная поддержка 5-вольтовой логики (TTL) без согласования уровней.

  • Предсказуемость (Hard Real-Time): Простая архитектура без конвейеров и кэша позволяет с точностью до такта прогнозировать время выполнения ассемблерного кода.

  • Простота разработки: Минимальное количество периферии, не нужно писать десятки строк кода инициализации тактирования и шин.

Все вышеперечисленное есть в китайских кортексах и риск5. На озоне можно от 10р прикупить.

Поделитесь конкретной моделью пожалуйста, нейронка подсказывает CH32V003 который соответствует этому списку далеко не во всем и не везде.

Более того, если речь о CH32V003-подобных, то да, я планирую в будущем поддерживать и 32битное железо и в первую очередь чипы куда не сможет прийти microPython и прочие тяжелые системы.

py32xxx - нет?

Судя по всему - не совсем, ток на пинах - 8мА, цена рядом с 8-битками, размер - у AVR есть меньше, ток потребления больше. Предсказуемость - тоже нет.

Чип конечно интересный - он близок, но в целом не выигрывает.

А еще в целом вопрос надежности - AVR обкатан десятилетиями.

py32xxx, cw32xxx, hc32xxx, ch32xxxx, at32xxxx. xx32Lxxx удивят по потреблению. gd32fxx проходят термокамеру.

В вашем списке всё смешалось в кучу. Большинство названных вами линеек МК в розницу стоят существенно дороже 100 рублей. Применять их там, где физически достаточно простых и "дубовых" 8-биток типа AVR, нет абсолютно никакого коммерческого резона.

А те копеечные китайские чипы, которые остаются в бюджетном сегменте обладают настолько скромными ресурсами, что на них физически невозможно запустить MicroPython, MicroEJ или другие тяжелые системы.

Ведь в чем главная фишка популярности 32-битных МК? Именно в богатстве ресурсов, которые позволяют использовать высокоуровневые языки, колоссально экономя деньги компании на скорости разработки и поддержки. Но в ультрабюджетном секторе этот софтверный козырь исчезает - разработчик снова остается один на один с голым Си или Ассемблером.

Идея vm5277 как раз и заключается в том, чтобы дать легкую, модульную и удобную высокоуровневую экосистему именно для таких слабых по ресурсам МК, куда тяжелый софт никогда не сможет прийти.

И здесь спор о 8 бит МК не имеет смысла - да, в моем проекте говорится о 8 битах - что является стартом проекта, но я также говорю и о том, что планирую прийти на 32бит МК. Вот как раз, в первую очередь, на не дорогие чипы с не большми ресурсами.

Я как-то взял партию таких китайцев, половина вообще не завелась из-за брака кристалла :/

И делать что-то от чего может хоть чуть-чуть зависеть чья-то жизнь стоит только на AVR.

Здесь еще можно добавить возможность запитывания 8-битных кирпичей напрямую от литиевых аккумуляторов, ибо напряжение +4,3В для них абсолютно безопасно. Таким образом, пропадает необходимость установки на плату LDO для формирования +3,3В, что удешевляет изделие и позволяет избавиться от дополнительного собственного тока потребления стабилизатора (что критически важно в устройствах, работающих без подзарядки длительное время).

К тому же без стаба меньше шансов, что плата погорит от скачка при включении

Например - системный контроллер в ПК или ноутбуке.

На самом деле их ниша стремительно сужается, но в легаси-проектах они проживут еще долго

Используются, и в огромных объемах. В серийной коммерческой разработке (от автопрома до бытовой техники и копеечных датчиков)

Но это где-то там высоко в горах Юго-Восточной Азии, не в нашем районе. Китайцы, если их спросить отдают 32-битные МК по такой низкой цене, то чтобы хоть как-то оправдать 8-битные, нужны объемы в многие миллионы изделий ценой в несколько центов. Где такие разработки есть у нас?

Цена в серии: При больших партиях разница даже в 10–20 центов за чип экономит компании огромные бюджеты.

Вроде как нет такой разницы, юаней российских по ту сторону лежит немеряно, соответственно ввезти 32-битные МК можно по очень низкой цене.

Физические размеры: Есть корпуса вроде SOT-23-6 (как у ATtiny10).

ЖПТ не согласен: "Generally, a low-pin-count QFN package is smaller than SOT-23-6"

Энергопотребление: Микроскопический ток в режиме глубокого сна и мгновенное пробуждение.

Есть же L серии 32-битных МК

Надежность: Они гораздо более устойчивы к ESD (электростатике) и помехам по питанию.

Совсем неочевидное утверждение

Простота разработки: Минимальное количество периферии, не нужно писать десятки строк кода инициализации тактирования и шин.

Агенту пофиг.

Да, безусловно, рынок 32-битных МК сейчас огромен и разнообразен. Но если чип имеет одно из перечисленных преимуществ, то зачастую у него обнаруживается и жирный компромисс. Мои критерии имеют обобщенный характер - этот "джентльменский набор" (честные 5В, мощный ток пинов, живучесть, низкое потребление тока) свойственен большинству 8-битных МК по умолчанию. В мире 32-битных чипов встретить всё это вместе в одном кристалле за копейки - большая редкость.

Но главное даже не в железе, а в софте. Что конкретно мы подразумеваем, говоря про ультрабюджетные 32-битки? На них физически невозможно запустить MicroPython, MicroEJ или другие тяжелые экосистемы - им просто не хватит ресурсов.

Ниша проекта vm5277 - это как раз слабые по ресурсам МК, где требования к железу близки к нативному Си. Идея в том, чтобы принести удобную модульную экосистему и высокоуровневый комфорт на те микроскопические кристаллы, куда тяжелый софт никогда не придет, а писать на голом ассемблере или Си под каждую задачу слишком дорого.

5В уже как-то давно не встречается. Силовая часть - 12В, относительно дубовая логика - 3.3В. Зачастую внутри МК стоит встроенный стаб на 1.2-1.8В, похоже такие напряжения так же станут стандартными для питания простых МК

3.3v - это нормально и давно уже должно было стать базой. Однако Arduino Uno еще жива и многие на ней учатся схемотехнике и программированию - а там большая часть датчиков и различных устройств на TTL

с точки зрения потребления - да, но есть скажем транзисторы, тиристоры (для силовухи) которые прекрасно открываются напряжением 3.3, а вот 1.8 и 1.2 уже не хватает, особенности кремния вроде как. и если уже подобрано много хороших компонентов работающих на 3.3 то как то попроще использовать контроллер на 3.3 чем городить доп. согласование до более низких уровней

Для силовухи драйверы желательно использовать, они уже довольно дешевые. А многие низковольтные полевики имеют очень низкое управляющее напряжение. Биполярники - вообще 0.6В

чтобы хоть как-то оправдать 8-битные

можно взглянуть немного с другой стороны - в простой программе подавляющее большинство команд оперируют всё ещё uint8_t

На 32-битных процах операции с такими числами требуют доп операции приведения к 8 битам. Так что даже на сях желательно знать под что писать

Агенту пофиг.

Ага, если писать на чем-то отличном от STM32, агент вам такое напишет. Он до сих пор не в состоянии отличать семейства МК и путает даташиты к ним, ну и в даташитах, бывает, такого напишут, что никакой самый умный агент не сможет это понять.

Как в “однопроводке” избегается конфликт двунаправленного вывода МК с выходом TxD программатора?

Штатный режим: МК переключает пин на выход только в момент вывода логов или ответов, а всё остальное время жестко сидит в режиме входа (Hi-Z). ПО на ПК работает в строгом полудуплексе - во время приема данных его передатчик заблокирован. Когда МК сыплет логами, ПК молчит; когда ПК начинает передачу, МК выступает чистым приемником.

Контроль рантайма: Логика STDIO в рантайме выстроена так, что если МК ожидает ввода, он сам ничего в этот момент не инициирует и линию на выход не дергает.

Что если коллизия? Риск рассинхронизации из-за сбоя в логике рантайма теоретически существует. Но даже если это произойдет, коллизия будет кратковременной - в худшем случае прилетят битые данные (что логично, раз рантайм пошел вразнос). А физика портов за эти миллисекунды пострадать просто не успеет, кремний останется цел. Ну а для надежности всегда есть классическое решение - поставить защитный резистор на 1 кОм.

Более того, на этапе проектирования у меня была идея формировать периодические окна приема с отправкой специального синхронизирующего кода со стороны МК. Но взвесив все "за" и "против", я пришел к выводу, что для ультралегкой 8-битной системы это излишне. Это привело бы к раздуванию ассемблерного кода ядра и нецелевому расходу тактов процессора на холостые циклы. Выбранная в итоге реактивная схема на PCINT оказалась намного компактнее и эффективнее.

Вопрос к автору - планируется ли поддержка чипов ATmega328PB? Та же мега328 за меньшие деньги с бОльшим количеством GPIO, прерываний, таймеров и интерфейсов.

список МК на которых я ранее тестировал проекты.
список МК на которых я ранее тестировал проекты.

Да, она есть в тулките, давно не обновлял по ней данные - вероятно сразу не заведется, просто нужно актуализировать, как в прочем и по другим чипам.

В общем вопрос только в актуализации.

Чип действительно интересный.

вот поэтому довольно давно дня avr поновее сделали dw, pdi и главное - updi, довольно близко к описываемому здесь

Верно.

Я только продублирую здесь часть статьи:

Я не претендую на абсолютную уникальность однопроводного интерфейса — в тех же чипах AVR от Atmel/Microchip есть фирменный протокол debugWIRE. Но, во-первых, он является закрытым проприетарным решением, требующим фирменного (и недешевого) программатора. Во-вторых, для его работы пин RESET должен быть аппаратно заблокирован под нужды отладки. Ну и в-третьих, в моей долгой инженерной практике debugWIRE регулярно демонстрировал нестабильность и сбои передачи данных (что, скорее всего, связано с сыростью софта на стороне хоста).

Плюс, добавим сюда универсальность моего решения (пусть и не оригинального)

dw то да, невозмоджно использовать без isp и то с проблемами. а вот udpi меня удивил - шить можно обычным usb-uart, отладка тоже есть. если прошивку надо обновлять то отдельный провод - иногда вполне себе вариант

Приятно, что Microchip не забросила труды Atmel. Про UPDI я раньше не слышал, так как в основном сижу на старых AVR (если не считать ATmega328PB). Жаль, что этот протокол остаётся частично закрытым - иначе я бы с удовольствием добавил его поддержку в свой проект.

есть один фанат новых avr который ну прям по битикам копает и сравнивает на github, включая материал как прошить updi через разные usb uart. софт для этого дела тоже доступен в исходниках, и не один

Но, во-первых, он является закрытым проприетарным решением, требующим фирменного (и недешевого) программатора. 

~20 лет назад AVR Dragon стоил 80$, со скидкой я купил за 40$. Это ни о чем, при том что сами микроконтроллеры поштучно стоили 5-10
Протокол DW современные LLM легко отреверсят (или уже давно кто-то это сделал)

пин RESET должен быть аппаратно заблокирован под нужды отладки

Его все также можно использовать как ресет. Но его прелесть, что он в и так 99% не используется. Особенно важно на 8-ногих МК.

Но самое главное DW - это полноценная отладка, которая есть с завода.

 Ну и в-третьих, в моей долгой инженерной практике debugWIRE регулярно демонстрировал нестабильность и сбои передачи данных (что, скорее всего, связано с сыростью софта на стороне хоста)

Печально, что у вас так. Я тоже не особенно доволен их софтом, но мой опыт использования любых IDE для микроконтроллеров - всё тупит +- одинаково.

На текущий момент основой платформой для разработки является AVR, в частности широко известный ATmega328p-чип используемый в Arduino UNO

Плюс, добавим сюда универсальность моего решения (пусть и не оригинального)

Звучит взаимоисключающе.

Ваше решение выглядит лучше чем отладочные приципы в инфрастркутуре ардуины,
Но неясно зачем откапывать стюадессу в 2026.

~20 лет назад AVR Dragon стоил 80$, со скидкой я купил за 40$. Это ни о чем, при том что сами микроконтроллеры поштучно стоили 5-10Протокол DW современные LLM легко отреверсят (или уже давно кто-то это сделал)

Вы сравниваете программатор за 80$ с USB-UART за 100 рублей.

Но самое главное DW - это полноценная отладка, которая есть с завода.

Вы видели что мой проект в стадии альфа? В бета будет полноценная высокоуровневая отладка.

Печально, что у вас так. Я тоже не особенно доволен их софтом, но мой опыт использования любых IDE для микроконтроллеров - всё тупит +- одинаково.

Мне тоже печально. Но намекать на косорукость человека с трудами как у меня - это однозначно попытка задеть

Ваше решение выглядит лучше чем отладочные приципы в инфрастркутуре ардуины, Но неясно зачем откапывать стюадессу в 2026.

Мне не понятен ваш жаргон, подозреваю что речь идет об исключительно поддержке Atmega328 - это крупное заблуждение.

Далее беседы с Вами не будет, так как я сомневаюсь в Вашей адекватности и доброжелательности.

Не было смысла вас как-то задеть, обидеть или оскорбить.

Вы сравниваете программатор за 80$ с USB-UART за 100 рублей.

Это ОТЛАДЧИК, который спас кучу времени. А программатор в те времена это что-то типа такого. Без USB хватало.

FTDI 232 в те времена стотил тоже около 5 долларов в моем селе.

DW (загуглил) давно отреверсили:
https://github.com/dcwbrown/dwire-debug

Instead of expensive proprietary hardware it works with a USB UART (FT232 or CH340) or a DigiSpark/LittleWire compatible board.

Мне не понятен ваш жаргон, подозреваю что речь идет об исключительно поддержке Atmega328 - это крупное заблуждение.

Тут нектотрые пишут /s указывая на сарказм (извините, думал это общеизвестный анекдот).

Я очень люблю AVR, даже всячески защищаю в комментариях. Готов даже использовать, не смотря на цену. Но, на мой взгляд, AVR потерял свой смысл для каких-то новых разработок.

Интересно как обрабатывается прерывание по стартовому биту, если МК в этот момент занят чем-то критичным. Задержка может легко развалить весь полудуплексный обмен

Отредактировал ответ:

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

Более того, верхний уровень (код на J8B) в принципе не работает с прерываниями напрямую. Даже многопоточность для верхнего уровня реализована иначе - ее архитектура сильно отличается от стандартных RTOS и изолирует прикладной код от низкоуровневых системных таймингов.

Что касается самого обмена, передача данных со стороны МК имеет свою специфику: отправка конкретного байта выполняется с заблокированными прерываниями для жесткого удержания таймингов битов. Однако между передачей байт прерывания снова разрешаются. Пауза между байтами вполне допустима протоколом, поэтому система успевает обрабатывать другие задачи.

Ну а если в какой-то специфической конфигурации все же найдутся критические узкие места, то снижение BAUDRATE гарантированно решит эту проблему.

И да - это альфа, пока ядро не вылизано. Сейчас в коде есть блоки которые могут заблокировать прерывания дольше чем следовало - но это временно, в релизе так точно не будет, просто еще не все сделано.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации