ОС реального времени AQUA RTOS для МК AVR в среде BASCOM AVR

[Javian]

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

[Cirno_9]

Что ж, расскажу о нем в следующей публикации. Хотя там ничего необычного нет: ардуино нано, esp8266 как сетевой интерфейс, горстка датчиков, набор из 8 реле, управляемых по i2c, и четыре аналоговых канала, тоже управляемых через i2c ЦАП (тут пришлось извратиться, т.к. у них всего два адреса). Силовые каналы для управления мощными светодиодами светильника сделаны на китайских CC/CV преобразователях, у которых выдраны потенциометры тока, и вместо них подключены выходы ЦАПов. Преобразователи жутко грелись уже на 600 мА (зря я поверила китайским 5 амперам), поэтому вместе с ЦАПами вынесены в корпус светильника и там приляпаны на термопасту охлаждаться вместе с.

[Javian]

Температура, датчик света. Остальное что-то необычное типа измерения pH?

[Cirno_9]

ага, рН, прозрачность воды, уровень (верх, низ), протечка.

[Ryppka]

Конечно, это чистая вкусовщина, но код, мягко говоря, выглядит непривычно и, как бы это сказать, не радует глаз…

[ZEN_LS]

Просто он на бэйсике. Я когда то начинал с такого, помню в 9-м классе, в 11-м уже начал писать на си. Про BASCOM AVR вспомнил только один раз в своей статье). Еще помню шил тиньку 2313, через программатор Громова, занимало минуты 2-3. Эх славные времена были (2011).

[Cirno_9]

видите, как замечательно: я вернула вас в дни вашей юности, к теплым воспоминаниям и т.д.

[ViacheslavMezentsev]

Жаль только, что Bascom AVR платный для таких применений (когда объём кода больше 4К, насколько я помню).
Тоже баловался переключателем задач для Bascom AVR. Дальше дело не пошло.
Тестировал виртуально всё.

[Cirno_9]

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

[Cirno_9]

У вас, похоже, вытесняющий механизм, когда диспетчер принудительно по таймеру переключает задачи с сохранением контекста; а данная ОС — кооперативная, тут задачи сами решают, когда можно отдать управление. Преимущество — не надо сохранять контекст.

[madf]

«у дураков мысли сходятся» :) отличный ход мыслей, но есть ряд глобальных «нюансов»:

1. у вас идет динамическое объявление функций вида:

declare function OS_GetMessageString(byval hTopic as byte) as string
declare function OS_PeekMessageString(byval hTopic as byte) as string

А в коде везде прописана классическая настройка:

$hwstack = 48
$swstack = 48
$framesize = 64

Можно легко словить порчу переменных (переполнение памяти).
Почитайте в Баскоме как нужно рассчитывать настройку этих переменных (их организацию).
Сам автор Баскома не раз об этом предупреждал (нельзя в динамических функциях предсказать конечный результат). Я по этой причине, в своих проектах ушел от использования этого функционала Баскома и с тех пор нет никаких проблем подобными видами «глюков».

2. «если пошла такая пьянка», то можно и нужно как-то заморочиться с контролем переполнения памяти. Боюсь всё это в итоге сведётся к «проще написать эмуль AVR внутри AVR с внешним обвесом (памяти и прочего)». :D Хотя можно что-то попробовать сделать с манипуляциями «OVERLAY» или просто добавить менеджер памяти, контролирующий оставшееся место (или продумать общую организацию переменных). Может получится целый отдельный модуль.

Вообще сложность всей реализации сводится к проблеме: скомпилированный и зашитый код, нельзя поменять в ходе выполнения. Это как образ — он такой как есть. Но можно попытаться его (код) обойти в процессе выполнения, если он с ошибкой.

[Cirno_9]

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

[linux_art]

Жуткое расточительство для весьма ограниченных по ресурсам железок…

[Cirno_9]

Хотелось бы обоснования ваших слов. В стандартной Ардуино Нано (328Р) при компиляции со всем блэкджеком ОС занимает около 20% памяти программ. Критичные куски кода задач выполняются без переключения контекста, ОС в это время машинных тактов практически не потребляет (отрабатываются только задержки и проверяются сигналы). Кроме того, условия использования ОС описаны в самом начале статьи: когда требуется достаточно сложный код. И далеко не факт, что с использованием конструкции «суперцикл + прерывания (в которых тоже должны будут отрабатываться те же самые задержки) + флаги» вы получите более компактный и быстрый код. А уж про его читаемость и удобство модификации и речи нет.

[linux_art]

20% памяти на накладные расходы это очень много. В сложных задачах обычно либо каждый байт выкраивать приходится либо переходить на контроллер с большим количеством памяти.

[avf1906]

тупиковый путь экономить каждый байт. У меня недавно был один проект, попытался использовать ИАР для STM8 с ограничением на 8к. Код конечно утоптал, 26 байт осталось. Но когда захотелось добавить фичу, уже не полезло. В итоге с добавлением разных фич код уже вырос до 11к и может еще вырасти.

[Cirno_9]

К сожалению, насколько мне известно, компилятор Bascom AVR весьма специфичен и заточен под чипы Atmega и жестко привязан к их архитектуре. Его преимущество — встроенная поддержка аппаратуры Atmega и популярного железа и протоколов, а также довольно быстрый и компактный код (без извращений лучше выйдет, наверное, только на ассемблере). Теоретически, правда, не исключена возможность генерации кода под иные архитектуры, т.к. под каждый чип семейства Atmega компилятор использует файл-конфиг, и если в нем поковыряться, то вдруг окажется, что он может и под другие чипы компилить код? Я не копала в эту сторону и думаю, что вероятность невелика.
Однако Вы можете использовать идеи, реализованные в AquaRTOS, для написания собственной ОС под STM.

[vvzvlad]

Боги, Bascom! Как давно я его не видел.