[haker_fox 60]

Сдравствуйте! Объясните пожалуйста дураку целесообразность применения RTOS на AVR.

Заранее спасибо.

Если бы спросили меня лично, я бы ответил так:

1. Мне нужно "одновременно" опрашивать клавиатуру, управлять дисплеем, крутить два шаговых двигателя и общаться с ПК по RS-232.

2. Заморачиваться разделением времени между процессами самостоятельно не хочется. Тем более что я уже пробывал это делать. Использовались таймеры, оператор switch(...) и др. Получается достаточно хлопотно, хотя ресурсы МК экономятся изрядно.

3. ОС же позволяет сосредоточится только на создании и программировании соответствующих задач для работы с указанной выше периферией (это лично мое мнение).

[spf 0]

Объясните пожалуйста дураку целесообразность применения RTOS на AVR.

Для начала стоит почитать темы в которых встречается слово RTOS, чтоб не возобнавлять религиозные войны...

[zltigo 0]

чтоб не возобнавлять религиозные войны...

Полностью поддерживаю...

[sz36 0]

Объясните пожалуйста дураку целесообразность применения RTOS на AVR.

Писать попроще (а иногда и намного проще). Если процессор выполняет несколько асинхронных по отношению друг к другу задач, то без RTOS для каждой задачи нужно создавать свою машину состояния, и при этом следить, чтобы не зациклиться ни в какой фазе слишком надолго. При более-менее сложных задачах это может оказаться весьма проблематичным. А с RTOS все просто - каждая задача пишется отдельно, по линейному алгоритму. И если, например, какому-то из процессов надо ждать события, допустим, ответа от другого устройства, и так, чтобы остальные процессы работали - ничего страшного, ждем и все. А без RTOS пришлось бы выходить, и организовывать обслуживание других процессов, каждый из которых тоже мог ждать события, но другого, в общем, сплошной геморрой.

Сам я scmRTOS использую, в общем, доволен, хотя и подрихтовать ее пришлось. Я как пришел к необходимости RTOS - был проект, рабочий, но потребовалось расширить функциональность, добавить еще задачу, асинхронную ко всем остальным, коих и так штук пять было. И пришло осознание, что впихивать во все циклы обслуживание еще одного внешего устройства немыслимо, запутаюсь. Поставил scmRTOS, объем кода, правда, не уменьшился, но он стал гораздо проще и понятнее, и еще один процесс добавился без проблем.

[zorromen 1]

Люди дайте scmRTOS то немогу найти и описание к ней........

[ReAl 0]

Люди дайте scmRTOS то немогу найти и описание к ней........

http://scmrtos.sourceforge.net/

http://sourceforge.net/projects/scmrtos/

[dmitry_volkov 0]

Господа!

 

Возможно я слишком резко высказываюсь, но это мое мнение; итак, все авр-ки - это не стековые машины, это микроконтроллеры с последовательным выполнением команд (переходы, условия и т.д. не в счет), которые не имеют аппаратной реализации многозадачности. Потому, полагаясь на чужой опыт создания многозадачной ос, псевдо, кстати, мы вынуждены свои "кусочки" алгоритмов функций привязывать к не всегда удобной обработке той самой многозадачности, - но это только мое мнение. Думаю, что авр-ки создавались изначально не для многозадачности, а для разделенным по времени или условию программам и подпрограммам. Конечно, более геморойно написать обслуживание нескольких устройств "одновременно", но согласитесь, что размер и мощности камня не безграничны, потому, если кто-то ориентируется на авр, то есть некоторые границы тех же многозадачных ос, либо есть вариант перехода на свою собственную ос, либо на другие контроллеры.

 

Это все полемика, но для "быстрого" написания программ обслуживания нескольких устройств и т.д. подойдет и RTOS, а для конечного продукта, тем более массового производства, нужно что-нибудь свое, это, повторяюсь, только мое мнение.

 

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

[IgorKossak 0]

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

Потому и результат вполне предсказуемый.

Я в таких случаях предпочитаю общаться с профильными специалистами.