Здравствуйте!

У меня вопрос к разработчику ОС Юрию и всем, кто допиливал ось под себя(VslavX и т.д.), озвученный в названии темы. Будет ли такой порт? Планирую работать с STM32f4.
Планируется ли дальнейшее развитие TNKernel?

Заранее благодарен за ответы.

Если не предполагается использование FPU, то, имхо, должен подойти существующий порт от Cortex-М3.
У меня на полке лежит нераспечатанный Discovery STM32F4 - никак руки не дойдут попробовать (работы всякой многовато). Очень надеюсь в ближайшее время таки до кита добраться и сделать порт с "честным многозадачным" использованием FPU - тут тема недалеко пробегала с интересной идейкой по переключению контекста FPU "по требованию". Мне будет несложно пропатчить основную ветку ОС самому (сделать и выложить пробный проект на упомянутый Discovery) или поделиться наработками с автором. Вопрос только - когда...

А можно ссылку на тему, где обсуждалась идейка?

Вот здесь обсуждалась.
Возможно пригодится ещё эта тема.

Спасибо за ответ. Про Ваш Discovery STM32F4 я в курсе - читал другую темку (занятное было состязание с scmrtos). Хотелось бы использовать по полной все возможности STM32F4. Поэтому если Вы сможете это провернуть - это было бы просто великолепно.
А по поводу дальнейшего развития этой оси вопрос остается в силе

Если бы я стал писать порт TNKernel для Cortex-M4, это было бы что-то похожее на FreeRTOS port.
Вячеслав предлагает более advanced решение, так что, IMHO, было бы лучше, если бы порт написал он..

ОК, я постараюсь найти немножко времени чтобы сделать порт для STM32F4xx, особо он мне "прямо сейчас" не нужен, но тема мне просто интересная. Этапы я вижу тут такие:
1. "освоить" STM32F4xx, написать плагин к своему отладчику-программатору, дополнить хидеры (на основе F2xx) и прочее
2. сделать собственно порт в привычной наработанной среде
3. "прикрутить" порт к официальному релизу (под GCC наверное)
4. Потестить это все с "плавучкой" в многопоточке
"Вечерами" тут работы на неделю-другую, постараюсь выкроить время.

Update: сегодня получилось поработать - пункт 1 почти выполнен. Теперь умею читать-писать по JTAG процессоры F405/407/415/417/427/437 (ессно, проверил 407 только). Порт для Cortex-M3 спокойно завелся на STM32F407 (пока без FPU). Более того, на старте пошла та же самая бинарная прошивка что и на STM32F207. Поднял частоту до 168МГц (со 120 для F2xx), поигрался с временем переключение контекста (940 нс @168MHz ART prefetch выключен (имитация ревизии А), и 900нс при включенном prefecth ("полноценная" ревизия Z).

VslavX!
Благодарю за инициативу! Надеюсь, что это не сильно будет Вас напрягать. Вы написали, что планируете прикрутить порт к оф релизу. Насколько я знаю, у Вас есть и собственные наработки для TNKernel(доделки, переделки оф релиза). Можно узнать в чем они заключаются, какие достоинства(недостатки) и, если возможно, посмотреть на исходники Вашей модификации.

С Уважением.

Увы, но руководство пока против чтобы открывать полные исходники модификации. В субботу спрашивал (есть желание на SourceForge выложить улучшения и разные порты - ожидается для NIOS, и, возможно, для MIPS), но снова получил прямой запрет .
Архитектурно отличается несильно - удалена таймерная задача (жалко дважды переключать контекст на каждый системный тик) - обработка перенесена в прерывание, с периодическим разрешением прерываний (чтобы не страдал реал-тайм), принципально выброшена часть "стремных" функций типа tn_task_terminate(). Оптимизирован (по аппаратуре вычислется вложенность) счетчик вложения прерываний, нет флагов запрета переключения контекста, часть функций работы со списками CDLL сделана макросами. Есть точный и грубый профайлеры, монитор системных объектов, синхронизированная отладка по JTAG/COM. Оптимизация по мьютексам вроде уже включена в v2.6. Возможно кое-что из остального тоже - я автору тексты отсылал. Посмотрю последний официальный релиз и если какие изменения я смогу быстро и прозрачно прикрутить к официальной ветке - выложу.

P.S. Сейчас больно слезаю с IAR-а (имел глупость написать несовместимые хидеры с использованием фичи @ физический адрес). Потому как нет безглючной версии IAR для Cortex-M4 (все IAR 6.xx с какими-либо выбрыками), перехожу на CodeSourcery GCC. Заодно будут вкусняшки типа LTO и C++ 11-ый (это прикладникам).

В последнее время пользуюсь GNU Tools for ARM Embedded Processors (https://launchpad.net/gcc-arm-embedded/+download)
- на моих проектах работает хорошо..

Спасибо, обязательно посмотрю. Любопытно будет сравнить с менторовским GCC.

Не забывайте про http://yagarto.de ) тоже ничего

Автор вроде бы обещал, что проект завершён. В качестве альтернативы предлагал всё тот же GNU Tools for ARM Embedded Processors.

linaro gcc еще есть,
github gcc(linux'овые сборки) - недавно перешел именно на него

Я именно о нём и говорил. Где-то договорились этот тулчейн называть именно GNU Tools for ARM Embedded Processors, а linaro - это больше в сторону Cortex-A семейства.

Выполнил черновой перенос существующего кода порта для Cortex-M3 (в который буду добавлять код для M4F) под GCC.Погонял тестовый код на Discovery STM32F4xx под IAR 5.41, IAR 6.40, GCC CodeSourcery (4.7.2 менторовский релиз 63) и упомянутый в этой ветке GNU Tools for ARM Embedded Processors.

По компактности сгенерированного кода (в порядке от меньшего к боьшему размеру)
- IAR 5.x - 11632
- IAR 6.x - 13344
- GCC CS - 13344
- Toolchain - 14816

По быстродействию (переключение контекста / Dhrystone, не особо показательно, разница маленькая):
- IAR 6.x (0.920 мкс) - 246502 DS
- IAR 5.x (1.080 мкс) - 246850 DS
- GCC CS (1.040 мкс) - 250490 DS
- Toolchain (1.080 мкс) - 250936 DS

Тест Dhrystone гонял, но он тоже не показателен - примерно 250000 у всех, +/- пару процентов. При модификации кода показатели меняются (видимо смещается как-то оно во флешке и начинает играть акселератор).

Исходники компилируются обоими компиляторами GCC - CS/Toolchain, никаких уcловных веток между ними нет. Но мне пока CodeSourcery нравится больше - документация получше, код покомпактнее. И вроде бы поддерживает LTO, но ключики -flto компилятору и линкеру на результирующий файл влияния не оказали. Toolchain на -flto варнингует.

В-общем, следующий шаг - уже буду собственно плавучку прикручивать, тут CodeSourcery в бесплатной редакции Lite может подбросить фокусов - вроде там были искусственные ограничения на hard-FPU. Буду разбираться дальше.

А вот с этим: arm-none-eabi кто нибудь, работал?

Именно про него парой постов выше упоминали аж несколько авторов.

Именно Линуксовая версия интересует? Я тестировал в этом топике версию с того же launchpad.net, но под Cygwin. Вроде же разницы на генерируемом выходном файле быть не должно?

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

Разницы нет.


Насколько мне известно, этот тулчейн заточен под Cortex-M/R семейства.

По теме переключения контекста FPU по требованию (по исключению) тоже хотелось бы услышать мнение All. После обдумывания мне кажется что хранить контекст FPU в стеке уже нельзя - иначе его будет невозможно восстановить по требованию (задача выполняется уже при произвольном стеке, и тут ей понадобился FPU - а стек-то уже тю-тю). Поэтому предлагается хранить контекст в блоке задчаи - TN_TCB. Но тут минус что контекст FPU большой - от 128 байт, и не каждая задача использует FPU - не всем оно надо. Поэтому предлагается завести пул блоков, для сохранения контекста. Когда задача начинает юзать FPU ей оттуда выделяется блок (ссылка храниться в TCB) и далее она пользуется блоком. При завершении задачи - блок возвращается. Таким образом пользователь может определить пул нужного размера - по числу задач работающих с FPU. Поддержку FPU в обработчиках прерываний/исключений думаю не реализовывать - код усложняется, скорость падает.

P.S. А чем бы float/double на консоль выводить, а то мой самописный printf не поддерживает %f, %e, %a - наверное, пришло время добавить эту поддержку. Посмотрел реализации glibc - так там еще длинную арифметику надо. uglibc тоже не радужно. Может кто-то присоветует относительно более простое решение?

Update: разобрался я с FPSCR, он автоматически в стеке сохраняется. При моем методе надо будет делать руками, главное - не забыть

Я бы для начала попытался проанализировать плюсы и минусы вашего метода при различных сценариях использования.
Сценарий первый: в данный момент времени две задачи (или более) работают с плавучкой. При таком сценарии, насколько я понял, после каждого переключения контекста на "плавучую" задачу будет происходить много чего: исключение, выяснение причины, сохранение контекста предыдущей задачи, поиск свободного пула для сохранения контекста новой задачи... То есть, это всё будет работать сильно медленнее, чем простой вариант а-ля FreeRtos.
Сценарий второй (выигрышный для вашего варианта): Все задачи (или все кроме одной) перестали работать с плавучкой. В этом случае ничего не происходит, всё работает как M3.
Мне кажется, что второй вариант будет встречаться значительно реже. К тому же, к FreeRtos-ному варианту можно просто добавить функцию окончания работы с плавучкой, типа tn_end_fpu(), в которой будет сбрасываться бит CONTROL.FPCA. В этом случае он не уступит вашему варианту и при втором сценарии (если конечно все задачи вызовут tn_end_fpu()).

Основной анализ проделан в статье ARM на которую Вы уже давали ссылку. Там же оба подхода довольно подробно рассмотрены. Из дополнительных минусов второго ("переключение по требованию") я вижу невозможность (хотя, скорее громоздкость и неудобство) использования FPU в обработчиках прерываний/исключений. Зато снижается оверхед при переключении контекста и interrupt latency.


С анализом сценариев у меня туго . На данный момент у меня такого рода задачи, что я вообще не понимаю зачем нужен FPU. Будучи студентом в университете приходилось заниматься численным моделированием плазмы. На Фортране-IV. На СМ-4. Предметом гордости было наличие блока FIS. Потом кафедра купила СМ-1420 с полноценным FPP - радости было. Но сейчас таких задач у меня нет - скрипач FPU не нужен. Поэтому мне сложно сказать какой сценарий более частый и предпочтительный, и планирую реализовать оба подхода, с выбором по флагу компиляции. Второй сценарий сделаю несколько упрощенным - для начала не буду заморачиваться с пулом, просто буду хранить контекст в TCB.

Если кто-то реально использует (или только планирует использовать) FPU в своих приложениях - то было бы интересно узнать какой типовой способ использования в разрезе RTOS - сколько задач используют FPU, есть ли использование FPU в обработчиках прерываний и прочее.


ИМХО такая функция полезна при обоих подходах. Если пользователя заботит быстродействие то ему надо предоставить возможность такой настройки.

Update:
Вот такое "понравилось":

"GNUC C compiler (gcc)
If a program is compiled with the FPU option, gcc might make use of the floating-point registers
if register pressure is high, and running low on available registers for data processing. In some
cases, the memory copy might also utilize floating-point registers to hold data"

Соглашение ABI при наличии FPU разрешает его почти произвольное использование - даже если нет работы с данными типа float/double, регистры FPU все равно могут использоваться компилятором, хотя бы в качестве быстрого хранилища переменных. Поэтому весь код обработчиков прерываний (включая системные функции типа tn_sem_isignal()) нужно компилировать с -mfloat-abi=soft. И библиотеки тоже с такой опцией. И, соответственно, приложение - иначе несовместимость линковки (хотя, проверю линковку "soft" и "softfp", есть шанс). И кому такое надо - вообще не моги пользовать FPU? Получается что второй подход для систем с отдельной линковкой приложения. Разрешить использование FPU в обработчиках можно, но для этого надо для каждого сделать отдельную функцию-переходник в котором явно запрещается FPU - чтобы FPU-код в обработчике вызвал исключение. И такой переходник скушает почти весь выигрыш в быстродействии

Из компиляторов пока только Keil можно заставить не использовать FPU для "неплавучих" целей. GCC и IAR таких флажков не имеют.

Реализовал оба метода переключения контекста.
Метод 1: использование автоматического "ленивого" сохранения контекста FPU в стеке, полностью аналогичен коду порта scmRTOS
Метод 2: метод переключения контекста по требованию. Имеется системная переменная - указатель на TCB задачи, контекст которой загружен в данный момент в регистры FPU. При переключении задачи эта переменная сравнивается с TCB загружаемой задачи. При совпадении доступ к FPU разрешается через биты регистра CPACR, иначе доступ запрещен. Когда текущая задача, не владеющая контекстом FPU пытается выполнить плавучую операцию - происходит исключение, сохраняющее регистры FPU в TCB задачи-владельца, и загружающее нужный контекст текущей задачи.
Предварительно потестировал оба метода.
Для начала картинка GCC<->IAR без поддержки FPU
Нажмите для просмотра прикрепленного файла
Мой взгляд, разницы принципиальной нет.

Теперь картинка сравнения разных методов, для компилятора GCC.
Нажмите для просмотра прикрепленного файла
FPU1 - метод 1
FPU2 - метод 2
none - ни одна из двух тестовых задач не обращается к FPU
Task1 - только первая тестовая задач обращается к FPU
Task2 - только вторая тестовая задач обращается к FPU
Task12 - первая и вторая тестовая задачи обращаются к FPU

Для метода 1 следует помнить, что FPCA бит в регистре CONTROL является sticky - то есть если задача хотя бы раз (возможно в далеком прошлом) обратилась к FPU и теперь про него вообще забыла - крайняя левая картинка уже использоваться не будет - работает одна из правых. С явным сбросом FPCA могут быть проблемы, так как компилятор может неявно использовать FPU даже в отсутствие операций с float/double.

Для метода 2 есть недостаток - не поддерживается FPU в прерываниях/исключениях. В связи с этим для гарантии код операционной системы следует компилировать с оцпией -mfloat-abi=soft. А приложение и математические библиотеки с опцией softfp. Иначе оно не будет линковаться. На ассемблер разумеется никаких ограничений.

Еще немного потестирую и буду прикручивать к официальной версии 2.6. Кстати, там видно что пооптимизировать, предложу модификации.

Update: еще покрутил ассемблерный листинг - для метода 2 времянки еще улучшились немного. На крайней правой нижней картинке теперь общее время 3.73мкс. Можно еще уменьшить за счет удаления всяких проверок (типа не пришло ли исключение из режима обработчика), но это уже может сказаться на надежности.

Update 2: у меня тут префетч из флеша в тесте выключался оказывается, почему то заметно влияло только на самую нижнуюю правую картинку - итого полное время 3,30 мкс для метода 2.

Update 3: тестирование прошло удачно, обновил картинку с цифрами. Префетч включен
Нажмите для просмотра прикрепленного файла

Очень интересно. Только я не понял, как читать осциллограммы
Сначала думал, что жёлтый луч - это одна задача, синий - вторая, а промежуток между ними - переключение контекста. Но потом засомневался - что-то уж очень маленькое время переключения контекста получается.
Что касаемо того, что gcc может использовать регистры FPU по своему желанию - это, по идее, достаточно легко обнаружить при отладке (и как-то изменить программу, чтоб это убрать).

Сейчас я убегаю, поэтому - по быстрому - фрагмент тестового кода:



Вечером продолжу тестирование и буду уже смотреть официальную ветку, там тоже есть что обсудить.
P.S. А префетч я отключал чтобы по-честному соревноваться с Вашими тестами scmRTOS - у Вас там ревизия проца старая
P.P.S. Картинки уже устарели - есть круче

Не могли ли бы вы поделиться проектом? У меня, к сожалению сделать это не получилось.
Программа постоянно прыгает по "OS timer tick" в tn_timer_task_func с периодической обработкой SysTick_Handler, но никак не переходит в функцию моей единственной задачи.
Буду благодарен любой помощи, мое первое знакомство с tn_kernel. Работаю все на той же stm32f4discovery под mdk-arm.

Порт "официальной" ветки и пример под stm32f4xx готовы, к сожалению, под IAR/GCC. Также внесена часть моих оптимизаций - которые вносятся без глубокого хирургического вмешательства. Осталось написать "сопроводиловку" и еще немного потестировать (там аж 8 вариантов компиляции нарисовалось) - и будет открыто.

TNKernel порт для Cortex-M4, написанный VslavX, выложен на сайте www.tnkernel.com.

Просьба со всеми вопросами обращаться непосредственно к автору ( VslavX )

VslavX, а почему в Вашем порте пропала необходимость в функции tn_int_exit() (заменена пустым макросом)?
Как оно теперь работает?

Здравствуйте!
Из документации непонятно, можно ли при добавлении TNKernel в свой проект добавить tn_arm_disable_interrupts() и tn_arm_enable_interrupts() в уже имеющийся startup_stm32f4xx.s и вызывать tn_tick_int_processing() из обработчика SysTick_Handler() в stm32f4xx_it.c или обязательно заменить его на startup_hardware_init.s из комплекта TNKernel как в примере. Получается очень много исправлений по сравнению с тем что приходится делать например для FreeRTOS (только дописать __weak__ к обработчику SysTick), это нормально или делаю лишнее по незнанию (начал работать с ARM недавно, использовал шаблоны из CMSIS/SPL и FreeRTOS)?

Доброго времени суток)
Безуспешно пытаюсь запустить TNKernel на STM32F401VC из Keil.
Порт для Cortex-M4 конфликтует с CMSIS core:

А порт для Cortex-M3 (как я понял из топика вполне работоспособен на Cortex-M4 ) падает в hardfault-handler:

Поделитесь пожалуйста простейшим проектом под Keil)

Продолжаю мудохаться.
Запустил порт для CortexM4 так, чтобы компилятор не ругался. Проект в прикрепленном файле.
Одна задача, которая зажигает светодиод. Падает в hardFault. Прошелся дебагером - проблемное место - функция tn_start_exe() ( достигается конец функции: строчка

А какой у Вас PendSV_Handler() работает? Судя по всему из файла startup_stm32f401xx.s, а должен бы из tn_port_cm4f_asm.s. Ну и для нормальной работы TN нужен системный таймер, функция tn_tick_int_processing() должна периодически вызываться из прерывания системного таймера.

Пробую запустить порт CortexM4F в своем проекте.
При TN_SUPPORT_FPU = 0 и TN_SUPPORT_FPU = 1 работает без проблем.
А при TN_SUPPORT_FPU = 2 падает в HardFault при первой же встреченной команде работы с FPU.
Компилятор IAR 7202. В чем может бть проблема?

Кто нибудь добился успеха с TN_SUPPORT_FPU?
Прграмма с TN_SUPPORT_FPU > 0 ведёт себя как ревнивая женщина (LPC4088).
Неужели нет альтернативы FreeRTOS?

scmRTOS?

Да, мне нравится она!
Использую в старых проектах.
Перешёл на TNKernel в частности из-за tn_net.

упс... минимальный стек больше при FPU.
Заработало но результат как и у kosyak©:
При TN_SUPPORT_FPU = 0 и TN_SUPPORT_FPU = 1 работает без проблем.
А вот при TN_SUPPORT_FPU = 2 падает в HardFault на инструкции VMOV S0,R0.
R0 = 0x320. Уже день пробился безрезультатно.
Меня собственно устраивает TN_SUPPORT_FPU = 1

Не подскажет ли кто как в EWARM заставть компилятор для определённой
функции не делать код для FPU (#pragma например)?

Попробуйте так.
Выносите функцию в отдельный файл, включаете файл в проект, в опциях указываете компилятору ключ командной строки --core=Cortex-M4