О проекте: Пишем один код - собираем на разные 8 бит МК!

https://vm5277.ru - это универсальное решение для embedded-разработки, которое позволяет сократить время создания прошивки для 8 бит микроконтроллеров в разы.

Как это работает?

• Пишешь код на Java подобном языке (чистое ООП, без головной боли с указателями и не читабельным кодом)
• Компилятор автоматически генерирует оптимизированный ассемблерный код под выбранную платформу
• Код работает поверх легковесной RTOS, написанной на ассемблере для максимальной производительности 
• Ассемблер-сборщик финализирует проект в бинарный файл прошивки

Что входит в решение:

• Высокоуровневый компилятор с Java подобным синтаксисом
• Максимально оптимизированная RTOS, целиком на ассемблере для каждой платформы
• Унифицированные драйвера - один API для UART, SPI, I2C, GPIO на всех МК
• Стандартные библиотеки (Runtime): Базовые типы данных (Float, String), математические функции (Math), работа с памятью и другие абстракции, не зависящие от платформы.
• Драйверы верхнего уровня (High-Level Drivers): Унифицированные API для работы с периферийными устройствами: датчиками (I2C/SPI), дисплеями, SD-картами, беспроводными модулями (ESP8266, Bluetooth).

Ключевые преимущества:

• Скорость разработки: Создавайте функционал на высокоуровневом  языке быстрее, чем на Си
• Производительность: RTOS и драйверы оптимизированы до уровня чистого ассемблера, экономя каждый байт и такт
• Переносимость: Переход с AVR на PIC или STM8 - дело нескольких правок, а не изучение и адаптация библиотек

Проект находится на ранней стадии, но я активно над ним работаю. Уже можно видеть, как высокоуровневый код на Java-подобном языке превращается в чистый и эффективный ассемблер! Это ещё не итоговый вариант, но прогресс уже есть.

Что уже работает в этом примере:

• Наследование интерфейсов: Test implements Number
• Динамическое выделение памяти: оператор new
• Полиморфизм: вызов метода через переменную интерфейсного типа (Number.toByte())
• Проверка типа во время выполнения: оператор is (аналог instanceof)
• Полноценная работа с объектами: конструкторы, методы, поля.
• Интеграция с RTOS: вызов системных функций (System.out).

Также приведу одну из функций RTOS(код сырой, может содержать ошибки)

Ключевые фрагменты сгенерированного ассемблерного кода:

1. Метаданные класса:
Компилятор автоматически формирует структуру для поддержки RTTI (Run-Time Type Information), необходимую для instanceof.

2. Динамическое создание объекта в куче:
Код конструктора new Byte(0x08) транслируется в вызов менеджера динамической памяти (os_dram_alloc) и инициализацию полей.

3. Проверка типа (is / instanceof):

Оператор if(b1 is Byte) компилируется в вызов процедуры j8bproc_instanceof_nr, которая проверяет метаданные объекта.

4. Полиморфный вызов метода:

Вызов b1.toByte() через интерфейс Number преобразуется в универсальный механизм поиска и диспетчеризации метода.

5. Интеграция с системными сервисами:

Вывод в "консоль" (System.out) — это вызов системного сервиса ОСРВ.

Что это значит?

Это доказывает, что подход vm5277 работоспособен. Мы можем писать на высокоуровневом ООП-языке, а под капотом получать код, который:

• Эффективно использует память: объекты размещаются в куче, метаданные компактны.
• Сохраняет производительность: ключевые операции (выделение памяти, проверка типов) вынесены в оптимизированные ассемблерные процедуры.
• Является переносимым: этот же Java-код, после завершения работы над платформами, сможет работать на PIC и STM8 (ограничений почти нет).

Я продолжаю работать над проектом универсального тулкита разработки программ для 8-битных микроконтроллеров.

Моя цель — создать единый ООП-язык (в стиле Java) с унифицированным API и HAL для 8-битных МК (AVR, STM8, PIC).

Хорошо подходящий слоган: «Написано один раз — работает на большинстве МК» (конечно, если это вообще возможно).

Сейчас я разрабатываю методику выделения памяти для примитивов внутри метода и его блоков (условные операторы, циклы и т. п.).

Основные два подхода:

- Динамическое выделение памяти на основе битовой карты блоков памяти.

- Выделение памяти непосредственно в стеке.

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

Судя по всему (подсказка от DeepSeek), всем известный язык C статически выделяет блок в стеке при входе в функцию, при этом:

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

- не умеет и не позволяет освобождать выделенную память до завершения функции;

- использует дополнительный код для выделения и освобождения блока в стеке.

Теперь я понимаю, почему разработчики на C для МК с малыми ресурсами используют глобальные переменные.

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

Это действительно огромная трата RAM.

Разрабатывая своё решение, я планирую использовать выделение памяти в стеке только для переменных метода (без учёта блоков), а для каждого блока — отдельную процедуру выделения памяти.

Это позволит существенно экономить RAM.

Но, к сожалению, увеличит размер прошивки, так как для каждого блока потребуется около 16 слов для 16-битного SP и около 5 слов для 8-битного SP (вероятно для 16 бит я вынесу данный код в процедуру, уменя есть подобное решение в core5277).

И это необходимо для высокоуровневого ООП-языка.

Я также планирую добавить опцию в компилятор, позволяющую выбрать, что экономить: RAM или FLASH+CPU.

При выборе FLASH+CPU память будет выделяться статически, как в C.

В общем, проблема C ясна:

Для каждой функции выделяется блок в стеке под все переменные (даже неиспользуемые), и освобождается он только при завершении функции.

В ассемблере же:
Программист сам решает, как использовать память при входе в функцию.
Часто память вообще не выделяется — многие значения хранятся в регистрах.
То, что не помещается в регистры, можно сохранить одной инструкцией PUSH и восстановить POP.
Можно закрепить ячейку RAM за функцией и использовать её без дополнительных накладных расходов.
Даже если использовать аналогичные C-подобные макросы, программист, скорее всего, будет выделять память для конкретных блоков, а не резервировать максимальный объём для всей функции.
При этом он будет эффективно использовать регистры.

Вот такая огромная разница в оптимизации между ассемблером и C.

К сожалению, я тоже не смогу добиться максимальной оптимизации (как в ассемблере) в своём компиляторе.

НО! В моём тулките это не так критично, как могло бы быть.
Дело в том, что множество низкоуровневых алгоритмов будет реализовано и оптимизировано на ассемблере.
Драйверы также будут на ассемблере и будут использовать эти алгоритмы.
Язык высокого уровня будет их активно применять (часть — прозрачно через кодогенератор компилятора, часть — через явные вызовы).

GitHub проекта: https://github.com/w5277c/vm5277

Визитка проекта: http://vm5277.ru/

P.S. Прошло 3 недели, за две из них я набросал AVR-ассемблер (не полностью, но его функционала и гибкости достаточно для текущих нужд тулкита).

Конечно, я был бы рад использовать avra, но он содержит ошибки, из-за которых не получается собирать мои проекты.

P.P.S. Я сменил лицензию с GPLv3-or-later на Apache-2.0. Судя по всему, это допустимо, так как на данный момент я являюсь автором всего кода в проекте.