IAR 5.30 ARM Опции

[Andrew Lekar]

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

[andrewlekar]

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

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

[Andy Mozzhevilov]

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

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

[zltigo]

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

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

[Andy Mozzhevilov]

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

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

[zltigo]

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

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

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

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

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

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

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

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

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

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

[solosh]

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

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