TNKernel v.2.6 имеет порты ARM, Cortex-M3 и новый порт TI MSP430x.

Переключение контекста в TNKernel v.2.6 работает заметно быстрее (порты ARM, Cortex-M3) по сравнению с предыдущими версиями.
The mutex ceiling protocol в версии 2.6 более "lightweight" по сравнению с предыдущими версиями - в соревновании "скорость против features" победила скорость (на данный момент).
Код mutex ceiling protocol в версии 2.6 основывается на коде. написанном Vyacheslav Ovsiyenko для его версии TNKernel.

Спасибо Vyacheslav Ovsiyenko, Audrius Urmanavicius, Alex Borisov, Michael Fisher за их улучшения и замечания.


http://www.tnkernel.com

под мелкочип пока не предвидится?

Это надо обращаться к Александру Борисову.

А насколько критично выравнивание стеков на 8?
В исходниках не нашел ничего , что мне запрещает вместо

#if defined (__ICCARM__) // IAR ARM
#pragma data_alignment=8
#endif
align_attr_start unsigned int task_xxx_stack[TASK_XXX_SIZE] align_attr_end;

написать просто

unsigned int task_xxx_stack[TASK_XXX_SIZE];

Получится выравнивание на 4 (для ARM7 и Cortex).

Вот как раз для ARM7 и Cortex и нужно выравнивание на 8.

Для чего? Насколько критично?
Хотелось сделать странное так:

но выяснилось, что malloc и так на 8 выравнивает.

Плавучка может отвалиться без выравнивания. Вообще, это требование стандарта, поэтому критично на 100%.

пример для STM32 под новые библиотеки версии 3 будет? а то уже два дня разбираюсь боюсь еще дня 3-4 провожусь

Попытался портировать TNNet на LM3S6965 и встал на грабли, уж больно его Ethernet-контроллер не похож на LPC. Может кто-нибудь портировал стек на это чудо?

А какие с ним трудности? EMAC у LM3S простой совсем.

Трудности не с пониманием EMAC у LM3S, а с прикручиванием его к TNNet. Я не совсем понимаю, что от драйвера требуется.

Юрий,
возникли вопросы по использованию буферов в TN-Net.
1) Правильно ли я понимаю, что при отправке IP пакета он будет состоять из минимум двух TN_MBUF, в одном заголовок Ethernet, во втором - сам пакет?
2) Смысл существования HI_BUF, если стек всяко использует цепочку из MID_BUF для больших пакетов? Специфика контроллера Ethernet у LPC?
3) Вы возможно сталкивались с контроллером Ethernet у LM3S. Нет ли у вас идей, как лучше его подружить с TN-Net?

вопрос по функции tn_event_wait при вызове функции, если ожидаемые флаги не установлены, т.е. функция возвращается с параметром TERR_TIMEOUT, не возвращает значение в параметр " * p_flags_pattern".
имхо это не совсем правильно. приведу пример:
мне нужно быстро разбудить задачу по одному из битов битовой маски флага, а по другому не критично, например достаточно его проверять каждые 100 системных тиков. поэтому я вызываю функцию в следующем виде:

на самом деле для проверки некритичного флага EVENT_2, мне придется дополнительно вызывать функцию tn_event_wait_polling с маской 0xFFFFFFFF предварительно обнулив флаг, т.е. совершаю несколько дополнительных неоправданных действий, тем более что переменная все равно создана, занимает память

еще ситуация усугубляется, если флаг был выставлен, затем очищен функцией tn_event_clear, но перед вызовом функции n_event_wait не обнулен, получается что по таймауту в переменной flag либо остается прошлое значение, либо вообще случайное. и флаги которые не вызывают "подъем" задачи мы вообще не видим

1) Да
2) HI_BUF нужен только для приема - чтобы не городить цепочку DMA буферов(длина принимаемого пакета еще неизвестна,
а память под него выделять уже надо - поэтому здесь используется HI_BUF размером MTU)
3) C Ethernet у LM3S не работал



Ожидание события в синхронизационном элементе ( в том числе и Event) надо использовать только тогда, когда по этому событию задача должна проснуться и получить управление ( т.е. проверять флаг в Event каждые 100 системных тиков идеологически неверно - Event не предназначен для такого использования).
Почему бы в этом случае не использовать просто глобальную переменную и проверять ее по timeout Вашего Event ?

Глобальные переменные в общем случае зло и если есть готовый механизм флагов, почему его не использовать, тем более что нужен один бит, и городить ради этого отдельную сущность в виде семафора или глобальной переменной кажется лишним. Впрочем, я только учусь работать с ОС, и возможно еще не проникся идеологией
ЗЫ: похоже теперь плотно подсел на TNKernel, уж очень понравилась. Спасибо!

Вроде понял, но не согласен с таким подходом. ИМХО собрать цепочку из MID_BUF в конечном счете будет выгоднее с точки зрения использования памяти.


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