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

[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 - надо проверять, пока не пользую.