scmRTOS - первые шаги, как правильно расшарить ресурсы? Опции

[sonycman]

Доброго времени суток!

Вот стало мне нечего делать, и потянуло попробовать в первый раз какую нибудь операционку.
Остановился пока что на scmRTOS - с виду очень простая и красиво написанная система.

Скачал порт на STM32 - немного поправить и должно заработать на LPC1768.

Думаю, как правильно работать разными процессами с такими ресурсами, как FatFs диск на карте памяти и ЖКИ.

Интересно, можно ли в последней 0.08 версии FatFs просто установить флаг конфигурации REENTRANT и использовать в функциях sync_obj() мьютекс OS для синхронизации?

[AHTOXA]

Вот стало мне нечего делать, и потянуло попробовать в первый раз какую нибудь операционку.
Остановился пока что на scmRTOS - с виду очень простая и красиво написанная система.

Отличный выбор

Интересно, можно ли в последней 0.08 версии FatFs просто установить флаг конфигурации REENTRANT и использовать в функциях sync_obj() мьютекс OS для синхронизации?

Конечно можно. Мутекс проще создать статически:

Код

OS::TMutex ff_mutex;

extern "C" int ff_cre_syncobj(BYTE, int*)    { return true; }
extern "C" int ff_del_syncobj(int)        { return true; }
extern "C" int ff_req_grant(int)        { ff_mutex.Lock(); return true; }
extern "C" void ff_rel_grant(int)        { ff_mutex.Unlock(); }

[sonycman]

Конечно можно. Мутекс проще создать статически:

Спасибо! Значит, я на правильном пути .

А как обычно реализовывают работу с ЖКИ под ОС?
Тоже городить мьютексы? Или проще отдать эту задачу одному единственному процессу, а другие будут, в случае надобности, слать сообщения с нужными данными?

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

ЗЫ: извиняюсь, оказывается, на форуме есть соответствующая операционным системам тема.
Наверное, стоит перенести топик туда?

[AHTOXA]

А как обычно реализовывают работу с ЖКИ под ОС?
Тоже городить мьютексы? Или проще отдать эту задачу одному единственному процессу, а другие будут, в случае надобности, слать сообщения с нужными данными?

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

И по поводу сообщений - как происходит с ними работа?
Я так понимаю, что сообщение - просто некий контейнер, который выполняет функцию промежуточного хранения или транспортировки данных между процессами.

Да.

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

Да, может. Чтобы этого не произошло, нужно отправлять сообщения более приоритетному процессу. Либо использовать очередь сообщений.

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

Тогда очередь, да. Например, OS::channel<>.

Надо ли обрамлять макросом TISRW все подряд обработчики прерываний, или только те, в которых используются сервисы ОС?

Только те, где сервисы.

И имеет ли значение приоритет прерывания SYS_TICK, на котором висит планировщик?
Ведь на кортексах по умолчанию работают вложенные прерывания.

Да, его приоритет минимальный, это гарантирует, что он выполняется после всех прерываний (не является вложенным). (Приоритет задаётся в OS_Target_asm.S)

[sonycman]

Да, его приоритет минимальный, это гарантирует, что он выполняется после всех прерываний (не является вложенным). (Приоритет задаётся в OS_Target_asm.S)

Спасибо за помощь!
С меня пиво
Буду продолжать осваивать.

К сожалению, одновременно приходится осваивать IAR (до этого работал только в Кейле), поэтому всё получается совсем не быстро

[AHTOXA]

С меня пиво

К сожалению, одновременно приходится осваивать IAR

Хм. Я думал, что GCC. Потому что для LPC17xx под IAR есть примерчики, и ничего допиливать не надо

[sonycman]

Хм. Я думал, что GCC. Потому что для LPC17xx под IAR есть примерчики, и ничего допиливать не надо

Ну я же не буду пустую ось, как в этих примерах, запускать.
Да и камень у меня другой. Плюс заготовка проекта под Кейл.
Вот и переношу

Кстати, вопрос не по теме, конечно, но вдруг кто подсобит.

Привык работать с исходником в среде SlickEdit - нравится подсветка цветом и, особенно, автоподстановка переменных\имён регистров и всего и вся в этом роде.

Набил пару первых знаков имени - а дальше просто выбираешь из раскрывшегося списка.
Очень удобно работать со структурами или классами - все члены сразу видно, ничего не надо вспоминать, два нажатия на кнопку - и длинное имя функции\объекта\переменной на месте.
Не представляю, как люди могут работать в простых редакторах без автоподстановки (типа голых кейла или иара) - ужас просто.

Но не всё так радужно - ИАРовские макросы под LPC17xx вида NAME ## _bits слик не понимает, к сожалению.
Приходится тащить с собой более простой "и понятный" LPC17xx.h из кейла.

Может, есть какой редактор, который и с этими макросами (##) прекрасно справляется?