scmRTOS для начинающего., Очередное начало очередного начинающего :( Опции

[Beginning]

Я конечно вижу (и понимаю) что подобных тем создано много, ну хотя бы несколько. Но почитав их, увидел, что они мне не подходят, точнее не дают ответы на необходимые мне вопросы. А вопросов будет походу много. Поэтому решил создать новую тему в немного другом стиле – т.е. с моими промежуточными выводами, дабы на примере эволюции чайника помочь новым юзерам.
Ось решил прикрутить к уже готовому проекту – железо(на ATmega32) + дрова периферии (написано на С). Что бы грамотно прикрутить ось нужно понять как она работает. В общем как работает ось, я в принципе представляю, по крайней мере, в общих чертах. Как то даже написал свой вытесняющий планировщик для ARM (Работает до сих пор . Ну да ладно. Почитал доку по оси v.2 почитал форумы. В голове образовалась определённый набор знаний в виде каши, ну или первичного супа, типа из которого на планете жизнь зарождалась Понял, что пора внедрять знания. Вставил иссодники оси в мой проект. Расставил их соответственно папковой иерархии проекта. Долго бился над путями. Потом плюнул и прикрутил исходники к проекту 1-EventFlag. Ну вроде нормально. Компилиться без ошибок.
Теперь пару тезисов которые я для себя определил, как некие точки от которых можно оттолкнуться.
1.Поток (кусок кода в while(1){}) будет выполняться пока
a) надо вызвать паузу (за это отвечает функция, как я понял, Sleep)
б)не произойдёт прерывание переферии, внутри которого произойдёт переключения контекста. Для этого мы в обработчики прерывания вставляем объект класса TISR_Wrapper. Вставляем этот объект, например, в прерывание UART recive.
в) Прерывание системного таймера. Таймер настроенный на срабатывание через определённый промежуток времени для проверки надо ли переключать контекст.
2. Шедулер или планировщик. Кусок кода который контролирует паузы для потоков – т.е. инкрементирует их если надо, смотрит какие флаги взвелись для ожидающих их потоков и т.д. ну и соответственно переключает потоки. Примерно так.

Вроде определились с необходимыми вещами. Приступаем.
Нам нужен системный таймер. На его роль определили Timer0. В общем проинитил его. Включил прерывание на переполнение. Время срабатывания решил поставить 1мс. И для этого в теле прерывания надо таймер инитить TCNT0 = 0x8D, это при кварце 7.3728. Порыл код и догадалcя что вроде для этого есть функция void OS::SystemTimerUserHook(), короче туда и вставил. Правильно сделал?
C таймером разобрались. Теперь эпопея номер два – програмное прерывание. Почитал за него. Блин, сложно въехать в сакраментальный смысл его использования, ну это и понятно надо сначала поюзать ось и столкнувшись с проблемами всё станет на свои полочки. Но как я уже говорил железо уже определено и костыль в виде соединения пинов мне не подходит. Отсюда мой первый вопрос. Как выпутаться из этой проблемы? Конечно, хотеться всё же использовать именно прерывание, т.к. использования прямого вызова шедулера очень не кашерно, как я прочитал в документации. Желательно не просто сказать – бери гэто, а привести пример кода, именно в контексте оси.
Спасибо.

[Сергей Борщ]

В реальном железе не отлаживал, т.к. из средств отладки в реальном железе есть только uart_puts.

Еще можно ногами помахать. Этого достататочно в очень большом количестве случаев.

Интересный эффект – когда убираешь оптимизацию в IAR вылетают море предупреждений типа:
Too low level of optimization to inline function "OS::TKernel::RegisterProcess" и т.д.

Все правильно. А зачем убирать оптимизацию? Это ведь все равно, что искать ошибки в совершенно другой программе.

И при этом программа постоянно сбрасывается, т.е. стартует работает, потом опять стартует. Это в протеусе.

Разберетесь - почему, глубже поймете, как именно работает ОС. Эти знания помогут в дальнейшем ее использовать. Только отлаживайтесь с оптимизацией. Без оптимизации возможны чудеса именно из-за невстраивания функций.

P.S. Насчёт протеуса, пока что не замечал от него явных глюков. Во всех случаях, когда я был уверен, что глючит протеус, оказывалось что глючу я

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