Подскажите, как правильно портировать на IAR 5.30? Апноту 1250 читал, софта внутри не нашёл, а скачать не дают.
В общем, есть версия для at91sam9260 для IAR 4.30, но там формат линкерных файлов другой и стартапы отличаются - я их перелопатил в интуитивной манере и даже запустил (пишет в терминале что работает на 1000 тиков и больше ничего не делает), но неизвестно, всё ли правильно.
Хочется посмотреть на нормальные файлы или хотя бы узнать, как проверить правильность работы.

С 4.30 на 5.хх переводится по EWARM_MigrationGuide.pdf

В os_cpu_a.asm нужно сделать что-то наподобие:

то есть объявить альтернативные имена меток, совпадающие с зарезервированными именами функций прерывания в IAR 5.xx.
Больше в asm делать ничего не нужно.
Дальше делаете icf файл - но это как везде, никакой специфики относительно UCOS.

Ну я в стартапе указал вместо обычных хэндлеров OS_CPU_ARM_xxx. Но в целом непонятно, зачем оно нужно...

Нужно что?

Зачем оси нужно знать про эти прерывания. Ладно, для IRQ и FIQ ещё есть смысл, а вот в чём смысл остальных векторов неясно.

Ещё такой вопрос: если бутлоадер установил вектора прерываний и настроил стеки, а потом загрузил основной код с адреса 0x20000000, в котором мы и хотим использовать ось, то будут ли обновлены вектора прерываний по данным из основного кода или останутся нетронутыми?

А я не заморачиваюсь с остальными, у меня в ось идет только IRQ.
FIQ обрабатываю вне оси (если оно мне нужно). А на оставшиеся вектора ставлю заглушки
while (1);
Если перенаправить в ось, то при отладке только мешает.


На этот вопрос не отвечу. Нужно смотреть документацию, как вектора ремапятся. С Атмелом не работал, у NXP младшие на 64 байта flash мапятся 64 байта из ОЗУ с адреса 0x4000 0000

Спасибо. Хоть что-то начинает проясняться, а то с этими многоуровневыми прерываниями и ремапами чёрт ногу сломит.

У меня по всей видимости, вектор прерываний вообще инициализируется бутлоадером и сама софтина его не трогает. В том числе и IRQ инициализируется таким образом, что всё идёт в AIC. И, как ни странно, в моём порту под SAM9260 тоже IRQ идёт в AIC и в ось не попадает. Собственно, благодаря этому, всё сразу заработало.
Вопрос теперь такой: какие преимущества/недостатки того, что прерывания обрабатываются нативно, через AIC, а не через ось? Судя по всему, если контроллер прерываний проца позволяет (есть приоритеты, многоуровневость), то и фиг с ней, с осью.

Прерывания должны сначала попадать в ось на OS_CPU_ARM_ExceptIrqHndlr, а потом уже в OS_CPU_ExceptHndlr, в которой уже идти по векторам из AIC.
Если вы сразу идете по вектору, минуя ось, то при вызове сервисов оси из прерываний у вас ось не будет об этом знать, что чревато переключением контекста из прерывания, с последующими глюками вплоть до выпадения в exception.

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

PS: View заработал. Только почему-то View 310G знает только о ком-портах 1 и 2. Как-то хиловато.

Как это не будете трогать сервисы оси из прерываний? А как же вы будете события задачам передавать?

В более-менее нормальных системах только сервисы собственно переключающие контекст из прерывания требуют системных оберток. Та-же передача сообщений из прерывания в большинстве случаев может только перепланировать шедулер, а переключение произойдет в плановом порядке по очередному тику или вызову шедулера. Лично я практически никогда не пользуюсь переключением контекста из прерываний, впрочем как и uC/OS и соответственно давно забыл ее нюансы.

Вполне нормальная практика - выполнение планировщика с возможным переключением контекста после выхода из прерывания.
Причина тоже понятна - скорость реакции задачи на асинхронное событие.
Если контекст переключать только по тикам таймера, это уже не то. Скорость реакции будет зависеть от периода таймера и его джиттера относительно асинхронного события.
Не думаю, что в любимой вами FreeRtos задачи переключаются по тикам. Должно перепланироваться после выхода из прерывания.

Только в реале нужная на самом деле редко, если подумать.

Если она нужна . При этом на самом деле для достижению рекордных скоростей вся эта возня с бездумным сохранением контекста тормозит изрядно, и если уж нужно действительно скорость реакции, то нужно или без системы или с системными заплатками.

По тикам, или после ухода текущей задачи в сон или ожидание

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

По контексту, полагаю, что Вы имеете ввиду переключение, а не перепланирование, против которого (правда не после, а в обработчике прерывания) я не имею ну совсем ничего против
Это просто лозунг, причем тупо реализованный с целью дабы ламеры не думая получили некий результат. При этом о цене заплаченной за "результат", умалчивается.
А цена эта немалая, ну например типичный, как минимум для меня, случай - по прерываниям собирается какой-то фрейм, ну например, сотни байт размером. Складывается в буфер. По получению полного фрейма посылается сообщение задаче, что в буфере лежит фрейм. Если делать тупо с сохранением контекста, то будут сотни лишних сохранений/восстановлений контекста на одну посылку сообщения. И это при этом сам обработчик может быть действительно быстрым буквально десяток команд и железо обслужено. Без сохранения - да, при посылке сообщения мы будем вынуждены дождаться тика или добровольной передачи управления. При этом на самом деле можем попасть и на IDLE, тогда вписав в idle() несколько строк можем уже и переключить задачу сразу. Для более жесткого переключения вполне хорошим приемом является и вызов-эмуляция некого прерывания, на котором висит обертка и переключение контекста, из обработчика прерывания без обертки. Я так несколько раз делал для FIQ.

То, на что нужна уж такая скорость реакции, можно сделать через FIQ...

Могут и так, и так.

И в scmRTOS тоже так сделано.
А обработчик прервания на входе сохраняет только те регистры, которыми будет пользоваться, а не весь контекст.

Под скоростью реакции я имел ввиду переход событие-задача. Фактически вызов системного сервиса (семафора, mbox, que) из прерывания и получение этого события в задаче.


Мне не нужно это объяснять, я знаю, как это работает и из чего накладные расходы состоят.
Все это решается в том числе организационно, назначением приоритетов задачам. Точно также, как и любой вытесняющей многозадачке.


Кто знает - тот знает.
Цена здесь, некий набор действий, выполненый портом ОС до передачи управления на вектор. Да, там есть некоторые накладные расходы.
Кстати в какой-то степени они зависят от архитектуры процессора. В АРМ приходится перекидывать контекст между стеками, что есть накладные расходы. Когда я делал порт для Fujitsu с его 32-банками регистров, то накладные расходы по переключению контекста были минимальны.


Если необходимо действительно быстрое прерывание, то я его тоже делаю на FIQ, поскольку у меня оно не идет через осевую обертку.
Кроме этого, FIQ прерывает IRQ, что позволяет сделать вход в обработчик с мимимальными задержками и джиттером (если это прерывание периодическое). В этом случае из FIQ, действительно только 1 раз из многих, возникает необходимость вызова сервиса ОС. Для этого в NXP я использовал Software Interrupt в VIC, которое уже идет через IRQ и соответственно может использовать сервисы ОС.
Но это действительно нужно только в некоторых случаях. Во многих случаях это скорость ради скорости.
Напротив, я могу привести ряд примеров, когда мне требовалось поднимать задачу периодически и достаточно часто (раз в 500 мкс, причем на Fujitsu, который ~5 раз медленне NXP на 60МГц при выполнении кода ОС). При этом делать таймер ОС с таким периодом совершенно нецелесообразно.

PS: Спорить о том, какой подход лучше, я не хочу. Понимая, как они оба работают, вижу и достоинства и недостатки и того и другого.
Автором топика был задан конкретный вопрос, и касательно uCOS. Я на него ответил. Да, если использовать тот порт, который они предлагают, то нужно перенаправлять вектор сначала на осевой обработчик. Если этого не сделать, то в прерываниях нельзя будет пользоваться сервисами ОС. Тогда (для uCOS) прерывания получатся оторванными от оси и передача событий из прерываний в задачи значительно усложняется, фактически сводясь в опросу флагов (как в системе foreground-background). Причем делать этого я смысла в большинстве случаев не вижу. Получается, что это скорость ради скорости.
Второй вариант - переписать порт uCOS. Можно сделать порт так, чтобы обработчик прерываний мог вызываться без пролога оси.
В общем я для Fujitsu именно так и делал. Если в пользовательском прерывании хотелось вызвать сервис ОС, то нужно было сначала вызвать функцию информирования ОСи о том, что вызовы идут из прерываний. В результате можно было некоторые прерывания обрабатывать, не пользуя сервисы ОС, и как следствие - по выходу не производя попыток переключения контекста.

Никакой не лучше - лучше иметь обе реализации. Если выбирать один вариант, тогда все прерывания в обертки. Это тупо будет работать, даже если пользователь не ведает, что делает и как оно работает.

Ну есть еще абстрактное понятие красоты

Посмею предположить, что и задачу часто регулярно поднимаемую делать было не очень-то целесообразно красиво . Хотя умом понимаю, что ресурсов все больше и больше и пусть себе работает, как может.

Та задача своими вычислениями занимала ~200 мкс из 500, а в некоторой ветви, которая выполнялась раз в несколько сотен итерраций - до 800 мкс (при этом джиттер, который она вызывала не имел значения).
То есть делать ее в прерывании - блокировать систему на недопустимое время.
Разделить алгоритм на 2 части - быструю для IRQ и медленную для задачи было не тривиально, явное усложнение системы. Да и смысла я в этом не увидел. Ну ест задача 40% процессорного времени, остальные - еще 30%. Еще резерв оставался.
Но это уже я совсем отошел от топика.