Стоит вопрос возможности использования обеих ОСей на кристалле. Кроме собственно ОСей в ROM'е кристалла есть драйвера периферии и собственно самого чипа. Кроме этого в RAM'е будут приложения пользователя, которые он пишет под определённую ОС.

Вопрос только в этих двух ОС. Возможно ли написать некий wrapper, который бы позволил пользоваться системными вызовами обеих ОСей. Возможно в этот wrapper войдёт не весь функционал, только общий для обеих ОСей и тот который необходим для функционирования драйверов.

Я лично не видел в своей жизни, чтобы существовал один драйвер как для Linux, так и для Windows.

Пользовательское приложение опять же нужно переписывать кардинально или тут тоже можно воспользоваться Wrapper'ом?

Существуют ведь какие-то интерпретаторы, которые позволяют питоновскому коду запускаться как на Linux, так и на Windows.

Коллеги готов выслушать ваше авторитетное мнение.

С каких это пор у FreeRTOS есть драйвера?
У нуклеуса тоже их механизм драйверам с натяжкой только назвать можно.

И какому простому юзеру интересны сервисы самого ядра оси? Интересен прикладной фреймворк.
Какие либы, какие стеки, какие GUI.
С этой точки зрения эти две оси вооще не сравнимы.

я не говорил, что ОСи содержат драйвера, я говорил, что ROM чипа будет содержать драйвера.

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

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

Когда юзеру дают фреймвок уже запрограммированный в железе, то ему надо сделать песочницу. К реальным сервисам оси допускать нельзя.
Любой вызов функций фреймворка юзером должен сопровождаться проверками на отсутствие конфликтов с работой ядра, его ресурсами и проч.
Нельзя давать юзеру играть приоритетами и очередями задач. И т.д.

Причем юзеру будет глубоко безразлично что там FreeRTOS или что другое.

Проще тогда уж портировать .NET Micro Framework поверх выбранной RTOS. И это будет идеологически правильно.

юзер чипа - он же разработчик.
мы с вами и все здесь присутствующие пользуются сервисами ОСи? почему остальные не могут?

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

Смотрю вот драйвера, которые идут с FreeRTOS'ом - файл drivers/ST/STM32F10xFWLib/src/stm32fxxx_eth.c
он пользуется API RTOS'а vTaskDelay.
Такого вида драйвера и будут в ROM'е. Но захотелось мне, не меняя драйвера, использовать не FreeRTOS, а Nucleus.
В Nucleus'е есть TCC_Task_Sleep. Так вот идея была создать wrapper для этих двух ОСей.

Понятно, что это убого. В идеале использовать ОСи, которые имеют один стандарт API - будь то POSIX, uITRON и т.д.

Это просто пример. Какими ещё вызовами FreeRTOS и Nucleus драйвера могут пользоваться?

Ну рассмешили. ))
Какие же это драйвера.
Это кривые студенческие либы написанные в Тунисе и выдаваемые ST за некий HAL уровень. Набитые багами под завязку.
Проще мануал на проц запомнить наизусть чем понять дикую логику тех парней которые придумали такое API.
Если приглядитесь, то увидите там кучу мест с задержками на программных опросах.
В тех либах вообще нет ни одной процедуры заточенной под RTOS. Во FreeRTOS эти либы притянуты за уши.

Если еще более вникните в тему, то узнаете, что в TCP стеках FreeRTOS и нуклеуса абсолютно разная структура сетевых буферов.
Т.е. в принципе нельзя заюзать процедуры работы с Ethernet пакетами от LwIP для нуклеуса.

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

Александр, спасибо, что участвуете в дискуссии.
Любым драйвером периферии или middleware на основе этого драйвера, который бы использовал во всю API Nucleus'а не поделитесь?

Так дело в том, что драйверов под RTOS у меня нет.
Я не делаю HAL, потому как в малых системах он совершенно не нужен и надуман.
А потому работа с одной и той же периферией у меня может производится из разных мест программы.
Т.е. даже выделить набор подпрограмм относящихся к определенной периферии из многомегабайтных исходников почти нереально, все сильно переплетено.
Эти переплетения и вам не дадут написать "драйвера", либо вы так ограничите возможности платформы, что там останется только вывод в UART c приемлемой эффективностью.

Т.е. у вас неподдерживаемый лапша-код?

Речь о периферии.

Кстати, "бизнес логика" приложения у вас в отдельном потоке или тоже размазана по всем потокам?