ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
27 апреля
547792 Топик полностью
VVB (19.09.2014 05:32, просмотров: 156) ответил =AlexD= на Вы это бросьте, биглуп прекрасно моделируется на ПиСи, причём можно прогнать весь спектр входных воздействий. Вещьчь абсолютно детерменированная, в отличии от вытесняющей ОСи.
Ну это уже тема отдельного холивара Bigloop vs автоматное программирование vs вытесняющие RTOS Так как меня интересует тема технологий разработки ПО, я выскажу своё мнение. К сожалению, хорошей литературы на русском языке по данной тематике я не встречал. Поэтому читаю на английском. Автор книги "Real-Time C++" утверждает, что подавляющее большинство приложений для встраиваемых систем управления можно написать с использованием bigloop. И утверждает, что опросы разработчиков таких систем показывают такой же результат. Я сильно озадачился, почему он так думает, потом понял, что в его суждениях следует учитывать: 1) он также программирует AVR, где проблемы с ОЗУ и нет места для стека каждой из задач; 2) использует свободное ПО (рассказывает, как из исходников GCC собрать тулчейн с newlib для AVR), то есть идёт путём наибольших сложностей и временных затрат; 3) использует С++, где программировать сложнее чем в С; 4) из-за маломощных МК автор не писал сколь-нибудь сложное ПО. Для интереса нарыл сайт с обзором состояния рынка разработки встраиваемых систем управления http://www.slidesh …adene/embedded-mar1913 так там на стр.28 выясняется, что RTOS использует в 2 раза больше народа чем не использует. Protothreads сродни bigloop в том, что используется общий стек и можно искусственным путём создать видимость многозадачности. Не заниматься вопросами защиты данных по причине одновременного доступа. Такое разделение позволит более чётко выделить функционал и логику какой-то части программы, но приводит к необходимости сохранения состояния используемых переменных в случае ожидания чего-либо. Что в общем-то мешает unit-тестированию (там требуется "очистка" модуля перед запуском каждого теста, и каждый тест независим от другого). Авторы книги "Test-Driven Development for embedded C" не парятся с вопросами RTOS/не RTOS а просто разрабатывают проект с использованием RTOS. Видимо, им даже в голову не приходят другие методики разработки. Авторы даже предлагают реализовать свой уровень API для отвязки от конкретной RTOS. MPU бессмыслен при bigloop/protothreads. Лично я, имея в виду вопросы сертификации, упрощения логики, выделения функционала, возможности снижения класса безопасности при использовании MPU, предпочитаю RTOS. Также RTOS позволяет целиком изолировать чужой код или библиотеки (выносишь всю работу с библиотекой в одну задачу и защищаешься MPU), что недостижимо при других подходах. А ведь библиотеки ещё и в бинарном виде, без исходников (я использую RL-ARM)! Да, отладка bigloop на компе проще по причине отсутствия потоков. Но нет изоляции различных фрагментов кода. Надо иметь множество статических или глобальных переменных для сохранения промежуточных состояний, что есть зло и требует дополнительных усилий при отладке.