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

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

Цитата

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

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

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

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

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

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

не, можно быстрее
если 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 подпрограммами) я навскидку не понял, буду пробовать его осознать

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




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





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



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

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


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



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