[ILYAUL 0]

что, как других дилетантами обзывать так запросто, а как вас, так и обиделись? :)

Примеры, да пожалуста:

1. Принимаем команды по наложению OSD, шина RS485 абонентов много, при получении команды не позже чем через нцать мкс (точное число ен помню больше 100 но меньше 500) следует отправить подтверждение приема. Других задач не выполняем. Формирование картинки работает не быстро - суперлуп длинный. Ну и? ради великой самоцели "малосидения в прерывании" делать еще и планировщик с тиком 100мкс?

2. Резервное устройство на батарейном питании, по команде дергаем клапан. Тут ключевой момент даже не время реакции, а потребление, проц работает ТОЛЬКО в прерывании, остальное время дрыхнет, вынос обработки в суперлуп увеличит потребление на величину отличную от нуля.

Реальные примеры из практики, а не тупые суперлупы в вакууме.

 

PS продолжим холивар или дадим ТСу решать свою задачу?

 

1. Такое впечатление , что Вы планировщик сидя в прерывании не делали и отсылали подтверждение наобум лазаря.

2. Такие устройства по другому и не имеет смысла делать. Но , если в них и исполняется только одна команда.

P.S Он уже решил.

[Flexz 0]

Как хотите)

1. У ТС проблемы с временем выполнения, я предложил один из вариантов ускорения, просто как вариант.

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

2. Этот пункт касается моего второго примера? Если да, то, на первый взгляд, это эквивалентно. А посему включается религия, не позволяет вам сидеть в прерывании - делайте в суперлупе, мне позволяет.

 

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

 

Вообще, чего я все на ваши вопросы отвечаю? Давайте вы теперь, расскажите, чем же так плохо задерживаться в прерывании, если никто не торопит с выходом из него?

[demiurg_spb 0]

В итоге SRAM - 2 байта (один маркер, другой счетчик символов при сохранении данных), и скорость максимальная. =)

Позволю себе усомниться в последнем утверждении. А флеша скоклько? А какие нехилые прологи и эпилоги у ISR и-за наличия вызова процедур.

 

чем же так плохо задерживаться в прерывании, если никто не торопит с выходом из него?

Вот этого "если" по жизни то и не бывает. При запросе других прерываний будет лишняя задержка.

Не мне говорить вам чем это может обернуться.

 

Мне сложно да собственно не нужно вас переубеждать в чём-то.

Отвечу вам просто: есть системный подход и есть остальное. Всё. Я сказал и больше добавить не чего.

[Flexz 0]

1. Такое впечатление , что Вы планировщик сидя в прерывании не делали и отсылали подтверждение наобум лазаря.

О каком планировщике речь? Я об ОСовом, который перервал бы тежелую обработку ОСД и отправил бы ответ, вы о нем же? зачем он? В перывании выставлялась задача для следующего цикла суперлупа и отправлялся ответ. Эквивалентно? Да! Так зачем планировщик? Ради религиозной цели несидения в перывании. Не плодите сущностей.

 

Вот этого "если" по жизни то и не бывает. При запросе других прерываний будет лишняя задержка.

Я совершенно конкретные примеры привел, где бывает.

 

Продолжать похоже бессмысленно, если вы настаиваете на своих принципах, то с ними вас и оставлю.

Изменено 11 ноября, 2011 пользователем Flexz

[demiurg_spb 0]

Пис, братья!:)

[Alt.F4 0]

Позволю себе усомниться в последнем утверждении. А флеша скоклько?

Специально для Вас посчитать? На вскидку до 500 байт флэша. По сути дела, написанный процесс флэш-памяти больше занимать не стал.

А какие нехилые прологи и эпилоги у ISR и-за наличия вызова процедур.

Просто огромные, загрузили в Z адрес подпрограммы и пошли ее выполнять. :)

Изменено 11 ноября, 2011 пользователем Alt.F4

[ILYAUL 0]

зачем он?.....

не позже чем через нцать мкс (точное число ен помню больше 100 но меньше 500) следует отправить подтверждение приема.

Я об этом . Вам надо просидеть в прерывании 100 мкс ( судя из Вашей фразы) что бы отправить ответ

[xemul 0]

Обрабатываю NMEA.

Кольцевые буферы действительно не нужны.

Заведите два буфера - в один принимаете, другой обрабатываете, - и два указателя - на приём и обработку. По <CR> в прерывании меняете указатели местами и взводите флаг приёма строки. Вместо <CR> в буфер пишете 0x00, <LF> пропускаете.

Но, имхо, за 1с - 150*10/115200 = 987 мс можно не напрягаясь разобрать принятую строку и обойтись одним буфером.

 

ЗЫЖ а какое сообщение NMEA весит 150 байт?

[Alt.F4 0]

xemul, спасибо, я уже решил задачу. Из всех NMEA обрабатываю 3 строки.

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

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

Грамотно. По сути у вас получился конечный автомат.

 

[demiurg_spb 0]

Специально для Вас посчитать?

Нет не стоит.

На вскидку до 500 байт флэша. По сути дела, написанный процесс флэш-памяти больше занимать не стал.

Просто огромные, загрузили в Z адрес подпрограммы и пошли ее выполнять. :)

А перед этим все регистры на стек а после обратно.

[ILYAUL 0]

А перед этим все регистры на стек а после обратно.

 

Врядли , если asm то только те ,что будут меняться

[demiurg_spb 0]

Я об этом . Вам надо просидеть в прерывании 100 мкс ( судя из Вашей фразы) что бы отправить ответ

Вы не так поняли его. сидеть не надо. надо ответить не позднее чем 100..500 мкс и всё.

 

Врядли , если asm то только те ,что будут меняться

Процедуры вызываются косвенно и не известно что каждой из них потребуется.

[ILYAUL 0]

Вы не так поняли его. сидеть не надо. надо ответить не позднее чем 100..500 мкс и всё.

 

Он же получает команду - т.е. уже влетел в прерывание, что-то там анализирует , ждёт 100-500 , отсылает ответ - выходит из прерывания. Судя по тому принципу который он отстаивает - в прерывании можно сидеть пока всё не сделаешь , а вот если выйти и ждать вне прерываниии - это уже другой принцип обработки. Вот он всё написал

Принимаем команды по наложению OSD, шина RS485 абонентов много, при получении команды не позже чем через нцать мкс (точное число ен помню больше 100 но меньше 500) следует отправить подтверждение приема. Других задач не выполняем. Формирование картинки работает не быстро - суперлуп длинный. Ну и? ради великой самоцели "малосидения в прерывании" делать еще и планировщик с тиком 100мкс?

Раз других задач не выполняем - значит торчим в прерывании

 

Процедуры вызываются косвенно и не известно что каждой из них потребуется.

Это сама процедура вызывается косвенно ( по Z) . А вот , что в этой процедуре потребуется сохранить , а на что наплевать - решает тот кто пишет процедуру/ А перед входом в процедуру можно сохранить счётчик комманд ,а при выходе вернутся на +1 адрес с которого ушли. Т.е. по принципу многозадачности.

[Flexz 0]

ILYAUL

Пятница, вечер, кому-то пора отдыхать. И не читайте между строк, там ничего нет.

Ясно написано, отправить ответ нужно "не позже", насчет "не раньше" и "сидим в прерывании" это вы сами придумали.