Новости о моем проекте vm5277 (разработка ПО для 8бит МК)

Сегодня  я решил поделиться хорошей новостью - у меня успешно (без ошибок) отработал очередной пример написанный на моем  языке J8B (близкий к синтаксису Java).

Я чуть более года создаю тулкит, который обойдет по многим важным аспектам существующие современные решения используемые для разработки программ (прошивок) на 8-битные микроконтроллеры (для начала). Ссылки на open source проект смотрите в конце поста.

Сейчас я акцентирую внимание на функционале и чаще всего для тестирования использую ATmega328p (он же используется в Arduino UNO), однако этот тулкит имеет все архитектурные возможности для мультиплатформенного кодинга (в том числе, в будущем, и для 32 битных микроконтроллеров)

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

И здесь нет никаких сложностей. В интернете есть множество примеров и скетчей для Arduino с использованием этого датчика. И поэтому его опрос легко реализовать на Си и даже на Ассемблере.

Но что если я хочу писать не на Си и Ассемблере, а на высокоуровневом ООП языке схожим синтаксисом с Java? Что если я не хочу знать как работает серийный порт, что такое прерывания и как переносить мою программу с одного чипа на другой? А еще больше я не хочу погружаться в тяжелый синтаксис Си и тем более ассемблера.

Я хочу использовать язык похожий на Java, чтобы он был максимально безопасен: чтобы моя программа не падала из-за выхода за границы массивов, чтобы я мог отслеживать переполнения примитивов, чтобы у меня была нормальная работа с исключениями. И я не хочу постоянно заботиться о выделении и освобождении памяти - из-за этого постоянно куча трудно диагностируемых ошибок, особенно если добавить еще работу с указателями. А еще я хочу композицию, потому что полноценное наследование неоправданно дорого, особенно для 8-битных микроконтроллеров. Т.е. я хочу работать с объектами, хочу передавать их в методы не заботясь кто именно их реализует.

В J8B нет наследования классов - оно сильно усложнило бы кодогенерацию, раздуло код и съело бы такты на анализ. Вместо этого я оставил наследование только для интерфейсов. А вся объектная модель строится через композицию. Это даёт предсказуемые расходы памяти и времени - вы платите ровно за то, что реально используете.

И поэтому мой пример выглядит вот так:

Для сравнения приведу пример подобного опроса на Arduino (язык Си):

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

Вот моя мультиплатформенная реализация класса - маловероятно что она вообще потребует какие-либо изменений при смене одного чипа на другой, например при переходе с ATmega328p на STM8 или ESP32 - написано один раз - будет работать практически везде.

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

И конечно обязательно нужно сказать о цене. Какова цена этим высокоуровневым фичам?

Килобайты ОЗУ, флеша? Компиляция в 5 минут? Сложные настройки компиляции и оптимизации?

Давайте посмотрим. 

Размер занятого FLASH - 2947 байта (9.3%) - это не просто опрос датчика - здесь также множество универсальных библиотек RTOS которые будут использованы повторно в больших проектах. Можно снизить размер прошивки где-то еще на 100 байт указав опцию -Dj8b.bldrApiReuse=true для использования функций бутлоадера убрав их из основной прошивки.

Также мы видим весь процесс настройки проекта и его команды сборки: mvn j8b:run -Parduino-uno

Конечно настройки есть, и их много - их можно прописать в pom файле maven'а или использовать отдельные утилиты сборки, ассемблирования и прошивки. Но для обычной прошивки достаточно только одной команды Мейвена с параметром платформы (необходим установленный vm5277 бутлоадер - что делается тоже легко).

Чуть подробный вывод сборки, по которому можно судить о скорости сборки и прошивки проекта:

Здесь мы видим, что компиляция прошла за 0.254 секунды, а ассемблирование за 0.202 секунды.

А здесь процесс прошивки, который длился 0.267 секунд.

В итоге, с учетом запуска Maven  - сборка выполняется где-то за секунду. Этот процесс можно сильно сократить пользуясь утилитами напрямую (особенно если их собрать в нативный код с помощью GraalVM)

И последнее - расход памяти:

Здесь добавлен вывод System.showDRAMMap(); - показывает занятые биты карты динамической памяти: 011100... т.е. занято 3 блока по 8 байт каждый - 24 байта. Они ушли на заголовок и кучу экземпляра класса DHT11.

В данной конфигурации динамическая память занимает 1755 байт, общий стек - 192 байта, бит карта - 27 байт. Остальное (74 байта) ушло на служебные нужды RTOS.

Хочу также обратить внимание - сейчас у меня в приоритете функционал. Процесс оптимизации - это задача на будущее. Т.е. я планирую в будущем добиться еще лучше показателей.

Еще я хотел бы обратить ваше внимание на производительность. Понятно, что реализация высокоуровневого языка, и тем более ООП языка, требует дополнительных расходов - например процессорного времени. 

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

Например - зачем писать подсчет CRC8 на уровне бизнес логики, когда ее можно оптимально и красиво написать на ассемблере и предоставить прикладнику в виде нативного метода. При этом никто не мешает, при необходимости, написать аналогичный код на j8b.

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

Я могу очень долго рассказывать о своем проекте. И уверен, что многие мои рассказы будут по началу вызывать скепсис. Но чем глубже Вы проникнитесь в мое решение тем интересней оно будет.

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

И напоследок я хочу показать несколько скриншотов основного инструмента разработки на моем J8B языке и ассемблере:

И да, это IntelliJ IDEA 2025.2.6.2 (Community Edition) с моим плагином (пока не поддерживает семантику языка). Также есть плагин для NetBeans - но похоже я не будут его поддерживать дальше, по крайней мере в ближайшее время. Разработка плагина для IDEA гораздо менее трудозатратна.

В общем я просто хотел поделиться своим достижением, я очень рад что уровень проработки всех мои компонентов позволил мне собрать этот код в рабочую прошивку.

Важно! Я несколько месяцев не обновлял проект на GitHub'е.

То, что вы там найдете  - не будет соответствовать этому посту.

Прошу подождать, я планирую в течении недели выложить все свои доработки.

Ссылки:

Сайт-визитка: https://vm5277.ru

GitHub: https://github.com/w5277c/vm5277

P.S. Ждите обновления проекта.