Jump to content

    

&Rey

Новичок
  • Content Count

    3
  • Joined

  • Last visited

Everything posted by &Rey


  1. Возможно данный момент уже исправлен в новой версии документации, но отмечу, что есть несоответствие в описание на ОС версии 5, п.4.2.3 и коде ОС v5.1 в части именования идентификаторов перечисления стартового состояния процесса TProcessStartState: в примере п.4.2.3 документации указан префикс идентификаторов «ss», а в коде (scmRTOS_defs.h) – префикс «pss».
  2. Предполагаю использовать мьютекс для организации доступа к SPI. Т.е. при вызове функций записи или чтения через SPI доступ к интерфейсу выполняется через lock()/unlock(). В тоже время до запуска ОС через SPI необходимо сконфигурировать внешнее устройство используя те же функции записи/чтения (вызывающие lock()/unlock()). Корректно ли выполнять вызовы lock()/unlock() до запуска OC? Требуется ли каким-либо образом привести объект-мьютекс в исходное состояние перед запуском ОС? Заодно, прошу прокомментировать данную ситуацию в связи с другими сервисам межпроцессорного взаимодействия: событиями, сообщениями.
  3. Впервые применяю rtos в проекте, поэтому пока не в полной мере для меня понятен стиль программирования при её использовании. Без ОС применял следующий подход: в main сначала выполнялась инициализация периферии микроконтроллера, затем инициализация внешних по отношению к МК устройств и далее в цикле выполнялся конечный автомат(ы) состояний. Видимо сложно сразу отказаться от того к чему привык и текущий вариант у меня получился следующий. В main выполняется инициализация периферии контроллера, в частности SPI, затем через SPI инициализируется, например, графический контроллер и затем запускается ОС в процессах которых выполняется требуемая функциональность. Работа с графическим контроллером ведётся через SPI из нескольких процессов, поэтому выполняется через семафор, т.е. вызовом функций записи/чтения по SPI, начинающихся lock и заканчивающихся unlock соответствующего семафора. Эти же функции сейчас используются для конфигурирования графического контроллера до запуска ОС на этапе инициализации. Варианты с двумя копиями таких функций с lock/unlock и без, или дополнительной проверкой не кажутся правильными. Поэтому и возник вопрос: к чему может приводить вызовы функций сервисных объектов ОС, в частности семафора, до запуска ОС. Практика показывает, что, предварительно, по крайней мере, для семафора вызовы lock/unlock до старта ОС не к чему внешне заметному не приводят - после старта ОС всё работает логично. Потом, ради интереса посмотрю, что в данной ситуации происходит внутри ОС. В итоге, скорее всего, воспользуюсь советом dxp и перемещу код использующий вызовы функций сервисов ОС внутрь одного из процессов до перехода в цикл.