Комментарии 38
Прошивка 8-битных МК
А 8-битные МК еще где-то используются в разработке?
Используются, и в огромных объемах. В серийной коммерческой разработке (от автопрома до бытовой техники и копеечных датчиков) у 8-битных МК есть пул критических преимуществ:
Цена в серии: При больших партиях разница даже в 10–20 центов за чип экономит компании огромные бюджеты.
Физические размеры: Есть корпуса вроде SOT-23-6 (как у ATtiny10).
Энергопотребление: Микроскопический ток в режиме глубокого сна и мгновенное пробуждение.
Надежность: Они гораздо более устойчивы к ESD (электростатике) и помехам по питанию.
Мощные пины: Больший допустимый ток входов/выходов и полноценная поддержка 5-вольтовой логики (TTL) без согласования уровней.
Предсказуемость (Hard Real-Time): Простая архитектура без конвейеров и кэша позволяет с точностью до такта прогнозировать время выполнения ассемблерного кода.
Простота разработки: Минимальное количество периферии, не нужно писать десятки строк кода инициализации тактирования и шин.
Все вышеперечисленное есть в китайских кортексах и риск5. На озоне можно от 10р прикупить.
Поделитесь конкретной моделью пожалуйста, нейронка подсказывает CH32V003 который соответствует этому списку далеко не во всем и не везде.
Более того, если речь о CH32V003-подобных, то да, я планирую в будущем поддерживать и 32битное железо и в первую очередь чипы куда не сможет прийти microPython и прочие тяжелые системы.
py32xxx - нет?
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 чем городить доп. согласование до более низких уровней
чтобы хоть как-то оправдать 8-битные
можно взглянуть немного с другой стороны - в простой программе подавляющее большинство команд оперируют всё ещё uint8_t
Агенту пофиг.
Ага, если писать на чем-то отличном от 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). Жаль, что этот протокол остаётся частично закрытым - иначе я бы с удовольствием добавил его поддержку в свой проект.
Но, во-первых, он является закрытым проприетарным решением, требующим фирменного (и недешевого) программатора.
~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 гарантированно решит эту проблему.
И да - это альфа, пока ядро не вылизано. Сейчас в коде есть блоки которые могут заблокировать прерывания дольше чем следовало - но это временно, в релизе так точно не будет, просто еще не все сделано.


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