[blackyblack 0]

Подскажите, как правильно портировать на IAR 5.30? Апноту 1250 читал, софта внутри не нашёл, а скачать не дают.

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

Хочется посмотреть на нормальные файлы или хотя бы узнать, как проверить правильность работы.

[Andy_Mozzhevilov 0]

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

 

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

    PUBLIC  OS_CPU_ARM_ExceptIrqHndlr
    PUBLIC  IRQ_Handler

...

OS_CPU_ARM_ExceptIrqHndlr
IRQ_Handler
    SUB     LR, LR, #4                                         ; LR offset to return from this exception: -4.
    STMFD   SP!, {R0-R3}                                       ; Push working registers.

то есть объявить альтернативные имена меток, совпадающие с зарезервированными именами функций прерывания в IAR 5.xx.

Больше в asm делать ничего не нужно.

Дальше делаете icf файл - но это как везде, никакой специфики относительно UCOS.

[blackyblack 0]

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

	PUBLIC  OS_CPU_ARM_ExceptIrqHndlr

PUBLIC IRQ_Handler

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

[Andy_Mozzhevilov 0]

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

Нужно что?

[andrewlekar 0]

Нужно что?

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

 

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

[Andy_Mozzhevilov 0]

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

А я не заморачиваюсь с остальными, у меня в ось идет только IRQ.

FIQ обрабатываю вне оси (если оно мне нужно). А на оставшиеся вектора ставлю заглушки

while (1);

Если перенаправить в ось, то при отладке только мешает.

 

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

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

[andrewlekar 0]

А я не заморачиваюсь с остальными, у меня в ось идет только IRQ.

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

 

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

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

[Andy_Mozzhevilov 0]

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

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

[andrewlekar 0]

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

 

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

[Andy_Mozzhevilov 0]

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

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

[zltigo 0]

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

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

[Andy_Mozzhevilov 0]

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

Вполне нормальная практика - выполнение планировщика с возможным переключением контекста после выхода из прерывания.

Причина тоже понятна - скорость реакции задачи на асинхронное событие.

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

Не думаю, что в любимой вами FreeRtos задачи переключаются по тикам. Должно перепланироваться после выхода из прерывания.

[zltigo 0]

Вполне нормальная практика - выполнение планировщика с возможным переключением контекста после выхода из прерывания.

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

Причина тоже понятна - скорость реакции задачи на асинхронное событие.

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

Если контекст переключать только по тикам таймера, это уже не то.

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

Скорость реакции будет зависеть от периода таймера и его джиттера относительно асинхронного события.

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

Должно перепланироваться после выхода из прерывания.

По контексту, полагаю, что Вы имеете ввиду переключение, а не перепланирование, против которого (правда не после, а в обработчике прерывания) я не имею ну совсем ничего против :)

Это просто лозунг, причем тупо реализованный с целью дабы ламеры не думая получили некий результат. При этом о цене заплаченной за "результат", умалчивается.

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

[HARMHARM 0]

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

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

Не думаю, что в любимой вами FreeRtos задачи переключаются по тикам. Должно перепланироваться после выхода из прерывания.

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

[solosh 0]

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

 

И в scmRTOS тоже так сделано.

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