[HarmEr 0]

В одном из проектов у меня было:

1. Самый нижний уровень: элементарные транзакции по SPI с FLASH/FRAM - чтение непрерывного блока байт, запись непрерывного блока байт, стирание страницы FLASH и т.п.

Диспетчеры, журналы, атомарный доступ, "разные службы" - это как бы уже часть ОС и подобия файловой системы.

Автор то тут четко выразился что ему нужны только работа с каналами передачи.

1-2 имхо разделять на собственное АПИ если это не высокоструктурированный проект или часть ОС смысла нет, все в один файл, 1 объявить статиком, а 2 сделать в виде АПИ.

Если все разносить по файлам, то у компилятора не будет возможность глубоко оптимизировать все это.

[jcxz 184]

Диспетчеры, журналы, атомарный доступ, "разные службы" - это как бы уже часть ОС и подобия файловой системы.

ОС - это только управление задачами. Всё остальное - дополнительные модули.

 

Автор то тут четко выразился что ему нужны только работа с каналами передачи.

Это где Вы такое узрели в его посте??? Из каналов передачи там только UART.

 

1-2 имхо разделять на собственное АПИ если это не высокоструктурированный проект или часть ОС смысла нет, все в один файл,

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

Разделение этих двух частей, даёт возможность легко наращивать функциональность при добавлении других устройств на данной SPI-шине: планировщик транзакций (арбитр шины) - отдельно, обработка самих транзакций - отдельно для каждого устройства на шине - своя для каждого устройства.

Своё разбиение я привёл как пример. В другой прикладной задаче/приборе вполне возможно будет другое разбиение.

[HarmEr 0]

ОС - это только управление задачами. Всё остальное - дополнительные модули.

ОС это распределение памяти, машинного времени и механизмы доступа и синхронизации.

 

Это где Вы такое узрели в его посте??? Из каналов передачи там только UART.

I2C, ADC тоже можно считать каналом передачи :) но в целом да, он хочет иметь доступ к разной периферии, не только передавать данные.

 

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

Разделение этих двух частей, даёт возможность легко наращивать функциональность при добавлении других устройств на данной SPI-шине: планировщик транзакций (арбитр шины) - отдельно, обработка самих транзакций - отдельно для каждого устройства на шине - своя для каждого устройства.

Своё разбиение я привёл как пример. В другой прикладной задаче/приборе вполне возможно будет другое разбиение.

Ну я свою классификацию тоже привел как пример, ибо писал LockFree OS и она перенесена в том числе под STM32.

 

Но до конца не понятно где заканчивается его нижний уровень, и что он имеет ввиду под верхним, нужно ему АПИ или интерфейс драйвера для какой то RTOS.

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

 

[leocat 0]

Нет. Ибо на Cortex-M ни линух ни тем более винда - невозможны.

Да ладно?!

http://www.nuttx.org

[Eddy_Em 1]

Линукс не установить на систему без MMU. Так что, не надо фантазировать!

[ichthyandr 0]

Нет. Ибо на Cortex-M ни линух ни тем более винда - невозможны.

а freertos ?

[jcxz 184]

а freertos ?

Конечно да.

[one_eight_seven 3]

Линукс не установить на систему без MMU. Так что, не надо фантазировать!

uCLinux

 

P.S. можно, конечно, ещё эмуляторы писать (и некоторые это делают), но зачем...

Изменено 22 февраля, 2018 пользователем one_eight_seven

[Aldec 0]

из перриферии: UART, ADC, COMP, DAC, I2C, Timer.

Может оказаться что это драйвер двигателя, тюнер SDR, анализатор спектра или вибродатчиков.... линукс и ртос там не очень требуется.

[jcxz 184]

uCLinux

uCLinux != Linux

[=pcb= 0]

Линукс не установить на систему без MMU. Так что, не надо фантазировать!

Можно.

1) ucLinux на ядре 2.6. версии

2) Linux на ядре от 4.6 версии на жирные камни, а ля 429, с недавних пор.

 

так что можно уже фантазировать открывшиеся новые возможности...

[jcxz 184]

2) Linux на ядре от 4.6 версии на жирные камни, а ля 429, с недавних пор.

Ну-ну... с недавних пор в "а ля 429" самопроизвольно возник MMU???

 

так что можно уже фантазировать открывшиеся новые возможности...

Фантазировать можно сколько угодно, но реальность безжалостна..... :laughing:

[Eddy_Em 1]

ucLinux

Это никак к линуксу не относится!

Еще раз: нет MMU == нет линукса!

Хватит меня уже бредом кормить!

[one_eight_seven 3]

Это никак к линуксу не относится!

Это форк линукса. Более того, много наработок uCLinux'а пошли в основную ветку. Так что относится и ещё как относится

 

Еще раз: нет MMU == нет линукса!

Хватит меня уже бредом кормить!

Есть только два мнения - моё и неправильное. Очень правильная позиция, да.

 

uCLinux != Linux

Debian != Linux

Fedora != Linux.

Linux != Linux.

 

Ваши слепые верования не имеют ничего общего с реальным положением вещей.

[Eddy_Em 1]

Ну хватит уже чушь нести!!!

Почитайте хотя бы, что такое линукс!

И да, дебилиан уже не линукс, а тем более — федора! Все, что перестало подчиняться требованиям UNIX-way, можно смело называть мастдайкой и топить в унитазе.

Эдак вы, батенька, такое откровенное дерьмище, как ондроед, линуксом обзовете!

Изменено 22 февраля, 2018 пользователем Эдди