|
|
  |
Пишу ОС РВ, Вот пишу ОС Реального времени, у какого какие предложения? пожелания? |
|
|
|
Jan 28 2009, 13:55
|

embarrassed systems engineer
    
Группа: Свой
Сообщений: 1 083
Регистрация: 24-10-05
Из: Осокорки
Пользователь №: 10 038

|
Цитата(zltigo @ Jan 28 2009, 15:38)  Так я в общем-то это и делаю, точнее лучше  , для текущей задачи задачи известен указатель на ее Task Control Block он и сохраняется в менеджером памяти в Memory Control Block. Я вот тут как-то задумался - у меня потребность знать какая задача выделила память редко возникает. Под Windows - в User Mode ОС сама следит и чистит, в Kernel Mode драйверу обычно тоже все равно какой контекст. В простых ОС для embedded понятие задача вообще упрощено и сведено до потока - в системных сервисах запоминать TCB тоже не особо нужно. Я как-то стараюсь привязать память к объекту который ее использует, а не к потоку. Например, сокет TCP - создается, живет, для него выделяются pbuf-ы, ведется четкий учет, квотирование, в самом pbuf есть ссылка на socket-владелец. А вот TCB - нету. Сокет может быть создан в одном потоке, выполнять обмен в совершенно другом, и завершить свою жизнь в третьем. И какой смысл помнить какой поток выделял для него pbuf? Аналогично для USB pipe - вся память "записана на владельца" - структуру описывающую pipe, и поля TCB там тоже как-то нету. Конечно, это не значит в общем случае что TCB знать не полезно, просто подход, наверное, другой.
|
|
|
|
|
Jan 28 2009, 13:57
|

Йа моск ;)
     
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610

|
Плохо только то, что армовский IAR почему-то не склеивает функции. Ну типа Код foo1(i, j);
foo2(i) { foo1(i, 0); }
foo1(i,j) { ..... } AVR'овский отлично изготавливает нечто типа Код foo2: j=0 foo1: .... ret , а армовский, к сожалению, так не делает
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
Jan 28 2009, 14:04
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(VslavX @ Jan 28 2009, 16:55)  Например, сокет TCP - создается, живет, для него выделяются pbuf-ы, ведется четкий учет, квотирование, в самом pbuf есть ссылка на socket-владелец. Значит там хранится не указатель на TCB, а на то, что хотите. Более того, что на самом деле у меня, например, для блока памяти выделенного очереди там на автомате сохраняется, естественно указатель на Queue Control Block. Ну а в самом QCB уже TCB  .
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Jan 28 2009, 14:38
|

embarrassed systems engineer
    
Группа: Свой
Сообщений: 1 083
Регистрация: 24-10-05
Из: Осокорки
Пользователь №: 10 038

|
Цитата(zltigo @ Jan 28 2009, 16:04)  Значит там хранится не указатель на TCB, а на то, что хотите. Более того, что на самом деле у меня, например, для блока памяти выделенного очереди там на автомате сохраняется, естественно указатель на Queue Control Block. Ну а в самом QCB уже TCB  . Не-а, я в принципе объекты к потокам не привязываю со стороны объекта. Потоки - да, ессно, имеют ссылки на объекты, а вот наоборот - нет. Это позволяет без проблем использовать объекты в произвольном контексте и, при желании, в нескольких потоках одновременно. Хотя, ессно, этим злоупотреблять не стоит и нечасто реально используется (стандартная практика - "где родился - там и сгодился" - ну и "помер" в итоге, когда уже объект стал не нужен ). Обойтись в объектах без ссылок на потоки вполне реально, ессно, обратная связь есть - куда ж без нее, но явной привязки к потоку нет. Пример: тот же TCP сокет при создании получает ссылку на объект типа "событие", по которой он будет оповещать приложение о своей жизни. А какой поток это событие будет ждать - "шерифа это не волнует"  . Цитата(Rst7 @ Jan 28 2009, 16:27)  Не удивит  А что тогда не нравится? Вот Ваш пример: Код 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 встречал - там он даже что-то вроде архиватора Лемпеля-Зива применяет - ищет в совершенно разных функциях одинаковые куски, составляет из них "словарь" и вовсю его "пользует".
|
|
|
|
|
Jan 28 2009, 14:43
|

Йа моск ;)
     
Группа: Модераторы
Сообщений: 4 345
Регистрация: 7-07-05
Из: Kharkiv-city
Пользователь №: 6 610

|
Цитата А функции, да, не конкатенирует Дык я об этом. Сделайте #pragma optimize=no_inline и поймете о чем я. Цитата там он даже что-то вроде архиватора Лемпеля-Зива применяет - ищет в совершенно разных функциях одинаковые куски, составляет из них "словарь" и вовсю его "пользует". Ну кросскол - это от лукавого, я так мыслю.
--------------------
"Практика выше (теоретического) познания, ибо она имеет не только достоинство всеобщности, но и непосредственной действительности." - В.И. Ленин
|
|
|
|
|
Jan 28 2009, 17:15
|

Участник

Группа: Validating
Сообщений: 27
Регистрация: 12-12-08
Из: Ижевск
Пользователь №: 42 419

|
Цитата(sergeeff @ Jan 28 2009, 04:35)  Это для общего развития или сейчас творческий простой? Это нужен инструмент аля FreeRTOS но с меньшими аппетитами по RAM и с правом копаться в ядре, с тем чтобы получившееся можно было и в коммерческих разработках выдавать. Цитата(MrYuran @ Jan 28 2009, 09:40)  А scmRTOS? Вроде бы как раз, для дохленьких контроллеров задумана, с полкилом рама, с минимизацией издержек. Единственный минус (имхо) - написана на плюсах. Хотя для кого-то это плюс. По-моему, лучше подключиться к раскрученному проекту, чем начинать собственный с нуля Вот вот в том то и дело что она Си плюс плюснутая. А так ничего ОC, правда тоже есть недочёты, в виде жёсткости системы приоритетов. Так например не может быть двух задач с одинаковыми приоритетами Цитата(AlexandrY @ Jan 28 2009, 11:40)  Ну покажите класс. Кто вас знает, мож вы гений. 512 Kb RAM-а - это очень много. Не советую ориентироваться на такие числа. Ограничтесь лучше 2-я Кб. Во всяком случае для uCOS, ThreadX, CMX и других мощных осей этого вполне хватает для пары тройки задач. Ну конечно она должна влезать в сотни бацт по ОЗУ. Я это просто прикинул, что при 512 кб уже смысла нет ставить то, что я думаю Цитата(AlexandrY @ Jan 28 2009, 11:40)  Вообще-то нынче каждый уважающий себя компилер идет с встроенной RTOS. У CodeWarrior - MQX, у Keil - RL ARM, у Tasking - OSE, у IAR - PowerPac и т.д Ну судя этой логике gcc -- не уважающий себя компилер Цитата(AlexandrY @ Jan 28 2009, 11:40)  Этой уникальной фичей мог бы стать realtime профайлер. Все как бы декларируют себя RTOS-ами, но реального тулса для тюнинга приоритетов задач, нарезок временных интервалов активности задач, тюнинга шедулеров в готовом дивайсе никто не предлагает. Всегда нужен PC, софтварный спец агент тормозящий приложение и захватывающий ресурс и IDE online. А можно по подробнее что есть realtime профайлер и какую статистику он должен собирать? Цитата(AlexandrY @ Jan 28 2009, 11:40)  Третья уникальная фича - проработка протокола вплоть до физического уровня межпроцессорного обмена. Это оч востребованная фича, поскольку времена когда все делается на одном проце стремительно уходят. Хм а вот тут тоже не совсем ясно? Что имееться в виду? Соединять несколько процов по какому-либо протоколу? С целью? Протокол обычно соответствует часто использемым функциям, т. е. реализует базовую функциональность чего-либо! А тут малость мне не понятно что может быть общего между различными устройствами в которых есть не один ЦП? И честно говоря, по этому ничего не видел ни инфы ни протоколов ни таких ОСей может подкините что-нибудь! Цитата(zltigo @ Jan 28 2009, 13:09)  Для "немного" того-другого просто надо доработать ту-же FreeRTOS. Хотели немножко памяти? - небольшие резервы по памяти там прямо под ногами лежат. Можно можно, но вот в один прекрасный день (хотя у нас в России пока на это мало глядят) мне тут скажут "мужик -- ты же доработал FreeRTOS" -- ну тогда у тебя проект на GPL -- давай выкладывай все свои исходники. Цитата(zltigo @ Jan 28 2009, 13:09)  А при сильно сэкономить и сделать систему под 512 байт, так такая система будет уродлива уже для десяткокилобайтовых... А как на ваш взгляд scmRTOS? Уродлива для десяткокилобайтовых? Цитата(VslavX @ Jan 28 2009, 15:58)  Дык, 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 нельзя полностью работать на статической памяти.
--------------------
|
|
|
|
|
Jan 28 2009, 17:42
|

embarrassed systems engineer
    
Группа: Свой
Сообщений: 1 083
Регистрация: 24-10-05
Из: Осокорки
Пользователь №: 10 038

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

Участник

Группа: Validating
Сообщений: 27
Регистрация: 12-12-08
Из: Ижевск
Пользователь №: 42 419

|
Цитата(VslavX @ Jan 28 2009, 21:42)  Посмотрите 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 и того меньше, ну да ладно нечего пинять на других коли сам не сделал Цитата(zltigo @ Jan 28 2009, 21:39)  Там модифицированный GPL. Почитайте, ну может десять баксов пожертвуйте.... Ну и если действительно заметно доработали, то прежде, чем кто-то это скажет Вы сначала должны зачем-то выложить исходники  Да и купить на самом деле можно OpenRTOS при малейшей необходимости - время дороже  . Мда, а если я хочу выложить исходники (ну типа посмотрите как я крут  ), ну да ладно если бы да кабы.. да росли бы грибы....
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|