Atmel

Это мое хобби.

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

Вот мое мини реле (ручная пайка, прототип):

Характеристики прототипа:

1) Управление по шине RS-485(две витых пары), поддержка до 128 устройств, допустимое расстояние - сотни метров(зависит от свойств кабеля).

2) Компактный протокол, среднестатистический запрос-ответ выполняется за 15-20 миллисекунд.

3) Уникальная идентификация каждого устройства.

4) Обнаружение всех устройств на шине в течении нескольких секунд.

5) Ведение истории устройством (записывается изменения показаний, рестарт устройства и команды реле с учетом источника команды).

6) Информирование Java контроллера о событиях(изменено состояние реле или показание температуры и прочее) в течении 30 миллисекунд

7) Поддержка порта расширения для датчика температуры(DS18B20) или датчика температуры и влажности(AM2301) или кнопки без фиксации для управления реле или выключатель(кнопку с фиксацией)  и другое

8) Возможность обновления прошивки по шине, функционалом можно воспользоваться прямо в клиенте.

9) Съем потребляемой мощности нагрузкой на базе тока(напряжение не учитывается, используется константа) *(доступно только для реле с датчиком тока)

10) Поддержка таймера с минимальным интервалом в 10 миллисекунд

11) Защита от частого переключения реле (максимальная частота - 2Гц)

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

13) Возможность блокировать каналы управления реле (ручной, шина, таймер, триггер)

14) Размеры, не более, 20х20х35мм (можно разместить в стакане обычной розетки)

15) Потребление(при 5В) менее 20ма/80ма(реле)

16) Поддерживаемое напряжение 5-36В (постоянный ток)

17) Индикация: вкл/выкл реле(синий), опрос датчиков(зеленый), передача по шине(красный)

18) Опрос датчиков - каждые 5 сек, информирование Java контроллера при изменении состояния реле, dT>=1, dH>=3, dW>=200

19) Коммутируемый ток - характеристики реле: 10А(250V AC)

20) Трех контактная колодка: вход, НО, НЗ.

Практически все мои устройства реализованы на базе ATmega168, прошивка реализована полностью на ассемблере на базе операционной системы реального времени core5277.

Протокол передачи данных проприетарный, собственной разработки, базируется на RS-485.

Прошивка проприетарная, но в принципе ничто не мешает залить свою.

P.S. Это устройство требовательно по току к шине, все таки 80мА много. Гирлянду таких не подключишь, есть дугой вариант, немного дороже и чуть больше, но с питанием реле от сети. Позже выложу. Есть и другие варианты исполнения.

P.P.S. Можно добавить поддержку Modbus своим устройствам, но будет ограничение по функционалу.

Сегодня  я решил поделиться хорошей новостью - у меня успешно (без ошибок) отработал очередной пример написанный на моем  языке 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. Ждите обновления проекта.