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

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

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

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

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

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

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

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

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

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

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

Moderator: Перенес.

scmRTOS - система с приоритетным планировщиком. Соответственно, вы должны предусмотреть, чтобы высокоприоритетный процесс на захватил систему навсегда. Вообще подход должен быть таким - оповестил нужный процесс тем или иным образом, что он должен чего-то сделать, он это что-то быстренько сделал и отдал управление. Кому процессу какой приоритет задать должны вы решить, исходя из вашей задачи.

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

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

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

Ещё не совсем разобрался с организацией прерываний.

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

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

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


Да.

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


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

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


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

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

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

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

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

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

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

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

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

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

Eclipse?

Ну самое правильное на эти уродские IARовские прибамбасы наплевать раз и навсегда, ибо писать подобную фигню:

даже если-бы она была переносима, вместо ОДНОЙ строчки неразумно. А если написаны нормальные дефиниции битов, то ими в отличии от этой красатульки, можно пользоваться ВСЕГДА.
А во-вторых слик, как и эклипсе, в исходниках - можете и написать под себя .

Да, надо в очередной раз попробовать очередную версию Эклипса


В случае работы с несколькими битами одного регистра конечно, не стоит пользоваться такими макросами.
Получается отвратно, учитывая, что volatile вообще не оптимизируется.

Но в случае единичных битов - нет проблем.

Всё равно понравился ИАРовский хидер под LPC1766, в отличие от сырого кейловского, в котором вообще отсутствуют определения битов

Вроде получается, контроллер сконфигурировал и пример запустил, сейчас потихоньку адаптирую под многозадачность интерфейс ЖКИ и т.д.

А как поступать с вызовами библиотечных функций типа sprintf(), memalloc() и т.д.?
Неужели их тоже надо обрамлять мьютексами?
Или критич. секциями?

Работу с кучей вернее всего придётся защитить, а вот всякие printf()?

Что-то сразу не получилось найти инфу по этому поводу

printf() придется в любом случае, вы же не хотите получить кашу в stdout? Всякие *s*printf() - в зависимости от реентерабельности.