Эта моя первая статья и скорее всего я непонятно написал, раз возникают такие комментарии.
Об усложнении ПО при использовании такого подхода я написал в самом конце статьи в пункте «Недостаток». Этот момент я не обходил стороной, ни просто так, ни деликатно :)
И последовательность выполнения всегда задана, что тоже может очень быстро начать мешать.
Это уже зависит от автора кода. Если последовательность в автомате для какой-то одной задачи важна, то у задач разной функциональности последовательность не строгая.
Для простой системы — подойдет, но чем сложнее система — тем проблемнее ее будет делать в терминах квантов времени, машин состояний и последовательности вызовов.
Я понимаю, что не всем по душе усложнение ПО. Но при достаточном опыте работы с таким подходом проблем не замечаешь.
Было бы интересно услышать тут для какого размера кода автор использует свой подход.
Один из случаев.
Периферия: RTC, 2xEEPROM, двухстрочных дисплей, ЦАП, датчик температуры, Bluetooth-модуль.
Датчики напряжения и тока на три фазы (6 датчиков) на АЦП, фильтруем сигнал фильтром третьего порядка, считаем RMS у каждого, расчет угла нагрузки на каждую фазу. Контроль этих значений (порядка 20 защит). Запись значений параметров при их изменении (пишем где-то 250 параметров), а так же отдельно запись списка параметров при срабатывании одной из защит (на кажадую сработавшую защиту около 160 байт в память).
Прием сигнала с ИК ПДУ: есть древовидное меню, где можно глянуть примерно 250 параметров.
Коммуникация: Modbus RTU и Bluetooth.
Там еще много чего есть, лень расписывать :)
Для современных микроконтроллеров, как например stm, такого нет.
Почему нет? Там RTOS вдруг вшита в контроллер и работает на аппаратном уровне? Или все проблемы можно решить поставив более мощное железо?
Наоборот), одна из фишек RTOS в том, что её использование придаёт программе логичную структуру, и упрощает написание), просто нужно изучить все эти «Мьютексы, семафоры, приоритеты», это не сложно.
Я написал, что для меня это не просто, а ты вдруг счел, что наоборот? :)
В неумелых руках такие фишки могут превратиться в неуправляемого нелогичного монстра, особенно если будет over9000 семафоров и т.п.
Для того FreeRTOS и придумали, она получше многих платных будет.
Поэтому я написал не «все», а «некоторые :)
В общем пока никто ещё не написал толком почему не стоит применять RTOS.
Альтернативным я его назвал именно после прочтения хорошего материала «Два подхода к проектированию ПО для embedded».
Само собой сложность ПО возрастает. Тут либо экономия ресурсов без операционки, но с затратами времени на разработку, либо экономия времени разработки ценой ресурсов контроллера.
Не правильно выразился :) В конкретном примере на псевдокоде он может и пишет, да и ладно. Целью статьи не служил рассказ про особенности периферии (можно и FRAM воткнуть) или про особенности конкретного контроллера. Я рассказывал про подход разработки ПО.
Если задачек 5, то пускай выполняются последовательно. А если 50, то попробуй уследи за ними потом.
Драйвер EEPROM не пишет каждую секунду. Он ожидает. Пришел запрос — пишем. Не пришел — ждем.
Почему? В день выхода WP8 все смартфоны на WP7 самоуничтожатся?
Об усложнении ПО при использовании такого подхода я написал в самом конце статьи в пункте «Недостаток». Этот момент я не обходил стороной, ни просто так, ни деликатно :)
Это уже зависит от автора кода. Если последовательность в автомате для какой-то одной задачи важна, то у задач разной функциональности последовательность не строгая.
Я понимаю, что не всем по душе усложнение ПО. Но при достаточном опыте работы с таким подходом проблем не замечаешь.
Один из случаев.
Периферия: RTC, 2xEEPROM, двухстрочных дисплей, ЦАП, датчик температуры, Bluetooth-модуль.
Датчики напряжения и тока на три фазы (6 датчиков) на АЦП, фильтруем сигнал фильтром третьего порядка, считаем RMS у каждого, расчет угла нагрузки на каждую фазу. Контроль этих значений (порядка 20 защит). Запись значений параметров при их изменении (пишем где-то 250 параметров), а так же отдельно запись списка параметров при срабатывании одной из защит (на кажадую сработавшую защиту около 160 байт в память).
Прием сигнала с ИК ПДУ: есть древовидное меню, где можно глянуть примерно 250 параметров.
Коммуникация: Modbus RTU и Bluetooth.
Там еще много чего есть, лень расписывать :)
Почему нет? Там RTOS вдруг вшита в контроллер и работает на аппаратном уровне? Или все проблемы можно решить поставив более мощное железо?
Я написал, что для меня это не просто, а ты вдруг счел, что наоборот? :)
В неумелых руках такие фишки могут превратиться в неуправляемого нелогичного монстра, особенно если будет over9000 семафоров и т.п.
Поэтому я написал не «все», а «некоторые :)
Статья была не про это.
Само собой сложность ПО возрастает. Тут либо экономия ресурсов без операционки, но с затратами времени на разработку, либо экономия времени разработки ценой ресурсов контроллера.
Драйвер EEPROM не пишет каждую секунду. Он ожидает. Пришел запрос — пишем. Не пришел — ждем.