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]

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

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

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

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

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

[aaarrr]

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

Moderator: Перенес.

[sergeeff]

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

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

[sonycman]

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

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

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

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

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

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

[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 из кейла.

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

[AHTOXA]

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

Eclipse?

[zltigo]

Но не всё так радужно - ИАРовские макросы под LPC17xx вида NAME ## _bits слик не понимает, к сожалению.

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

CODE

    S0SPCR_bit.CPOL = 1;     
    S0SPCR_bit.CPHA = 1;        
    S0SPCR_bit.BITENABLE = 1;
    S0SPCR_bit.BITS   = 9;    
    S0SPCR_bit.MSTR = 1;

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

[sonycman]

Eclipse?

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

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

Код

    S0SPCR_bit.CPOL = 1;     
    S0SPCR_bit.CPHA = 1;        
    S0SPCR_bit.BITENABLE = 1;
    S0SPCR_bit.BITS   = 9;    
    S0SPCR_bit.MSTR = 1;

даже если-бы она была переносима, вместо ОДНОЙ строчки неразумно.

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

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

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

[sonycman]

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

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

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

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

[aaarrr]

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

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

[sonycman]

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

А как узнать, к примеру, о реентерабельности определённых функций библиотеки ИАРа?
Вроде нашёл среди inc. файлов конфиг. файл DLIB с метками multi-thread...

Наверное, надо спросить в соотв. теме
Вероятно, библиотеки можно как то конфигурировать.

Сорри, я с такими вещами ещё дел не имел, поэтому такие глупые вопросы

[aaarrr]

А как узнать, к примеру, о реентерабельности определённых функций библиотеки ИАРа?

Я бы советовал начать с документации. Такие вещи указываются в обязательном порядке.

[sonycman]

Я бы советовал начать с документации. Такие вещи указываются в обязательном порядке.

Спасибо, нашёл, стоило немного под напрячься!
После трудного дня легче спросить на форуме, чем шерстить занудные мануалы :

Most parts of the DLIB library are reentrant, but these functions and parts are not
reentrant because they need static data:
● Heap functions—malloc, free, realloc, calloc, and the C++ operators new
and delete
● Time functions—asctime, localtime, gmtime, mktime
● Multibyte functions—mbrlen, mbrtowc, mbsrtowc, wcrtomb, wcsrtomb,
wctomb
● The miscellaneous functions setlocale, rand, atexit, strerror, strtok
● Functions that use files in some way. This includes printf, scanf, getchar, and
putchar. The functions sprintf and sscanf are not included.
Some functions also share the same storage for errno. These functions are not
reentrant, since an errno value resulting from one of these functions can be destroyed
by a subsequent use of the function before it is read. Among these functions are:
exp, exp10, ldexp, log, log10, pow, sqrt, acos, asin, atan2,
cosh, sinh, strtod, strtol, strtoul

Remedies for this are:
● Do not use non-reentrant functions in interrupt service routines
● Guard calls to a non-reentrant function by a mutex, or a secure region, etc.

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

[sonycman]

Может, кто подскажет идею, как в этой операционке сделать измерение процента бездействия\занятости процессора?

Жаль, что нет такого встроенного сервиса. Неужели это не просто сделать?

По идее, хук на вход в idle поток есть, если бы был второй хук на выход из этого потока...
Тогда бы вошли - запустили таймер - вышли - засекли время.

[sonycman]

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

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

Может, лучше ещё один мьютекс?

[Сергей Борщ]

По идее, эти функции должны выполняться весьма быстро

Первый раз, пока куча не фрагментирована. Да и от реализации менеджера зависит. А если самый худший случай - память кончилась и вызывается чистильщик?

Мутекс подходит очень хорошо.

[AHTOXA]

Добавлю ссылку на пример: вот.

[sonycman]

Первый раз, пока куча не фрагментирована. Да и от реализации менеджера зависит. А если самый худший случай - память кончилась и вызывается чистильщик?

Понятно - значит, будет мьютекс

А что за чистильщик такой? Составная часть библиотечного malloc(), или что-то своё?
Каков его функционал - дефрагментация выделенных блоков?

Добавлю ссылку на пример: вот.

Спасибо!

[Сергей Борщ]

А что за чистильщик такой?

Там по ссылке чуть ниже описано. Система принимает сообщения, складывает в буфер и ретранслирует дальше. Если канал ретрансляции отвалился, то буфер в конце-концов переполнится. В этом случае чистильщик удаляет по одному самые старые сообщения пока не наберется достаточно свободного места для нового.

[sonycman]

А для чего вообще в обработчики прерываний с сервисами РТОС добавлять "обёртку" TISRW?
Случайно забыл её добавить в обработчик, использующий SignalISR() - на работоспособности вроде не сказалось...

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

[ReAl]

А для чего вообще в обработчики прерываний с сервисами РТОС добавлять "обёртку" TISRW?
Случайно забыл её добавить в обработчик, использующий SignalISR() - на работоспособности вроде не сказалось...

Ну так это надо сомтреть. Похоже, переключение задач, которое "попросило" сделать SignalISR(), происходит не сразу же, а после очередного прерывания системного тика либо другого прериывания, у которого есть TISRW. Т.е. увеличилось время реакции на тот SignalISR(), который не обёрнут в TISRW. Вполне может и не нарушить работоспособность в определ’нной ситуации.

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

Не может. Там есть Kernel.ISR_NestCount

[sonycman]

Не может. Там есть Kernel.ISR_NestCount

По первому вопросу всё понял, спасибо!

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

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

[ReAl]

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

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

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

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

Ну тут уже зависит от архитектуры.
Как в AVR - так там контекст программно сохраняется и вложенное прерывание не пролезет, пока вручную не разрешить таковые.
Если есть аппаратное сохранение контекста и если оно может быть прервано более приоитетным прерыванием, то да. Но с точки зрения ОС это мало отличается от следующих друг за другомо прерываний - она ещё не получила управления и не знает, что прерывания вложенные. Т.е. к началу работы высокоприоритетного обработчика ОС не знает, что низкоприоритетное вобще начиналось, с её точки зрения это те же "друг за другом".
Можно ли с этим побороться и как именно - тоже надо смотреть конкретную архитектуру.
Кстати, если реальное переключение задач производится специальным прерыванием, то и в описаных случаях хоть планировщик вызовется и несколько раз, а контекст на нужную задачу переключится один раз в конце.

[sonycman]

Можно ли с этим побороться и как именно - тоже надо смотреть конкретную архитектуру.
Кстати, если реальное переключение задач производится специальным прерыванием, то и в описаных случаях хоть планировщик вызовется и несколько раз, а контекст на нужную задачу переключится один раз в конце.

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

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

Спасибо за пояснения!