Пишу ОС РВ, Вот пишу ОС Реального времени, у какого какие предложения? пожелания? Опции

[ddiimmaa]

Знаю, знаю дело не шибко благодарное. И люди могут тухлыми помидорами закидать. "Мол зачем ещё одна ОС?". Развелось тут понимаешь ОСеписателей.

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

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

Исходя из выше сказанного -- никаких POSIX, ну и сфера применения МК с ОЗУ от 512 до 256кбайт (ну выше там наверно что другое пойдёт).

У кого какие пожелания?

Наставления?

Мнения?

Вопросы?

что вы скажете по поводу выбора лиценции?

Что кому нравиться не нарвиться в их осях?

[sergeeff]

Это для общего развития или сейчас творческий простой?

[MrYuran]

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

[AlexandrY]

Ну покажите класс. Кто вас знает, мож вы гений.
512 Kb RAM-а - это очень много. Не советую ориентироваться на такие числа.
Ограничтесь лучше 2-я Кб. Во всяком случае для uCOS, ThreadX, CMX и других мощных осей этого вполне хватает для пары тройки задач.
Вообще-то нынче каждый уважающий себя компилер идет с встроенной RTOS.
У CodeWarrior - MQX, у Keil - RL ARM, у Tasking - OSE, у IAR - PowerPac и т.д

Нужно что-то уникальное у RTOS чтобы не стать посмешищем в этом ряду.

Этой уникальной фичей мог бы стать realtime профайлер.
Все как бы декларируют себя RTOS-ами, но реального тулса для тюнинга приоритетов задач, нарезок временных интервалов активности задач, тюнинга шедулеров в готовом дивайсе никто не предлагает. Всегда нужен PC, софтварный спец агент тормозящий приложение и захватывающий ресурс и IDE online.

Второй уникальной фичей мог бы стать сборщик мусора.
Задачи в момент инициализации могут захватить кучу памяти под разные буфера.
Потом при выгрузке задачи надо долго выискивать где там че было выделено.
Неплохо было бы чтоб все автоматом освобождалось.

Третья уникальная фича - проработка протокола вплоть до физического уровня межпроцессорного обмена.
Это оч востребованная фича, поскольку времена когда все делается на одном проце стремительно уходят.

Ну и еще дальше есть идеи...
Зависит от вашей реакции

Исходя из выше сказанного -- никаких POSIX, ну и сфера применения МК с ОЗУ от 512 до 256кбайт (ну выше там наверно что другое пойдёт).
У кого какие пожелания?
Наставления?
Мнения?
Вопросы?
Что кому нравиться не нарвиться в их осях?

[zltigo]

Второй уникальной фичей мог бы стать сборщик мусора.

Ну а я и не знал, что в свое время походя добавил во FreeRTOS "уникальную" вещь - всего-то в Memory Control Block менежера памяти запоминается адрес TCB задачи его запросившей.

можно сделать немного по другому и немного лучше.

Для "немного" того-другого просто надо доработать ту-же FreeRTOS. Хотели немножко памяти? - небольшие резервы по памяти там прямо под ногами лежат. А при сильно сэкономить и сделать систему под 512 байт, так такая система будет уродлива уже для десяткокилобайтовых...




 

[Rst7]

всего-то в Memory Control Block менежера памяти запоминается адрес TCB задачи его запросившей.

LR еще запоминать надо Или любой произвольный отладочный параметр, передаваемый malloc'у при таргете Debug.

[VslavX]

LR еще запоминать надо Или любой произвольный отладочный параметр, передаваемый malloc'у при таргете Debug.

LR? А если это не ARM? . Лучше __LINE__ + __FILE__ (по крайней мере, IAR/GCC/MSVC про них знают ) Например:

Код

#define TN_ASSERT( Value, Text)                                             \
    if (!(Value))                                                           \
    {                                                                       \
        tn_assert( Text, __LINE__, __FILE__);                               \
    }

[Rst7]

LR? А если это не ARM?

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

[VslavX]

А ассерты - это другой разговор.

Дык, assert - для примера только. Я текст с alloc() сразу поленился выложить. Так лучше?

Код

#if (DEBUG == 0)
#define MM_Alloc( a, b)                         \
        MM_AllocFree( a, b)
#else
#define MM_Alloc( a, b)                         \
        MM_AllocDebug( a, b, __LINE__, __FILE__)
#endif

А вот реализация:

Код

PVOID __stdcall
MM_AllocDebug
(
    DWORD   Size,           // size of chunk in bytes
    BOOL    bPaged,         // pageble or nonpageable flag
    DWORD   Line,           // source line number
    PCHAR   File            // source file name
)
{
    PMEM_BLOCK Result;

    Result = (PMEM_BLOCK)_HeapAllocate(
                    Size + sizeof(MEM_BLOCK),
                    bPaged ? HEAPSWAP : 0);
    if (Result == NULL)
    {
        dprintf(PFX "Memory allocation failed\n");
        return NULL;
    }
    
    Result->Size = Size;
    Result->Line = Line;
    Result->File = File;

    Pushfd();
        //
        // First write may cause paging, so we need to
        // disable interrupts again and do operation again.
        // It is not good idea to use the synchronization
        // objects here (it is merely for debug purposes
        // and is potentially dangerous - may cause the
        // deadlock)
        //
        Result->Next = memHeadList;
        Cli();
        Result->Next = memHeadList;
        memHeadList = Result;
    Popfd();
    return &Result->Data[0];
}

Подход очень неплох - когда завершаемся - можно пробежать по списку неосвобожденной памяти и сразу ответить на вопрос "кто виноват". Но есть и минус - когда делаем MM_Free - надо пробежать по списку, найти блок (если не нашли - тоже класс - сразу assert), и удалить из списка. Когда таких блоков много и частые alloc/free - список тормозит. Но для отладки - самое оно.
А в embedded я стараюсь "кучу" не пользовать - у меня обычно ясно сколько объектов будет "в деле" - для них пул блоков фиксированной длины пользуется - в TN Kernel под это дело даже системные вызовы сделаны.

[Rst7]

Подход очень неплох - когда завершаемся - можно пробежать по списку неосвобожденной памяти и сразу ответить на вопрос "кто виноват"

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

Конечно, если мельчить задачи, то решение zltigo тоже работает неплохо - если в одной задаче обозримое количество аллокаций. Хотя грань понятия "мельчения" у каждого своя. Кому и 2 аллока - смерть

[VslavX]

минималистичный вариант - это сохранение адреса вызывающей процедуры.

А как Вы ищете потом процедуру по этому адресу? Я подсчитал - у меня в TCP за сотню вызовов pbuf_alloc(), по листингам смотреть-считать? Есть автоматизация какая?

[Rst7]

А как Вы ищете потом процедуру по этому адресу?

В IDA пробовали грузить .elf-файлы с нестрипнутым debug-info? Дальше все просто, кнопочку G, вводите адрес LR, оценяете, где находитесь.

[_Pasha]

Подход очень неплох

Зачем плодить наследованные глупости? Выделяйте память , используя дескрипторы, которые можно располагать в отдельном сегменте. Заодно ответы на вопросы: Дефрагментация? Размер блока? Уборка мусора?

В общем, сейчас закритикуют... Жду

[VslavX]

В IDA пробовали грузить .elf-файлы с нестрипнутым debug-info? Дальше все просто, кнопочку G, вводите адрес LR, оценяете, где находитесь.

Спасибо, про IDA я как-то не подумал, попробую! А для IAR-а тоже сработает?

Зачем плодить наследованные глупости? Выделяйте память , используя дескрипторы, которые можно располагать в отдельном сегменте. Заодно ответы на вопросы: Дефрагментация? Размер блока? Уборка мусора?

В общем, сейчас закритикуют... Жду

Чтобы закритиковать - надо сначало понять что именно Вы предложили . Если я правильно поняд - то похожий механизм был в Win16 - это был настоящий ахтунг (имел "счастье" попользоваться) , и не от хорошей жизни его MS предложила. ИМХО, подход "залочь - поюзай - разлочь" не слишком хорош для небольших систем. В реал-тайме вообще чревато проблемами - "мне тут память срочно нужна, а там, пАнимаешь в фоне сборщик мусора работает".

[Rst7]

А для IAR-а тоже сработает?

Ага. 4.42 точно стреляет. 5.x - надо проверять, пока не пользую.

[zltigo]

Ну адрес вызывающей процедуры.

Так я в общем-то это и делаю, точнее лучше , для текущей задачи задачи известен указатель на ее Task Control Block он и сохраняется в менеджером памяти в Memory Control Block.

[Rst7]

для текущей задачи задачи известен указатель на ее Task Control Block он и сохраняется в менеджером памяти в Memory Control Block.

Я не очень понял, кто сохраняется? Указатель на TCB? Но это локализация с точностью до задачи.

[zltigo]

Я не очень понял, кто сохраняется? Указатель на TCB? Но это локализация с точностью до задачи.

Естественно до задачи. Нужно зачем-то меньше? Тогда при вызове malloc у меня можно явно указать не NULL, а некое число идентификатор и сохранено будет оно, а не указатель на TCB. В качестве идентификатора можно использовать, и указатель на текстовую строчку или сруктуру в котрой уже есть и TCB задачи и локализация конкретного места.

[Rst7]

Тогда при вызове malloc у меня можно явно указать не NULL, а некое число идентификатор и сохранено будет оно, а не указатель на TCB.

Не возражаю

[VslavX]

Так я в общем-то это и делаю, точнее лучше , для текущей задачи задачи известен указатель на ее Task Control Block он и сохраняется в менеджером памяти в Memory Control Block.

Я вот тут как-то задумался - у меня потребность знать какая задача выделила память редко возникает. Под Windows - в User Mode ОС сама следит и чистит, в Kernel Mode драйверу обычно тоже все равно какой контекст. В простых ОС для embedded понятие задача вообще упрощено и сведено до потока - в системных сервисах запоминать TCB тоже не особо нужно. Я как-то стараюсь привязать память к объекту который ее использует, а не к потоку. Например, сокет TCP - создается, живет, для него выделяются pbuf-ы, ведется четкий учет, квотирование, в самом pbuf есть ссылка на socket-владелец. А вот TCB - нету. Сокет может быть создан в одном потоке, выполнять обмен в совершенно другом, и завершить свою жизнь в третьем. И какой смысл помнить какой поток выделял для него pbuf?
Аналогично для USB pipe - вся память "записана на владельца" - структуру описывающую pipe, и поля TCB там тоже как-то нету.
Конечно, это не значит в общем случае что TCB знать не полезно, просто подход, наверное, другой.

[Rst7]

Плохо только то, что армовский IAR почему-то не склеивает функции. Ну типа

Код

foo1(i, j);

foo2(i)
{
foo1(i, 0);
}

foo1(i,j)
{
.....
}

AVR'овский отлично изготавливает нечто типа

Код

foo2:
   j=0
foo1:
   ....
   ret

, а армовский, к сожалению, так не делает

[zltigo]

Например, сокет TCP - создается, живет, для него выделяются pbuf-ы, ведется четкий учет, квотирование, в самом pbuf есть ссылка на socket-владелец.

Значит там хранится не указатель на TCB, а на то, что хотите. Более того, что на самом деле у меня, например, для блока памяти выделенного очереди там на автомате сохраняется, естественно указатель на Queue Control Block. Ну а в самом QCB уже TCB .

 

[VslavX]

Плохо только то, что армовский IAR почему-то не склеивает функции. Ну типа

Попробуйте применить к функции модификатор static. Вероятно, компилятор Вас приятно удивит .
PS: я уже этим static даже злоупотреблять немного начал

[Rst7]

Попробуйте применить к функции модификатор static.

Не удивит

[VslavX]

Значит там хранится не указатель на TCB, а на то, что хотите. Более того, что на самом деле у меня, например, для блока памяти выделенного очереди там на автомате сохраняется, естественно указатель на Queue Control Block. Ну а в самом QCB уже TCB .

Не-а, я в принципе объекты к потокам не привязываю со стороны объекта. Потоки - да, ессно, имеют ссылки на объекты, а вот наоборот - нет. Это позволяет без проблем использовать объекты в произвольном контексте и, при желании, в нескольких потоках одновременно. Хотя, ессно, этим злоупотреблять не стоит и нечасто реально используется (стандартная практика - "где родился - там и сгодился" - ну и "помер" в итоге, когда уже объект стал не нужен ).
Обойтись в объектах без ссылок на потоки вполне реально, ессно, обратная связь есть - куда ж без нее, но явной привязки к потоку нет. Пример: тот же TCP сокет при создании получает ссылку на объект типа "событие", по которой он будет оповещать приложение о своей жизни. А какой поток это событие будет ждать - "шерифа это не волнует" .

Не удивит

А что тогда не нравится?
Вот Ваш пример:

Код

int global_int;

static void foo1(int i, int j);
static void foo2(int i)
{
    foo1(i, 0);
}
static void foo1(int i, int j)
{
    global_int = i+j;
}

void TestLW(void)
{
    int Key;

    foo2(2);

У меня превратился в:

Код

   \                                 In segment CODE, align 4, keep-with-next
   1838          void TestLW(void)
   1839          {
   \                     TestLW:
   \   00000000   F0402DE9           PUSH     {R4-R7,LR}
   1840              int Key;
   1841          
   1842              foo2(2);
   \   00000004   8C029FE5           LDR      R0,??TestLW_0  ;; FirstTest
   \   00000008   0210A0E3           MOV      R1,#+2
   \   0000000C   041080E5           STR      R1,[R0, #+4]
   1843

Имхо, вполне ничего.
А функции, да, не конкатенирует - я это только в IAR AVR встречал - там он даже что-то вроде архиватора Лемпеля-Зива применяет - ищет в совершенно разных функциях одинаковые куски, составляет из них "словарь" и вовсю его "пользует".

[Rst7]

А функции, да, не конкатенирует

Дык я об этом. Сделайте #pragma optimize=no_inline и поймете о чем я.

там он даже что-то вроде архиватора Лемпеля-Зива применяет - ищет в совершенно разных функциях одинаковые куски, составляет из них "словарь" и вовсю его "пользует".

Ну кросскол - это от лукавого, я так мыслю.

[ddiimmaa]

Это для общего развития или сейчас творческий простой?

Это нужен инструмент аля FreeRTOS но с меньшими аппетитами по RAM и с правом копаться в ядре, с тем чтобы получившееся можно было и в коммерческих разработках выдавать.

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

Вот вот в том то и дело что она Си плюс плюснутая. А так ничего ОC, правда тоже есть недочёты, в виде жёсткости системы приоритетов. Так например не может быть двух задач с одинаковыми приоритетами

Ну покажите класс. Кто вас знает, мож вы гений.
512 Kb RAM-а - это очень много. Не советую ориентироваться на такие числа.
Ограничтесь лучше 2-я Кб. Во всяком случае для uCOS, ThreadX, CMX и других мощных осей этого вполне хватает для пары тройки задач.

Ну конечно она должна влезать в сотни бацт по ОЗУ. Я это просто прикинул, что при 512 кб уже смысла нет ставить то, что я думаю

Вообще-то нынче каждый уважающий себя компилер идет с встроенной RTOS.
У CodeWarrior - MQX, у Keil - RL ARM, у Tasking - OSE, у IAR - PowerPac и т.д

Ну судя этой логике gcc -- не уважающий себя компилер

Этой уникальной фичей мог бы стать realtime профайлер.
Все как бы декларируют себя RTOS-ами, но реального тулса для тюнинга приоритетов задач, нарезок временных интервалов активности задач, тюнинга шедулеров в готовом дивайсе никто не предлагает. Всегда нужен PC, софтварный спец агент тормозящий приложение и захватывающий ресурс и IDE online.

А можно по подробнее что есть realtime профайлер и какую статистику он должен собирать?

Третья уникальная фича - проработка протокола вплоть до физического уровня межпроцессорного обмена.
Это оч востребованная фича, поскольку времена когда все делается на одном проце стремительно уходят.

Хм а вот тут тоже не совсем ясно? Что имееться в виду? Соединять несколько процов по какому-либо протоколу? С целью? Протокол обычно соответствует часто использемым функциям, т. е. реализует базовую функциональность чего-либо! А тут малость мне не понятно что может быть общего между различными устройствами в которых есть не один ЦП? И честно говоря, по этому ничего не видел ни инфы ни протоколов ни таких ОСей может подкините что-нибудь!

Для "немного" того-другого просто надо доработать ту-же FreeRTOS. Хотели немножко памяти? - небольшие резервы по памяти там прямо под ногами лежат.

Можно можно, но вот в один прекрасный день (хотя у нас в России пока на это мало глядят) мне тут скажут "мужик -- ты же доработал FreeRTOS" -- ну тогда у тебя проект на GPL -- давай выкладывай все свои исходники.

А при сильно сэкономить и сделать систему под 512 байт, так такая система будет уродлива уже для десяткокилобайтовых...

А как на ваш взгляд scmRTOS? Уродлива для десяткокилобайтовых?

Дык, assert - для примера только. Я текст с alloc() сразу поленился выложить. Так лучше?

Код

#if (DEBUG == 0)
#define MM_Alloc( a, b)                         \
         MM_AllocFree( a, b)
#else
#define MM_Alloc( a, b)                         \
         MM_AllocDebug( a, b, __LINE__, __FILE__)
#endif

Вот это да идея!!! первый раз такое вижу. Может буду применять. Честно говоря, меня шас память мало волнует. Больше приоритеты и прочее. И вообще мне не нравиться например что в FreeRTOS нельзя полностью работать на статической памяти.

[zltigo]

Можно можно, но вот в один прекрасный день (хотя у нас в России пока на это мало глядят) мне тут скажут "мужик -- ты же доработал FreeRTOS" -- ну тогда у тебя проект на GPL -- давай выкладывай все свои исходники.

Там модифицированный GPL. Почитайте, ну может десять баксов пожертвуйте.... Ну и если действительно заметно доработали, то прежде, чем кто-то это скажет Вы сначала должны зачем-то выложить исходники Да и купить на самом деле можно OpenRTOS при малейшей необходимости - время дороже .

[VslavX]

Посмотрите TN Kernel
Написана на чистом C, "понятным языком", хорошо структурирована. API сделано "по мотивам" спецификации uTRON 4.x - на таких ОС японцы большую часть своей электроники делают. Приоритеты не фиксированы, есть round-robin для задач с одинаковым приоритетом, есть механизмы борьбы с priority inversion, достаточно быстрая. Я на ней остановился после знакомства с uCOS и FreeRTOS. Еще очень понравилась scmRTOS - изящнейшая вещь, но я не настолько уверено "++" владею, и, к сожалению, узнал о ней уже после значительного "перелопачивания" TN.

[ddiimmaa]

Посмотрите TN Kernel
Написана на чистом C, "понятным языком", хорошо структурирована. API сделано "по мотивам" спецификации uTRON 4.x - на таких ОС японцы большую часть своей электроники делают. Приоритеты не фиксированы, есть round-robin для задач с одинаковым приоритетом, есть механизмы борьбы с priority inversion, достаточно быстрая. Я на ней остановился после знакомства с uCOS и FreeRTOS. Еще очень понравилась scmRTOS - изящнейшая вещь, но я не настолько уверено "++" владею, и, к сожалению, узнал о ней уже после значительного "перелопачивания" TN.

посмотрел

Код

//----- Task Control Block ------------
typedef struct _TN_TCB
{
   unsigned int * task_stk;  //-- Pointer to task's top of stack
   CDLL_QUEUE task_queue;    //-- Queue is used to include task in ready/wait lists
   CDLL_QUEUE timer_queue;   //-- Queue is used to include task in timer(timeout,etc.) list
   CDLL_QUEUE block_queue;   //-- Queue is used to include task in blocked task list only
                               // uses for mutexes priority seiling protocol
   CDLL_QUEUE create_queue;  //-- Queue is used to include task in create list only
   CDLL_QUEUE mutex_queue;   //-- List of all mutexes that tack locked  (ver 2.x)
   CDLL_QUEUE * pwait_queue; //-- Ptr to object's(semaphor,event,etc.) wait list,
                               // that task has been included for waiting (ver 2.x)
   struct _TN_TCB * blk_task; //-- Store task,that blocked our task(for mutexes's
                               // priority ceiling protocol only (ver 2.x)

   unsigned int * stk_start;          //-- Base address of task's stack space
   int   stk_size;           //-- Task's stack size (in sizeof(void*),not bytes)
   void * task_func_addr;    //-- filled on creation  (ver 2.x)
   void * task_func_param;   //-- filled on creation  (ver 2.x)

   int  base_priority;       //-- Task base priority  (ver 2.x)
   int  priority;            //-- Task current priority
   int  id_task;             //-- ID for verification(is it a task or another object?)
                               // All tasks have the same id_task magic number (ver 2.x)

   int  task_state;          //-- Task state
   int  task_wait_reason;    //-- Reason for waiting
   int  task_wait_rc;        //-- Waiting return code(reason why waiting  finished)
   int  tick_count;          //-- Remaining time until timeout
   int  tslice_count;        //-- Time slice counter

   int  ewait_pattern;       //-- Event wait pattern
   int  ewait_mode;          //-- Event wait mode:  _AND or _OR

   void * data_elem;         //-- Store data queue entry,if data queue is full

   int  activate_count;      //-- Activation request count - for statistic
   int  wakeup_count;        //-- Wakeup request count - for statistic
   int  suspend_count;       //-- Suspension count - for statistic

// Other implementation specific fields may be added below

}TN_TCB;

очень впечатляет во FreeRTOS и того меньше, ну да ладно нечего пинять на других коли сам не сделал

Там модифицированный GPL. Почитайте, ну может десять баксов пожертвуйте.... Ну и если действительно заметно доработали, то прежде, чем кто-то это скажет Вы сначала должны зачем-то выложить исходники Да и купить на самом деле можно OpenRTOS при малейшей необходимости - время дороже .

Мда, а если я хочу выложить исходники (ну типа посмотрите как я крут ), ну да ладно если бы да кабы.. да росли бы грибы....

[VslavX]

посмотрел

Код

//----- Task Control Block ------------
typedef struct _TN_TCB
{
...
}TN_TCB;

очень впечатляет во FreeRTOS и того меньше

Ужимается в полтора раза без потери функционала. У меня сейчас TCB составляет 22 слова. FreeRTOS имеет TCB поменьше (я 16 слов насчитал по-минимуму), конечно, но и функционал победнее. Из синхрообъектов TN очень хороши мутексы (владелец + управление приоритетом) и события (хоть какая-то замена WaitForMultipleObjects). В-общем - размер TCB - это еще не показатель.

[AlexandrY]

В RL ARM у TCB размер 12 слов, а по функционалу оно TN уделает пожалуй.

Ужимается в полтора раза без потери функционала. У меня сейчас TCB составляет 22 слова. FreeRTOS имеет TCB поменьше (я 16 слов насчитал по-минимуму), конечно, но и функционал победнее. Из синхрообъектов TN очень хороши мутексы (владелец + управление приоритетом) и события (хоть какая-то замена WaitForMultipleObjects). В-общем - размер TCB - это еще не показатель.

[VslavX]

В RL ARM у TCB размер 12 слов, а по функционалу оно TN уделает пожалуй.

Ну я бы не сказал, что "уделывает". Но спорить насчет цвета и вкуса фломастеров не буду

[ddiimmaa]

Ужимается в полтора раза без потери функционала.

Странно! А вот интересно? А что же тогда автор не удосужился сам ужимать своё детище? или принимать заплатки от кого либо?

[zltigo]

Странно! А вот интересно? А что же тогда автор не удосужился сам ужимать своё детище?

Потому, что обычно Авторы реальных систем думают не только о том, как поставить рекорд по минимуму TCB. Естественно, приложив определенные усилия действительно можно соптимизировать для конкретных применений. Бывают, конечно и практически необъяснимые решения, типа раздельных блоков памяти для стека и TCB у FreeRTOS (у себя похерил), но в основном Авторы действительно получивших распространение систем не дураки.

[ddiimmaa]

Потому, что обычно Авторы реальных систем думают не только о том, как поставить рекорд по минимуму TCB.

Ну вот посмотрите на Адама Дункелься!!! Это не его ли мини мини стэком TCP пользуються большинство микромикроконтроллистов!
Так вот он вообще придумал Contikki -- по два байта на поток. Правда у него не поток а протопоток (protothread). И реалтаймом не пахнет, но он своё детище операционнкой называет.

Бывают, конечно и практически необъяснимые решения, типа раздельных блоков памяти для стека и TCB у FreeRTOS (у себя похерил)...

Ну тут всё просто, как мне кажеться -- это чтобы облегчить жизнь процедурам выделения/освобождения памяти. Говорят в ранних версиях FreeRTOS был пул, как-то заранее нарезаных блоков памяти.

[zltigo]

И реалтаймом не пахнет, но он своё детище операционнкой называет.

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

Ну тут всё просто, как мне кажеться -- это чтобы облегчить жизнь процедурам выделения/освобождения памяти.

Очень сомнительное облегчение. TCB они конечно, одного размера, но стеки в общем случае разного. Получаем большее число фрагментов при гипотетически легче утилизируемом блоке освобожденного TCB под новую задачу.

В явных минусах - увеличение расхода памяти на TCB, MCB и времени на двойной запуск менеджера памяти.  

Говорят в ранних версиях FreeRTOS был пул, как-то заранее нарезаных блоков памяти.

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

[VslavX]

Странно! А вот интересно? А что же тогда автор не удосужился сам ужимать своё детище? или принимать заплатки от кого либо?

Есть такой анекдот:

Жили-были в лесу серые мыши, жизнь у них была трудная и пошли они к мудрому Филину за советом:
- Мы, мыши серые, звери мелкие, все нас обидеть и съесть норовят. Скажи нам, Мудрейший из Мудрейших, как нам быть?
Филин, подумал, подумал, и говорит:
- А вы, мыши, станьте ежиками колючими, и никто вас тогда трогать не будет!
Мыши обрадовались, поблагодарили и собрались уже было уходить:
- Погоди, Мудрейший, а как же нам ежиками стать?
- Млин, ну чего вы ко мне с такой ерундой пристаете - я же только Стратегией занимаюсь! Вот!

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

Так вот он вообще придумал Contikki -- по два байта на поток. Правда у него не поток а протопоток (protothread). И реалтаймом не

Дык, "Контики" - плот он и есть плот. А хочется, если уж не лайнер (Linux/WinCE), то хотя бы океанскую яхту . Если ресурсы (финансовые или аппаратные ) позволяют. А современные недорогие массовые ARM-ы - типа LPC/SAM - "яхту" позволить вполне могут.
Ну океанскую или нет, а "река-море" - запросто.

[AlexandrY]

Что то непонятны ваши потуги интуитивно выразить мысль.

Есть скорость работы самой операционки на целевой платформе.
Есть скорость разработки приложения на базе операционки (определяется объемом middleware )
И есть скорость отладки приложения и поддержки либо на целевой платформе либо на host системе. (определяется интегрированными тулсами)
Эти скорости сильно противоречат обычно друг другу.
Поэтому лайнер здесь в проекции на другую плоскость будет трактором.

Малые RTOS нужны для малых процов.
Малых процов на самом деле становиться только больше.
Взять какой-нить netbook:
на HMI один, на управление питанием - другой, на расширяемый ввод-вывод - третий, спец коммуникации - четвертый и т.д.
И на каждый из них имеет смысл ставить RTOS чтобы ускорить разработку. И спрос на малые RTOS соответственно тоже растет.
И универсальность от них требуется достаточно большая и скорость тоже, поскольку от нее зависит энергопотребление.
Выбрав непродумано ось для этих применений можно сильно пролететь.

Заигрываться тоже понятно не стоит. Цена вопроса смены оси где-то месяц.
Но бывает что и это слишком долго поэтому пообсуждать вижу смысл.

А вот рассматривать малую RTOS в плане открытости лицензии или открытости тулсов не вижу смысла. На это есть рефакторинг.
Чем, подозреваю, автор и занимается.

Дык, "Контики" - плот он и есть плот. А хочется, если уж не лайнер

[VslavX]

Что то непонятны ваши потуги интуитивно выразить мысль.

Да я ничего особенного выразить не хотел - топикстартер начал размеры TCB обсуждать, поэтому я привел образное сравнение плавсредств - меньше размер/меньше удобств. Само средство, конечно, желательно выбирать согласно задачи - в луже побарахтаться, Днепр переплыть или Тихий океан пересечь.

[ddiimmaa]

топикстартер начал размеры TCB обсуждать, поэтому я привел образное сравнение плавсредств - меньше размер/меньше удобств.

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

[VslavX]

но больше удивило то, что на каждый объект (семафор мютекс и т. д.) у разработчика свой элемент в TCB.

Это где там на каждый объект свое поле в TCB? Есть свои списки для мьютексов - но это для реализации протоколов наследования приоритета. BTW, я через авторский вариант мьютексов "не продрался", сделал упрощенный вариант PIP/PCP (приоритет снижаем при освобождении мьютекса - сканируем захваченные мьютексы и выбирает макс уровень) - тогда один список не нужен. А так -
все списки в TCB очень даже на месте и лишних нет:

CDLL_QUEUE task_queue; - включен или в список диспетчера (и такой список свой для каждого уровня приоритета - планировщик работает очень быстро) или в список объекта который ждет -mutex/sem/event/queue

CDLL_QUEUE timer_queue; - включен в список проверки на тайм-аут ожидания. Теоретически можно и выкинуть - тогда в процедуре системного таймера бежать не по этому списку, а по списку всех задач и смотреть "кто ждет" и проверять тайм-аут. Но это - неоптимально, поэтому список таймера стоит этих 2-х слов в TCB, имхо.

CDLL_QUEUE block_queue; - этого у меня нет, используется для протоколов управления приоритетами, я схему немного упростил, но все "в рамках приличий", которые допускает uTRON 4.x. Насколько я смог разобраться, авторский вариант реализует полные версии PIP/PCP, что, имхо, несколько избыточно, хотя и приятно.

CDLL_QUEUE create_queue; - просто список всех задач в системе. Не особо нужен (кажется, даже реально в оригинале не используется), но полезен при отладке (выводим список всех задач в системе) и при контроле повторного использования TCB.

CDLL_QUEUE mutex_queue; - просто необходимый список для реализации протоколов PIP/PCP, чтобы по этим протоколам вычислить приоритет задачи надо иметь список залоченных задачей мьютексов. Ну, альтернатива - можно иметь один глобальный список мьютексов в системе, сканировать его - проверять наш/не наш. Но мьютексов в системе может быть очень много, а вот реально залочено задачей - один/два/три. Поэтому выигрыш в скорости - существенный. Также используется для автоматического освобождения мьютексов при завершении задачи (типа автоочистки) - бесплатный бонус

Да, списки можно сделать и односвязными. Ессно, потеряв в скорости и в предсказуемости времени операций добавления/удаления элемента - имхо, в данном случае - моветон.

Итак, ужать еще кое-что можно. Но - упадет скорость и потеряем кое-что полезное.
Еще момент - при написании/рефакторинге ОС неплохо бы определится с целевой платформой, тогда не будет таких вопросов - "а почему такой относительно сложный TCB". Например, когда я "осваивал" TN - сразу задал для себя некоторую минимальную планку ресурсов - минимум 32-битник и 8К оперативки и 32К флеша - на сегодня это младшие представители семейств LPC/SAM - так что такая планка вполне оправдана. Под 32-битностью я также понимаю атомарность операций извлечения/записи в память 32-битного слова/указателя -это позволило значительно пооптимизировать кое-какие места.

[AlexandrY]

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

На мой взгляд универсальность в этом плане делать не стоит.
Я тоже за ARM-ы, но только за Cortex-ы

И че сразу надо учесть - это соглашения из Application Binary Interface.
Неучет ABI - бесконечный источник траблов даже в солидных осях.
Даже в uCOS не знаю как сейчас, но раньше не брали в расчет нюансы ABI
И получали сюрпризы типа: а у меня из задачи стандартные либы так-то и так-то сбоят.

Под 32-битностью я также понимаю атомарность операций извлечения/записи в память 32-битного слова/указателя -это позволило значительно пооптимизировать кое-какие места.

[AlexandrY]

Кстати копнув глубже в архитектуру ARMv7-M (ядро Cortex-а) обнаружил там команды чем-то напоминающие вход и выход из критических секций в мультипроцессорной системе.
Неплохой задел для операционок будущего!

[ddiimmaa]

На мой взгляд универсальность в этом плане делать не стоит.
Я тоже за ARM-ы, но только за Cortex-ы

И че сразу надо учесть - это соглашения из Application Binary Interface.
Неучет ABI - бесконечный источник траблов даже в солидных осях.

Хм, если ОСь -- оpen source, тогда какие могут быть траблы, главно API не часто менять, а на ABI наплевать.

Кстати копнув глубже в архитектуру ARMv7-M (ядро Cortex-а) обнаружил там команды чем-то напоминающие вход и выход из критических секций в мультипроцессорной системе.
Неплохой задел для операционок будущего!

Ну дак поделитесь хоть мнемоникой.

[aaarrr]

а на ABI наплевать.

Сильное заявление Плевать на стандарты, мягко говоря, не рекомендуется. Особенно осестроителям.

[ddiimmaa]

Сильное заявление Плевать на стандарты, мягко говоря, не рекомендуется. Особенно осестроителям.

Когда будут хотя бы 10 приложений для ОСи тогда будет не наплевать на АПИ
А когда будет загрузчик и две три либы тогда будет не наплевать на АБИ

А сейчас... кхм кхм.... начхать на них мона.

[aaarrr]

А сейчас... кхм кхм.... начхать на них мона.

Это заблуждение. Лучше соблюдать стандарты с самого начала, чем потом исправлять уже растиражированные ошибки.

[ddiimmaa]

Это заблуждение. Лучше соблюдать стандарты с самого начала, чем потом исправлять уже растиражированные ошибки.

Даааа? Я буду рад если вы мне покажите нормальный стандарт под такую ОСь. POSIX не предлагать слишком монструозно для таких осей. miTRON -- хороший стандар однако уж больно там имена функций корявые мне своим русским умом японские сокращения не понять

[aaarrr]

Даааа? Я буду рад если вы мне покажите нормальный стандарт под такую ОСь.

Сначала придется уяснить, о чем мы говорим:
Application Binary Interface

[sergeeff]

Многие признают, что scmRTOS для микропроцессоров очень неплоха, но при этом останавливает, что она написана на C++ (хотя я лично в этом не вижу никаких проблем). Так вот для понимания что к чему, напишите ее на чистом С.

[VslavX]

miTRON -- хороший стандар однако уж больно там имена функций корявые мне своим русским умом японские сокращения не понять

Хм, а какое отношение имена функций имеют к идеологии?

останавливает, что она написана на C++

Имхо, в "плюсах" очень много возможностей для генерации неявного кода, чтобы грамотно пользовать C++ в embedded надо знать язык _очень_ хорошо. Вот здравое сомнение в своем уровне владения языком и останавливает.

[dxp]

Имхо, в "плюсах" очень много возможностей для генерации неявного кода, чтобы грамотно пользовать C++ в embedded надо знать язык _очень_ хорошо. Вот здравое сомнение в своем уровне владения языком и останавливает.

Насчет много, это вы погорячились. Основной генератор неявного кода - шаблоны, исключения и RTTI. В embedded реально используются только шаблоны, вот с ними надо быть внимательным, но сюрпризов там нет - все достаточно легко прогнозируется. Остальное: неявная передача this в функции-члены при вызове, все эти vtpr/vtbl и прочее - это, во-первых, мелочи, во-вторых, это не оверхед, а реализация необходимой функциональности, которую в противном случае (например, на С) пришлось бы писать руками.

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

[AlexandrY]

Обратно никогда не хочется!
Став все время работать на C++ вы забываете постепенно паттерны программирования на C и вам затруднительно использовать фреймворк который нынче весь исключительно на C написан. Или сидите на двух стульях и пишите медленнее обычного и делаете больше багов.
Либо вы вообще узкий специалист и это не ваша игра.

Освоение С++ меньше всего сводится к синтаксису и объектной модели, надо иметь экосистему, как модно нынче говорить, для использования этого языка.
C++ в embedded просто неконкурентоспособен.
Т.е. написав ось на C++ вам придется писать и фреймворк и прикладные стеки на C++
А это абсолютная утопия еще в ближайшие десятилетия.
Сделать заново целиком весь embedded фреймворк способны только гиганты типа Microsoft.
Но они уже сделали ставку на C# и .NET.
А нишу малых RTOS они занимают micro framework у которого HAL уровень на том же C написан.

Насчет много, это вы погорячились. Основной генератор неявного кода - шаблоны, исключения и RTTI. В embedded реально используются только шаблоны, вот с ними надо быть внимательным, но сюрпризов там нет - все достаточно легко прогнозируется. Остальное: неявная передача this в функции-члены при вызове, все эти vtpr/vtbl и прочее - это, во-первых, мелочи, во-вторых, это не оверхед, а реализация необходимой функциональности, которую в противном случае (например, на С) пришлось бы писать руками.

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

[VslavX]

Обратно никогда не хочется!
Став все время работать на C++ вы забываете постепенно паттерны программирования на C и вам затруднительно использовать фреймворк который нынче весь исключительно на C написан. Или сидите на двух стульях и пишите

Ну, это смотря насколько в C++ углубиться. Идеи в ++ есть, немало, и среди них есть даже полезные. Я, например, довольно часто использую сам объектный подход - неважно, что функции обычные С-шные и изолирование методов и данных производится примитивно вручную на уровне файлов и операторов static. Да, нет перегрузки, наследования и прочего, но проект в целом видится яснее.

Т.е. написав ось на C++ вам придется писать и фреймворк и прикладные стеки на C++

Имхо, при желании вполне можно подружить C++ приложение и C-framework. Придется поработать, не без этого, но - возможно. Меня скорее напрягает вероятная проблема с компиляторами - спектр применяемых архитектур широкий - ARM/XScale, PowerPC, X86, возможно скоро будет MIPS, маячит Nios/CortexM1. На "чистом C" как-то все пока получалось переносить без особых проблем. Но - все равно тема интересная, думаю надо таки ++ попробовать - на каком-то ограниченном проекте (и, кстати, на сишном фреймворке), только бы вот время на это все найти . Паттерны вряд ли забудутся - я любитель частенько смотреть в ассемблерный листинг.

[yuri_t]

IMXO, у С++ наиболее полезные вещи -это наследование и возможность создания полнофункциональных собственных типов-расширений языка (перегрузка операторов и т.д.).
В моей практике для embedded эти возможности требовались очень редко и поэтому С++ я использую только для программирования на PС под Windows, a для embedded - только С (по принципу KISS)

Кстати, при переходе от С к С++ и наоборот бывает весьма трудно переключиться с одного стиля программирования на
другой

[ddiimmaa]

Сначала придется уяснить, о чем мы говорим:
Application Binary Interface

В таких ОСях думаю, что вводить специальный формат вызова не целесообразно. То есть как передавать параметры из функции в функцию из приложения в ядро, должен решать компилятор.

Никаких int 80h как в Menuet или Linux с регистрами и прочее -> ведёт к сильной привязке к архитектуре, да и зачаем оно? лишняя головная боль.

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

Так вот, из всего что я знаю, так говорят, что BeOS -- объектно ориентирована и scrmRTOS. BeOs не видел, а вот последняя надо сказать очень элегантна сделана.


Жаль что это единственное исключение из правил.

[aaarrr]

В таких ОСях думаю, что вводить специальный формат вызова не целесообразно. То есть как передавать параметры из функции в функцию из приложения в ядро, должен решать компилятор.

Компилятор все решить не может, некоторые вещи придется сделать самому в соответствии с ABI.

Простой прнимер: стандарт ARM ATPCS требует выравнивать стек при вызове функции по границе двух слов. Автор FreeRTOS на это требование забил, в результате мы имеем глючащие библиотеки плавучки на некоторых компиляторах.

[ddiimmaa]

Компилятор все решить не может, некоторые вещи придется сделать самому в соответствии с ABI.

Простой прнимер: стандарт ARM ATPCS требует выравнивать стек при вызове функции по границе двух слов. Автор FreeRTOS на это требование забил, в результате мы имеем глючащие библиотеки плавучки на некоторых компиляторах.

Хм, а что ему мешает это выравнивать, что нельзя в файле port.c забить проверку стека при инициализации (если не делиться адрес на 8 то убавлять ещё 4 байта в стек поинтере?)?
А далее уже дело компилятора!

Или что? тут не поможет данное решение????????

Или далее компилятор уже не выравнивает?

"некоторые вещи придется сделать самому в соответствии с ABI."
Ну конечно к ним относиться стековые веши, согласен!!! Ясень пень что стек инициализировать надо в соотвесвии с ABI, но что тут определяться то?
Сама то ОС, главная часть то бишь! она каким тут боком?

Почему надо думать об ABI, зачем создавать какой то свой интерфейс вызовов, почему тупо не следовать уже написанному и то только в портируемой части? вот что я не пойму?Как? простите инициализация стека корреным образом влияет на ОС?

[aaarrr]

Или что? тут не поможет данное решение????????

Поможет, конечно, хотя лажа на самом деле в tasks.c:

Код

#if portSTACK_GROWTH < 0
{
    pxTopOfStack = pxNewTCB->pxStack + ( usStackDepth - 1 );
}
#else
{
    pxTopOfStack = pxNewTCB->pxStack;    
}
#endif

Помимо направления роста стека (portSTACK_GROWTH) должен быть еще один параметр, определяющий пре- или постдекремент при стековых операциях.

Почему надо думать об ABI, зачем создавать какой то свой интерфейс вызовов, почему тупо не следовать уже написанному и то только в портируемой части? вот что я не пойму?Как? простите инициализация стека корреным образом влияет на ОС?

Да кто Вас призывает придумывать свой интерфейс вызовов? Как раз и нужно следовать существующему. Просто при создании ОС нужно учитывать все многообразие архитектур, а не забивать жестко направление того же стека.

[ddiimmaa]

Вчера я выложил в Интернет более менее работаюшую версию моей ОС-и. http://irtos.sourceforge.net/

Назвал её iRTOS. Скачиваете отсюда -> http://sourceforge.net/projects/irtos/

На данный момент ОС работает
1 на АVR mega 128. (WinAVR + AVRStudio )
2 на ПК, создавая потоки через POSIX Threads
В последнем случае генерируеться отладочная информация, которая может быть обработана
c с помошью irtos_events -- программы на Qt что рисует графики (см скриншоты на http://sourceforge.net/projects/irtos/ ).

Пока она создаёт потоки с приоритетами и может лишь переключать контексты потоков.

Приглашаю посмотреть и заценить сие "чудо без перьев" кому любопытно. Так как реально она пока работает не стабильно.

Жду ваши гневные и смешные отзывы. Тута или в форуме http://sourceforge.net/forum/forum.php?forum_id=811508