Эта версия посвящена ,в основном, устранению накопившихся багов.

Огромное спасибо всем участникам проекта TNKernel !!!

благодарю, но хочу высказать свои хотелки, в целях повышения юзабельности

1. добавить контроль стека в tn_port_cm3_iar.s. Хотя бы закоменченным блоком. Кому надо разкоментят на этапе отладки.
2. вынести TN_CHECK_PARAM, TN_MEAS_PERFORMANCE, USE_MUTEXES, USE_EVENTS из tn.h в tn_config.h. Как это реализовано в прочих ОС
3. добавить mailbox. Повышает функциональность за счет увеличенного трансфера данных между задачами
4. сделать TN_FILL_STACK_VAL оффициальным 0xDEADBEEF
5. в tn_event_wait сделать p_flags_pattern необязательным
6. в TN_TCB опциональные поля под дефайнами USE_MUTEXES и USE_EVENTS перенести в хвост структуры. Это для унификации пункта 1 и будущих асмовских проверок

P.S. это я всё у себя реализовал. И понимаю что TNKernel is free и каждый творит что хочет.
Но если посчитаете перечисленные хотелки приемлимыми и адекватными, то не плохо чтобы это все появилось в оффициальной версии

Спасибо!

немножко дополнений...

небольшие рекомендации от меня:
не использовать printf и прочие тяжелые функции в tn_app_init, так как исполнение этой функции выполняется в контексе сервисной задачи tn_timer_task, у которой стек не большой и по дефолту 64 слова.
В результате выхода за пределы стека, портится список tn_ready_list (который как раз находится перед tn_timer_task_stack )
в итоге, получаете удивительные но нерадостные сюрпризы от операционки.

a вce-тaки пoлeзнaя фичa peaлизoвaнa idle_user_cb вepcии 2.5 для PIC24.
Может сделать стандартым для всех портов ?

9. в фyнкциях tn_event_clear и tn_task_create проверка параметров без условной компиляции
10. при компиляции без TN_CHECK_PARAM поля id_task, id_mutex и прочие id излишны, и только зря "поедают" RAM
11. не плохо бы разместить поля id_task, id_mutex и прочие в режиме TN_CHECK_PARAM разместить в начале структур, чтобы проще выявлять виновников портящих память

Добрый день!
Сразу же прошу прощения если мой ламерский вопрос не в тему.
Встала задача запустить TNKernel на STM32F401VC.
Порядок действий:
Скачал порт для Cortex M4 на офф сайте: http://www.tnkernel.com/tn_port_CortexM4.html
Из скачанного архива перенес папку "TNKernel" в свой проект. Добавил в проект все исходники, прописал пути к заголовочным файлам, выставил необходимые макроопределения.
Теперь пытаюсь написать простейшую программу:


И тут я получаю сообщения об ошибках:

Функции __get_PRIMASK() и __set_PRIMASK() в файле "tn_port_cmf4.h" совпадают с одноименными функциями из файла "core_cmFunc.h".
Как быть?

Кстати, а есть сравнение TNkernel с Coocox?

Всем привет.

Сразу перейду к делу, после чего изложу лирику, если она кому-то интересна. Итак: в TNKernel все еще есть достаточно неприятные баги, и в течении последнего месяца я интенсивно переписываю TNKernel, исправляя найденные ошибки. Ошибки обнаруживаются с помощью подробных unit-тестов (которые я тоже аккуратно пишу), благодаря чему стабильность системы реально повышается, а вероятность добавления впоследствии новых ошибок снижается. Судя по найденным багам, оригинальная TNKernel тестировалась только "вручную", без формализованных тестов, что печально.

Текущий список найденных и исправленных багов:

* если в tn_sys_tclice_ticks() переданы неверные параметры, то возвращается TERR_WRONG_PARAM и прерывания остаются запрещенными
* есть три задачи: две низкоприоритетные с одинаковым приоритетом task_low1 и task_low2; и одна высокоприоритетная task_high. Теперь: task_low1 блокирует мютекс М1 (с алгоритмом повышения наследования приоритета), потом task_low2 пытается тоже его заблокировать и уходит в ожидание, потом task_high тоже пытается его заблокировать и тоже уходит в ожидание -> приоритет task_low1 повышается до приоритета task_high. Теперь task_low1 разблокирует мютекс, следующая задача в очереди - task_low2, она его блокирует, и ее приоритет должен быть повышен до приоритета task_high (т.к. она все еще его ждет), но этого не происходит: высокоприоритетная task_high продолжает ждать задачу task_low2, приоритет которой низкий.
* низкоприоритетная задача task_low блокирует мютекс М1 (с алгоритмом повышения наследования приоритета), высокоприоритетная задача task_high тоже пытается его заблокировать и уходит в ожидание -> приоритет task_low повышается до приоритета task_high; теперь task_high выходит из ожидания по таймауту -> приоритет task_low остается повышенным. То же самое происходит, если task_high была остановлена с помощью tn_task_terminate.
* tn_mutex_delete() - если мютекс не заблокирован, то возвращается TERR_ILUSE. То есть, чтобы удалить мютекс, нужно сначала его заблокировать. Это неправильно.

Проект размещен на bitbucket: ссылка.

Как получилось, что я вообще занялся этим: сначала я долгое время пользовался портом Alex.B для PIC32, не особо вникая в то, как работает это ядро; потом в какой-то момент меня очень расстроил тот факт, что в нормальном режиме работы контекст может быть сохранен в стек задачи два и более раз. Плюс к этому, мне уже давно надоели проблемы, связанные с тем, что для прерываний используется стек задачи, которую оно прервало (вместо отдельного стека для прерываний) - на это тратится куча RAM, которой и так вечно не хватает, и я начал искать другой порт. Нашел: это порт от Anders Montonen, в котором для прерываний используется отдельный стек, поддерживаются вложенные прерывания и shadow register set.

Но в этом порте отсутствовали некоторые вкусности, которые есть в порте Alex.B: как минимум, там не было удобных Сишных макросов для определения прерываний, и еще сам TNKernel должен быть собран в составе проекта, без возможности выделить его в отдельную либу. Таким образом, я решил допилить его для себя. Anders Montonen хочет оставить свой порт настолько близко к апстриму, насколько возможно, поэтому мне оставалось только форкнуть его.

Далее, чем больше я вникал в TNKernel, тем меньше мне нравился ее код. Подробно см. на страничке моего проекта Why refactor?, все переписывать сюда не буду, изложу кратко: очень много дублирования кода, нет централизованных методов чтобы делать многие вещи, таким образом, одно и то же реализовано в куче мест просто копи-пастом (именно это является причиной изложенных выше багов с мютексами). Почти в каждой функции есть много точек выхода, почти перед каждым оператором return - разрешение прерываний. Это нарушение очень хорошего правила: "одна точка входа - одна точка выхода". Если бы это правило соблюдалось, то ошибка в tn_sys_tclice_ticks() никогда не появилась бы.

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

В данный момент большинство кода уже переписано таким образом, чтобы код дублировался как можно меньше. Если есть два похожих сервиса (например, tn_fmem_release() и tn_fmem_irelease()), то основная работа производится в одном месте, а вышеуказанные сервисы являются только обертками, совершающими соответствующие вступительные и заключительные действия.

И так во всем остальном. Больше всего путаницы с мютексами и их алгоритмами управления приоритетами задач; tn_mutex.c и tn_tasks.c переписаны, наверное, процентов на 70%.

Насчет тестов: на данный момент написаны очень подробные тесты для мютексов, чуть менее подробные тесты для управления задачами. Остальное - в скором (надеюсь) будущем.

О некоторых проблемах (например, про баг в tn_sys_tclice_ticks и про путаницу с макросом MAKE_ALIG) я писал Юрию на почту, он ничего не ответил: видимо, потерял интерес.

Некоторые детали API были изменены, т.к. они мне не нравятся; конкретно об изменениях тут: Differences from original TNKernel. Скорее всего, впоследствии API будет еще изменяться (т.к. я еще не все поправил, что мне не нравится), но по возможности оставлю слой совместимости с оригинальным TNKernel.

Вообще, изменений уже очень много (например, нет timer task - подробнее об этом по ссылке выше, хотя на API это не влияет), и будет еще больше, так что совместимость с оригинальной TNKernel будет, конечно, не абсолютная. Чтобы не вводить в заблуждение, возможно, придется выбрать новое название. Возможно, это будет TNeoKernel - и безусловная причастность к TNKernel указана (Юрий, большое спасибо вам за этот проект), и добавлена частичка Neo, которая указывает на некую новизну =)

В настоящий момент существует только порт для PIC32; Не знаю, заинтересует ли кого-то этот мой проект, но на всякий случай я написал.

Спасибо за внимание.

Очень интересно, спасибо! А то сейчас на pic'ах грустно с качественными ОСРВ, а в своё время tn_kernel очень нравился
Хотелось бы узнать: есть ли возможность посмотреть проекты с unit-test'ами? Тесты очень часто помогают понять логику API больше, чем документация. Да и вообще интересно на какой платформе тестируется: x86, pic-mips или совместно?

Спасибо за интерес =)

Проект с юнит-тестами пока один, гоняю в железе на своем PIC32MX440F512H (камень, использующийся в текущем проекте на моей работе), вывожу лог в UART.

Конечно я покажу его, но сразу предупрежу: его код пока не такой вылизанный: к сожалению, мое open-source время ограничено и на все не хватает, но когда я смогу найти время и причесать его, то размещу ссылку на странице самого ядра.

Как в целом работают тесты: есть задача с самым высоким приоритетом (типа test_director), она создает себе рабочие задачи(A, B, C, ...), создает объекты (например, мютексы: M1, M2, ...), говорит задачам что делать, и проверяет, что после этого получилось.

Вкратце, код тестов выглядят примерно так:


Здесь мы сначала выводим в лог дословный коммент "A locks M1", потом отправляем команду задаче A, чтобы она заблокировала мютекс 1. После чего ждем некоторое время, и проверяем: владелез мютекса 1 должна быть задача А, кол-во блокировок должно быть 1, последнее возвращенное значение - TERR_NO_ERR. Ну и так далее, код тестов должен быть понятен без лишних комментариев (я надеюсь).

В лог при этом выводится следующее:



Если что-то пойдет не так, то будет не "as expected", а подробности, что именно ожидалось и что получилось, и тесты останавливаются.

Репозиторий можно получить так (будет скачан "environment" репозиторий с несколькими подрепами, одна из подреп - собственно, сам проект с тестами, остальные - либы, их немного) :

hg clone http://hg.dfrank.ru/rtos_check/_env rtos_check

Файл со всеми тестами мютексов: hg.dfrank.ru/rtos_check/project_common/files/tip/fw_tmp_bk16/appl/source/appl/appl_tntest/appl_tntest_mutex.c
Файл со всеми тестами задач (пока их немного) : hg.dfrank.ru/rtos_check/project_common/files/tip/fw_tmp_bk16/appl/source/appl/appl_tntest/appl_tntest_tasks.c

Лог всех тестов: http://vpaste.net/gsfGv

Вот таким образом. Уже много раз эти тесты сразу указывали мне, когда я где-то что-то ломал

прикрутил к TnKernel систему runtime контроля стеков задач, и текущего состояния задач. Кому интересно делюсь

пример


реализация

А порт для Cortex-M0(M0+) существует?

где-то на просторах электроникса лежит tn_port_cm0 ( но не нашел )
но вот давненько выкладывал готовый проект, можете оттуда выдрать

Спасибо, выдрал.