Как грамотные люди делают прием пакетов по USART Опции

[TamTam]

Ну написал с горем пополам обработку прирывания по окончанию приема байта, процедурку копирования из буфера в eeprom, но вот вопрос ???

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

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

[TamTam]

Мне понравилось как у Атмела сделано. Я такую конструкцию не только для уарта применяю, но и вообще где надо стыковать асинхронные процессы. Также в примерах исходников prottos привел классный драйверок - аналог. На прием естественно надо таймаут ставить - после приема каждого байта заряжать таймер. Если нет данных в течение опеределенного времени - сбрасываем стэк. Кроме кольцевого буфера нужен буфер для сборки принимаемых пакетов и буфер для сборки отправляемых пакетов. А на будущее - haker_fox далл ссылку на прекрасный на мой субъективный взгляд протокол. Сам его повсеместно использую. Четко и стабильно работает. Програмная реализация тоже есть в исходниках.

Да WAKE штука хорошая. Я его тоже однажды применял. но железо не моё было я токо под дельфю переписывал. Хотел библу с исходником выложить да так и потерял сурц а библа гдето лежит.

[Sergiy]

Да, обратите внимание на фразу, что в обработчиках прерывания должны быть краткие функции, и не в коем случае писать незя в ЕЕПРОМ, потому что процесс достаточно длителен (мс на байт), выставьте битовую переменную, что нужный пакет в буфере обмена и готовьте следующее окно (я использую двухоконные буфера), когда один заполняется, второй готов и константен для целевой функции - все довольны, а оперирую двумя битовыми флагами, один показывает, что новый буфер подготовлен и ожидает, а второй что какое окно надо пользовать в данный момент целевой функцией, первое может менять в активное состояние прерывание приемника, в пассивное возвращает целевая функция, а окна переключаются в инверсии, да два буфера хватит если есть простой в конце заполнения второго буфера и ждать пока не будет сброшен обработки первого буфера в целевой функции.

Когда позволяет выбрать протокол - выбор вообще делаю в пользу битовой синхронизации начала пакета, работает не просто железно, а супержелезно. По таймауту тоже применяю, когда надо минимальная длина пакета с простой упаковкой. Применять шапочную синхронизацию по голове и-или хвосту без таймаутной проверки не стал бы - рискуете потерять часть пакетов и рассинхронизироваться, когда в секторе данных будут шапки - поймете их за служебные - а это только данные на самом деле. Но когда нить конечно синхронизация будет восстановлено, но пакеты патеряны для вас. Можно синхронизировать тройками, когда в секторе данных есть синхросимволы, то повторять их подряд три раза, это знак что это данные. Но это немного увеличит трафик и распаковку пакетов. Да, при таймаутах учитывайте особенности программирования под винду. Обрамляйте процесс передачи пакета в Делфи или Билдере где вы там пишете в РиалТайм процесс, это делается парой строчкой на Делфи но значительно понижает вероятность ложного таймаута внутри пакета. Хотя шанс маленький все равно остается, иногда больший (на раком установленных операционках, высокоприоритетных задачах, выполняемых одновременно с вашим приложением - запись, форматирование дисков .