Как стать автором
Обновить

Комментарии 7

НЛО прилетело и опубликовало эту надпись здесь
Ну вообще-то так и должно быть. Светодиоды показывают уровень наполненности очереди :)
НЛО прилетело и опубликовало эту надпись здесь
впервые с ОС на МК начал работать, когда разрабатывал СКУД — очень заценил сокращение времени и удобство программирования, конечно можно использовать DMA, вложенные прерывания и прочее — это будет более эффективное решение, но и более долгое — не только по времени написания, но и в отладке, (а заказчику то в общем то плевать на идеальный код — ему важно, чтоб работало и как можно быстрее, так если у нас появились нафаршированные памятью и периферией быстрые и дешевые мк — почему бы не упростить себе жизнь). А тут просто раскидал по таскам все — один клавиатуру динамически опрашивает и через очередь просто символы шлет, которые набрали — другая клавиатура будет? нет проблем — меняется только этот таск, не затрагивая основной код. На дисплей другой таск — который тоже — просто принимает сообщение для вывода — как выводить забота этого таска — может быть символьный дисплей, может графический. На пиликанье разное третий таск. Эзернет — четвертый и т.п. — в итоге получается очень гибкая и удобная в отладке система — например попросили еще в скуд RFID Добавить — нет проблем — еще один таск, минимальная модификация остального кода и готово, без использования ОС добавление и изменение различных элементов ранее не оговоренных как правило не очень то и просто сделать. Плюс никто не запрещает пользоваться теми же прерываниями и DMA вместе с использованием ОС — короче RTOS рулит — всем советую, автору плюс)
вы так написали, что «возьмем rtos, нагородим очередей и все полетит»
очереди пораждают не меньше проблем, чем не очереди, всем надо уметь пользоваться. Можно послать много команд и переполнить очереди, контроллер может сгенерить много данных и переполнить очередь, точно так же как и переполнить буфер, который был до этого. По сути то разницы никакой нет, что переполнять. Да и очереди надо обслуживать, например в некоторых ситуациях их надо очищать, выкидывать что-то древнее…

Проблема большого количества данных решается на уровне потока передаваемых данных (USART в данном случае), для чего есть специальные сигналы/команды приостанавливающие передачу.

протоколы, которые позволяют выполнять команды паралелльно сложней. в первом варианте все просто, запрос(з)->ответ(о). А вот во втором (где можно з, з, з, о, з, о, з, з...) уже надо прописывать записимости между командами, что нельзя выполнять какую-то, пока не получим ответ на предыщую. может так получится, что контроллер будет выполнять команды из более приоритетных очередей или будет не успевать их выполнять и уставка на мотор будет запаздывать.

с некоторой сложности проекта, конечно нужно использовать RTOS, ее вообще можно использовать в прицнипе всегда, так как пустая, она практически ничего не весит.

П.С. Ваш программист из примера, который грамотно может расставить мьютексы в сложном приложении, странный. Раз он может сделать это, то уж точно догадается использовать очереди, если этот вариатн будет лучше ) очередь вообще простая структура, ее и без RTOS можно накидать.

Ну я же не написал, что очереди — это серебренная пуля для всего. Так, посеребренная, как и вообще любой инструмент :) И как с любым инструментом, выгод от него должно быть больше, чем затрат.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

Истории