Попробуйте подумать ещё чуть чуть. Вы всё для себя написали сами

не, можно быстрее
если 3 байта. 2 байта = адресс подпрограммы.
1 = счётчик байт.

тем самым вы не тратите на ран-тайме время для вычисления адреса. на этапе компиляции он автоматически вычисляется. единственный минус такого подхода - более аккуратное программирование..

(круглый)

Мда. Это клиника...
Вам уже три человека сказали, что вы неправы. Может, попробуете подумать?

Для тех кто в танке и думать не хочет , а может и хуже ,читаем специально для них


Что имеем : Отправить команду непозже чем цать мкс - сия фраза смысла не несёт , смысл имеют озвученные цифры
Обозначим время ответа X
больше 100 - значит Х>100
меньше 500 - значит Х<500
Получается , что ответ надо отправить в промежуток между 100мкс - 500мкс - 100<X<500

Отсюда следует , что X должен быть, НЕ МЕНЬШЕ 100 ( по условию Х>100) и НЕ БОЛЬШЕ 500 (по условию Х<500)

Вследующий раз , когда будете что-то писать - ДУМАЙТЕ!!!

"при получении команды следует отправить подтверждение приема не позже чем через X мкс" - что не так со смыслом?


Цифры относятся к одному числу X. Оно может принимать значения от 100 до 500, конкретного значения написавший не помнит.


Никоим образом не получается.

Почему "не несет"? Очень даже несет - там написано что время ответа от 0 до Х.




Нет, здесь написано что максимальное значение Х может быть от 100 до 500.
А поскольку про минимальное вообще ничего не указано, то его можно принять равным нулю, т.е. ответ сразу.


Т.е. в целом, интервал ответа может быть от 0 до 100 , и от 0 до 200, и от 0 до 500.
Вот от 0 до 600 - уже не может.



вот именно

Allregia , aaarrr

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

Я восхищён упорством упёртостью этого человека!

О как интересно! Примерно в то же время, что разворачивалась дискуссия, я тоже писал свою первую (и пока единственную) в жизни программку на С - драйвер GPG-модуля, прием/передача NMEA команд по USART, причем в рамках невытесняющей многозадачности с планировщиком И тоже хотел анализировать символы и считать контрольную сумму внутри прерывания по приему, и также дискутировал с руководителем проекта, который меня убедил, что на этом бедном камне кроме моего вшивого GPS висят ещё дохрена внешних железяк по SPI, USART и просто на ногах по уровням, и что сидеть в прерываниях мы не будем дольше минимально необходимого времени для записи байта, и добил наличием прерываний без флагов, которые мы вообще потеряем, если будем сидеть долго в других, ибо AVR вложенные прерывания не допускает... И я понуро пошел осваивать кольцевой буфер с указателями хвоста и головы, разбор его содержимого при каждом такте системного таймера планировщика, только разумеется безо всякого сдвига самого буфера и переписывания его ещё в какие-то массивы - только результирующие координаты в глобальную переменную, по буферу бежал по элементам последовательно и без возвратов, размер кратным степени 2 не делал (банально не влез в ОЗУ отладочного маленького камня, надо минимум 80 (максимальная посылка NMEA), а 128 уже не влезал) - и что, нормально все работает, я был очень рад и доволен Сразу после включения GPS конечно начинает слать по несколько посылок одновременно каждую секунду, и буфер скорее всего переполняется, но я его сначала не анализирую, отправляю команду "слать только формат RMC раз в N секунд", и даже если он шлет раз в секунду вполне успеваю разгрести буфер и даже вывалить в отладочную печать в терминал и сами посылки и разобранные валидные координаты.

ЗЫ решение, как его придумал автор (с 25 подпрограммами) я навскидку не понял, буду пробовать его осознать

Что за прерывания без флагов, просветите.
Зачем вы их теряете, зря это.




Согласен именно ":)"





Да, хорошо быть начальником: он по определению и не дурак и мат часть знает.



Я так понял что у вас а не мегаАВР, а недоАВР какой-то. Но "невытесняющая многозадачность с планировщиком"
при этом влазит (какая ОСь кстати?).

ИМХО, отлаживаться правильней/удобней на большем камне, а не на меньшем (я про ОЗУ).


Да, хорошо быть начальником: он по определению и не дурак и мат часть знает.



Это смотря как делать.
См.
ссылка

Был бы специалистом - просветил бы. А так только на задворках памяти осталось что-то типа прерываний по высокому/низкому уровню на ногах.


Спасибо за науку и пример. Буквально несколько часов назад обсуждали с тем же руководителем проекта применение именно такой особенности AVR (и не только их) - возможность сделать enable interrupt внутри прерывания, запретив только этот же источник - для вынесения "параллельных потоков" наружу уже готового линейного кода без переделки последнего, сохранение при этом в стек адресов возвратов из прерываний очень вдохновляет.


Ну, это в данном случае не следствие а наоборот причина, почему он начальник


В финальном проекте будет.... не знаю что, но AVR побольше. А отлаживаю я свой блок на AT90USB162 с 512 байт ОЗУ На что начальник говорит - если ты уложишься в эти 512 байт, то в готовом проекте я буду уверен, что ОЗУ не переполнится даже если все задачи начнут работать одновременно (условно). А у меня там ещё и конвертор USB<->COM с приемом команд и выдачей отладочной информации в терминал на комп
ОС нет, самонаписанный нами же шедуллер, который по кругу запускает задачи, каждая из которых написана НЕ как при ОС - как будто других задач нет и все время её, а в виде "зашел, проверил готовность предыдущего шага - начал следующий - вышел", если я понятно объяснил


Спасибо за полезные прямые ссылки, буду изучать и пытаться понимать.
ЗЫ: если в прерывании по приему очередного символа не делать ничего. кроме того как класть его в кольцевой буфер, то конечно даже в этом случае можно исхитриться и обойтись буфером меньше длины посылки (отрезая уже проверенные символы и считая контрольную сумму), но мне было проще анализировать имея строку целиком. Я подозреваю, что при анализе буфера я много раз пробегаю от начала посылки до конца буфера - и если посылка ещё не вся пришла, то делаю это зря... Но таков сейчас мой алгоритм анализа. Можно конечно придумать флаг - пришел конец посылки и тогда анализировать буфер, а после анализа сбрасывать...

Флаг вроде был. Но один на все источники.




100%-но работающая возможность, лишь бы стека хватило.



Понятно, что-то вроде вызова функций, сохраняющих номер итерации(состояния).



Флаг придумать несложно: например приём символа с кодом 0x0D(CR) означает конец строки в NMEA и по нему можно начинать анализ.

Успехов.