Добрый день.
Столкнулся с задачей, которую никак не могу решить.
Имеется кольцевой буфер UART на 150 байт. По приходу байта вызывается прерывание, где происходит его запись и сдвиг всего буфера. Но вот незадача, скорость UART 115200, а частота МК 9216кГц. В результате я имею запас всего 80 тактов, которых естественно не хватает на сдвиг этого буфера.
Что можно придумать?
Спасибо.

P.S. на данной скорости UART работает стороннее устройство и ее изменять нельзя. Частота МК почти максимальная, т.к. питание 3В.

Проц -то какой? И зачем сдвигать весь буффер?

Зачем сдвигать буфер? Не проще ли писать по следующему адресу и отслеживать указатель? Если написать обработчик на ассемблере, должно влезть.
Если, конечно, внешний UART с FIFO нельза поставить.

А зачем его сдвигать?
Есть такое понятие - голова (head) и хвост (tail ) буфера.
УАРТ пишет по указателю head. Чтец читает по указателю tail? инкрементируя его соотв. образом, догоняя head...

Естественно, не сдвигать. Два указателя, для принимаемого и извлекаемого байта.

Много не понятного , сразу все 150 принимаются и по одному возвращаются или принял передал . Если принял передал , зачем тогда такой буфер?

Здесь доходчиво написано:

http://chipenable.ru/index.php/programming...uart-queue.html

Дело в том, что мне надо вылавливать из этих 150байт только три первых символа, остальные данные переменны, и их пишу в СОЗУ и потом обрабатываю.
Таким образом кольцевой буфер с "head" и "tail" не подходит, т.к. надо чтобы в буфере было сразу 150байт.

Буду пытаться обрабатывать в прерывании по шагам всю строку.

Простите, а какая связь между 150 байт и реализацией буфера через "голову" и "хвост"? И почему двигать все 150 байт относительно границ буфера подходит, а двигать границы буфера относительно этих же 150 байт - нет?

Да хоть 100500 - суть не меняется.

Проще сначала подумать.
Нечто С-образное:

Хочется заметить, что на приём байта (а не бита!) у Вас аж 800 тактов.

Размер кольцевого буфера лучше иметь кратным степени 2...

Вы как-то определитесь и не скупитесь на слова при описании проблемы , излейте всё задание , легче станет

Данные в этих 150байтах лежат не в строгом порядке, в результате надо часто искать запятые, точки и другие символы. На флажках это дело решать муторно.
Я переделал по своему, вопрос исчерпан.
Спасибо.
Этого тоже не достаточно, ведь надо было прочитать, записать + счетчик перепроверить. В итоге: 150*7тактов=1050тактов.

У вас идеология неверная. Уарт заполняет фифо и только.
Фоновая программа выгребает фифо и парсит фреймы. В таком варианте будет достаточным иметь размер фифо байт на 16-64..
А парсер фреймов (собственно протокол) может иметь свой буфер на максимальный размер пакета.
Как-то так обычно делается.
Благодаря чему выполняется парадигма минимизации времени обработки прерываний...
Более того некоторые протоколы регламентируют максимальный размер фифо канала связи. Так например modbus имеет пожелания на размер фифо в 32 байта...

А если пример с NMEA? Там остановить передачу нельзя. В этом случае нужно иметь буфер на максимальную посылку. Ну а как обрабатывать - уже выше описали.

Тем более.
В 90% случаев цикл основной программы отрабатывается быстрее чем несколько мс. Только исходя из этого и выбирается размер фифо (чтобы не переполнился за эти пару мс).
Например на скорости 115200 один байт передаётся за ~90мкс, а цикл фоновой программы 2мс.
Следовательно минимальный размер фифо будет 2000мкс/90мкс = 22 байта. Округлим до ближайшего кратного 2 и получим 32.
ЧИТД. Вот такая простая арифметика.

А то, что вам написали (ловить старт-стоп) нужно делать в фоновой программе (в модуле протокола NMEA например медленно и печально искать пакеты и сверять crc) а не в ISR уарта.
Тем самым вы рассекаете на независимые логические модули свою программу.
Я вам дельный совет даю - прислушайтесь.

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

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

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

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

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

В данном же случае, очевидно, что NMEA не имеет никакой возможности загрузить контроллер до упора. Посему можно создавать кучу буферов и сделать программу более понятной для самого себя. Как бэ потренироваться в создании уровней обработки. На простом примере. Ибо также очевидно, что если чел не знаком с кольцевыми буферами, то ему самое время начать тренировки...

Времена, когда на IBM PC экономили память и оптимизировали код ассемблером канули в вечность.

Времена, когда нечего экономить и в микроконтроллерах - уже наступили. Только еще не все в курсе...

А собственно чего сидеть в прерывании USART, что Вам это даст ? У него самая тупая задача , принял (запихнул в буфер) - передал. На это он и расчитан.
Другую Вы ему даже предложить не сможете.
В лучшем случае в прерывании одна команда - вон туда положить. Никаких предворительных ласк делать не надо , как в случае - ВСЁ обрабатывать в прерывании (запихивать в стек регистры ,SREG и прочее, прочее, тратя на эту хрень время) . Вышли и всё остальное время можете тратить на разбор "полётов" .

Оценим на пальцах ДОБАВОЧНУЮ латентность, возникающую при использовании фифо.
Максимум один цикл основной программы в случае ТУПОГО суперлупа, а при использовании планировщика или чуть более внятного суперлупа много меньше.
Большая задержка? С Вас примеры где это действительно важно...

Автору уже советовали конечный автомат - так как он

упёрся в сложность программы. Если он перенесёт "работу с флажками" во внешнюю (по отношению к прерыванию) программы - не поможет...

Как это? Все равно ведь работа по прерываниям получше, чем по триггерам и использует ресурсы идеально.

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

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

А можно пояснить подробнее - в чём преимущество кольцевого буфера с размером, кратным степени 2 ?

Проще закруглять. Одной командой &.

Вовсе нет. Вас лично я и не пытался задеть.
Можем продолжить.
1. У ТС протокол без жёских временных ограничений (и таких протоколов несоизмеримо больше).
2. Кто мешает поставить команду sleep в тело суперлупа и просыпаться по тем же прерываниям уарта?

Или % что современные компиляторы хорошо оптимизируют.
что будет эквивалентнов случае когда FIFO_SIZE кратно степени 2.

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

1. Такое впечатление , что Вы планировщик сидя в прерывании не делали и отсылали подтверждение наобум лазаря.
2. Такие устройства по другому и не имеет смысла делать. Но , если в них и исполняется только одна команда.
P.S Он уже решил.

Как хотите)
1. У ТС проблемы с временем выполнения, я предложил один из вариантов ускорения, просто как вариант.
Так понимаю с обоснованностью в первом примере вопросв нет? Не поймите меня неверно, я не пропагандирую решение задачи на автоматах всегда и везде. Как-то раз приходилось приходилось дописывать чужую прогу реализованную подобным образом, там автоматы были весьма громоздкие и добавить еще пару команд оказалось довольно муторно.
2. Этот пункт касается моего второго примера? Если да, то, на первый взгляд, это эквивалентно. А посему включается религия, не позволяет вам сидеть в прерывании - делайте в суперлупе, мне позволяет.

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

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

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

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

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

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


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

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

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

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

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

Кольцевые буферы действительно не нужны.
Заведите два буфера - в один принимаете, другой обрабатываете, - и два указателя - на приём и обработку. По <CR> в прерывании меняете указатели местами и взводите флаг приёма строки. Вместо <CR> в буфер пишете 0x00, <LF> пропускаете.
Но, имхо, за 1с - 150*10/115200 = 987 мс можно не напрягаясь разобрать принятую строку и обойтись одним буфером.

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

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

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

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

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

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

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

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

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


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

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

Собсна... а зачем ждать, когда уарт примет целую строку?
Принимайте себе в "резиновый буфер" - с маркером конца (в смысле ASCIIZ), а в основном процессе есть указатель на начало непарсенных данных. А потом, когда ВКПС - все парсенные данные становятся валидными. Я б сказал, что все так и делают, когда надо быстро. Но не скажу

Расшифровываю: 100<X<500 Чему равен X когда надо отправить ответ? Ну как минимум сто . Т.е не раньше .Запятую поставил я - правила грамматики.

Цитата

и "сидим в прерывании" это вы сами придумали

- ничего подобного , это же Ваш принцип сидеть там до упора.

Каверкать чужие слова, и выдавать свои мысли за чужие - дурной тон, завязывайте с этим.
В ТЗ, кстати, было следующее "...отправить ответую посылку не позднее, чем через 10 битовых интервалов...", а сокрости работы от 19200 до 115200бод.

Что Вы написали , то я и "каверкую" , строго исходя из того что Вы пишите.
Прочитайте свою последнюю фразу и подумайте что Вы написали с точки зрения простой логики.

У вас явные проблемы с чтением
Расшифровываю правильно : ответить надо не позже, чем X мкс, где 100 < X < 500. Про "не раньше" там нет и не было.