caxapa.ru :: Вопрос знатокам uCOS-II

VVB (25.09.2008 15:06, просмотров: 16724)

Вопрос знатокам uCOS-II Задаче надо просыпаться тогда, когда произошло одно из трёх событий: появились данные в одной очереди; появились данные в другой очереди; появились данные в mailbox. Единственное, что мне приходит на ум -- использовать дополнительный сервисный mailbox, специально используемый для просыпания задачи (соответственно, все задачи, кладущие данные в очередь или в mailbox для передачи данных, должны также ложить что-то в сервисный mailbox). Другие способы приведут к overhead'у Возможно ли другое решение без такого извращения?

Ответить

- Большое спасибо за советы! Они помогли получше узнать возможности uCOS. Как говорится, один мозг -- хорошо, а два -- лучше. - VVB(29.09.2008 09:31)
  - имхо это не возможности uCOS, а возможности любой RTOS вообще - Alex B.(29.09.2008 10:14)
- А если сделать так: Алексей Мусин(196 знак., 26.09.2008 18:50)
  - Года 3 назад, когда писал прототип модуля тревог (для самодельной кооперативной многозадачности), не хотел заморачиваться со связанным списком и не было проблем защиты массива. Сейчас появилась необходимость менять, я пошёл по пути наименьших усилий в VVB_(22 знак., 27.09.2008 19:40, )
    - Связный список - штука несложная и красивая к тому же. Юкосовский менеджер памяти - хороший образец экономной реализации. - Алексей Мусин(27.09.2008 19:48)
  - Я бы даже сказал что и ресивер не нужен здесь. AlexandrY(327 знак., 26.09.2008 22:15)
    - согласен =) - Alex B.(27.09.2008 02:23)
- Здесь сервис флагов логичней юзать, а не майлбоксов. - AlexandrY(25.09.2008 22:12)
  - Речь идёт об event flags? Я вчера пытался с ними разобраться (ранее я их не использовал), понял, что event flags не для этого случая. Лучший вариант -- всё-таки сервисный счётный семафор. - VVB(26.09.2008 07:06)
- юзать счетный семафор и неблокирующие сервисы для проверки, чего пришло. Только мне кажется, тут ошибка проектирования - нафига задаче ждать данных из двух разных очередей? - Alex B.(25.09.2008 15:12)
  - будет что-то типа упорядоченного списка, и задача обслуживает запросы на удаление/добавление элементов в список (меняет сам список). Есть другой вариант? VVB(186 знак., 25.09.2008 15:19)
    - ну так а что, через одну очередь нельзя запросы передавать? - Alex B.(25.09.2008 15:19)
      - Если точнее, то нужно обслуживать не список, а массив из указателей на объекты, размещаемые в флэше. - VVB(25.09.2008 15:23)
        
        Может, это не массив, а объектный пул? - Vit(25.09.2008 20:37)
      - через очереди передадаются указатели - VVB(25.09.2008 15:20)
        
        я знаю, и что? примерный код можете привести. Зачем две очереди-то? - Alex B.(25.09.2008 15:28)
        
        Код в процессе написания. Лучше словами объясню. VVB(1429 знак., 25.09.2008 15:48)
        
        А что мешает сделать так: Alex B.(262 знак., 25.09.2008 16:17)
        
        Я думал об этом. Минус: резервирование максимум 2*8*N байт ОЗУ. 2 -- потому что две команды, 8 -- размер структуры, N -- число тревог. При числе тревог 100 получаем перерасход 1600 байт ОЗУ. VVB(442 знак., 26.09.2008 07:04)
        
        вы чо, какой перерасход? По-моему вы не понимаете, чего и как там работает... Alex B.(657 знак., 26.09.2008 10:09)
        
        описанную вами структуру надо где-то хранить и защищать (это критические данные). VVB(1164 знак., 26.09.2008 11:15)
        
        действительно не понимаете... Зачем статически-то структуру объявлять? Alex B.(2265 знак., 26.09.2008 12:59)
        
        При условии использования сервиса RTOS "блоки памяти фиксированного размера" это лучшее решение, согласен (и сразу понимал суть). VVB(480 знак., 26.09.2008 14:48)
        
        дык и с одной очередью задачи ничего не будут знать друг о друге Alex B.(514 знак., 26.09.2008 15:19)
        
        А еще, как написал AlexandrY, действительно проще использовать events Alex B.(190 знак., 26.09.2008 13:16)

Микроконтроллеры