Jump to content

    
Sign in to follow this  
blackyblack

IAR 5.30 ARM

Recommended Posts

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

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

 

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

Мне не нужно это объяснять, я знаю, как это работает и из чего накладные расходы состоят.

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

 

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

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

Кто знает - тот знает.

Цена здесь, некий набор действий, выполненый портом ОС до передачи управления на вектор. Да, там есть некоторые накладные расходы.

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

 

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

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

Кроме этого, FIQ прерывает IRQ, что позволяет сделать вход в обработчик с мимимальными задержками и джиттером (если это прерывание периодическое). В этом случае из FIQ, действительно только 1 раз из многих, возникает необходимость вызова сервиса ОС. Для этого в NXP я использовал Software Interrupt в VIC, которое уже идет через IRQ и соответственно может использовать сервисы ОС.

Но это действительно нужно только в некоторых случаях. Во многих случаях это скорость ради скорости.

Напротив, я могу привести ряд примеров, когда мне требовалось поднимать задачу периодически и достаточно часто (раз в 500 мкс, причем на Fujitsu, который ~5 раз медленне NXP на 60МГц при выполнении кода ОС). При этом делать таймер ОС с таким периодом совершенно нецелесообразно.

 

PS: Спорить о том, какой подход лучше, я не хочу. Понимая, как они оба работают, вижу и достоинства и недостатки и того и другого.

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

Второй вариант - переписать порт uCOS. Можно сделать порт так, чтобы обработчик прерываний мог вызываться без пролога оси.

В общем я для Fujitsu именно так и делал. Если в пользовательском прерывании хотелось вызвать сервис ОС, то нужно было сначала вызвать функцию информирования ОСи о том, что вызовы идут из прерываний. В результате можно было некоторые прерывания обрабатывать, не пользуя сервисы ОС, и как следствие - по выходу не производя попыток переключения контекста.

Share this post


Link to post
Share on other sites
Спорить о том, какой подход лучше, я не хочу.

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

Получается, что это скорость ради скорости.

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

мне требовалось поднимать задачу периодически и достаточно часто (раз в 500 мкс, причем на Fujitsu, который ~5 раз медленне NXP на 60МГц при выполнении кода ОС). При этом делать таймер ОС с таким периодом совершенно нецелесообразно.

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

Share this post


Link to post
Share on other sites
Посмею предположить, что и задачу часто регулярно поднимаемую делать было не очень-то целесообразно красиво :(. Хотя умом понимаю, что ресурсов все больше и больше и пусть себе работает, как может.

Та задача своими вычислениями занимала ~200 мкс из 500, а в некоторой ветви, которая выполнялась раз в несколько сотен итерраций - до 800 мкс (при этом джиттер, который она вызывала не имел значения).

То есть делать ее в прерывании - блокировать систему на недопустимое время.

Разделить алгоритм на 2 части - быструю для IRQ и медленную для задачи было не тривиально, явное усложнение системы. Да и смысла я в этом не увидел. Ну ест задача 40% процессорного времени, остальные - еще 30%. Еще резерв оставался.

Но это уже я совсем отошел от топика.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this