Comments 20
Что ж, расскажу о нем в следующей публикации. Хотя там ничего необычного нет: ардуино нано, esp8266 как сетевой интерфейс, горстка датчиков, набор из 8 реле, управляемых по i2c, и четыре аналоговых канала, тоже управляемых через i2c ЦАП (тут пришлось извратиться, т.к. у них всего два адреса). Силовые каналы для управления мощными светодиодами светильника сделаны на китайских CC/CV преобразователях, у которых выдраны потенциометры тока, и вместо них подключены выходы ЦАПов. Преобразователи жутко грелись уже на 600 мА (зря я поверила китайским 5 амперам), поэтому вместе с ЦАПами вынесены в корпус светильника и там приляпаны на термопасту охлаждаться вместе с.
Тоже баловался переключателем задач для Bascom AVR. Дальше дело не пошло.
Тестировал виртуально всё.
К сожалению, это так. Ни разу не призываю к пиратству, но разработчики могли бы назначить более адекватный ценник для некоторых стран — тогда, глядишь, и не пришлось бы вносить маленькую поправочку в одну из dll.
У вас, похоже, вытесняющий механизм, когда диспетчер принудительно по таймеру переключает задачи с сохранением контекста; а данная ОС — кооперативная, тут задачи сами решают, когда можно отдать управление. Преимущество — не надо сохранять контекст.
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» или просто добавить менеджер памяти, контролирующий оставшееся место (или продумать общую организацию переменных). Может получится целый отдельный модуль.
Вообще сложность всей реализации сводится к проблеме: скомпилированный и зашитый код, нельзя поменять в ходе выполнения. Это как образ — он такой как есть. Но можно попытаться его (код) обойти в процессе выполнения, если он с ошибкой.
спасибо за ценное замечание! согласна. ну, можно ограничиться короткими строками, которые наверняка не вылезут за границы. и в реальном коде, конечно, надо будет пересчитать размеры стеков и фрейма по упомянутой вами методике и средствами баскома. а вообще, это скорее проблема компилятора. и да, именно поэтому для сообщений использован указатель, а строки — лишь как дополительная фича.
Однако Вы можете использовать идеи, реализованные в AquaRTOS, для написания собственной ОС под STM.
ОС реального времени AQUA RTOS для МК AVR в среде BASCOM AVR