PIC и BlueTooth

[mike-y-k]

AndGrig, только лучше подробней для всех - где и что забивал этот поток байт.
Суть ошибки уже прорисовалась, осталось всем оставить четкое описание как не нужно делать

[akegor]

осталось всем оставить четкое описание как не нужно делать

Обычно при немонстроидальном обмене работаю в ASCII. При этом информация идет символами от 0 до F, из остальных можно любой использовать для синхронизации.
Есть "стартовый" байт и признак конца строки (обычно 0x0d и 0x0a). Пока не пришел стартовый байт можно все отбрасывать. Есть некоторая избыточность, но алгоритм простой, как грабли.

[AndGrig]

AndGrig, только лучше подробней для всех - где и что забивал этот поток байт.
Суть ошибки уже прорисовалась, осталось всем оставить четкое описание как не нужно делать

Вроде я все описал.
В даташите на PIC16F876 в разделе 10.2.2 "Асинхронный приемник USART" написано, что приемник может хранить в своем регистре только 2 байта. Если приходит 3-й байт, а регистр полон, то контроллер выставляет флаг переполнения приемника и прекращает прием. Перезагрузка контроллера командой goto 0x00 этот флаг не сбрасывает.
Передо мной стояла, в общем-то, стандартная задача - в произвольный момент времени подключиться со смартфона к контроллеру и неспешно передать/принять два байта. При подключении смартфона к блютузу, соединенному с контроллером, они знакомятся и договариваются о сотрудничестве обмениваясь информацией. И нет чтобы сделать это по тихому между собой, так все это вываливается на вход Rx контроллера. В моём случае обработка двух байт требует запрещение прерываний и занимает 4 мсек. За это время входной регистр приемника забивается и приемник выключается.
Решения задачи:
1. Нужно все это читать и выбрасывать.
2. Выключить приемник на 50 мсек, а затем опять включить.
3. Ничего не делать (приемник сам отключится) и через 50 мсек сбросить ошибку переполнения.
Как узнать, что пошел прием не нужной мне информации? Она начинается с определенного заголовка, заканчивается какой-то финальной фразой и длится чуть менее 50 мсек. Заголовок всегда начинается байтом 0х2В (нужно посмотреть еще пару байтов для надежности). Получив этот байт, я жду 50 мсек, а затем сбрасываю ошибку переполнения как описано в даташите.

Уважаемый akegor просто все читает и выбрасывает пока не придет особый заголовок сообщения. Это позволяет организовать работу с несколькими устройствами.
Я только не совсем понял "...работаю в ASCII. При этом информация идет символами от 0 до F". Ведь ASCII использует один байт, т.е. от 0х00 до 0хFF.

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

[Eddy71]

Зачем всё так сложно?
Принялся байт - сработало прерывание - в прерывании быстренько байтик считали, сохранили в буфер и пошли работать дальше. Флаг приёма сам очистится..

[akegor]

Ведь ASCII использует один байт, т.е. от 0х00 до 0хFF.

Нибблы байта принимают значения от нуля до "Ф", они передаются соответствующими символами. Другими словами, один байт передается двумями.
В случае с модемом - жду его сообщение об успешной регистрации в сети, после этого начинаю с ним работать. Все принимается в буфер достаточного размера, не два байта.

[mike-y-k]

AndGrig, уважаемый akegor написал об обмене распакованными бинарными данными в шестнадцатеричном формате - там действительно только 0…9, A…F. Других шестнадцатеричных цифр ещё не придумали. Пишите свою реализацию sprintf/sscanf для формата %x или %X и пользуетесь. При передаче и приёме только будет в 2 раза больше данных.

В Вашем случае при спаривании устройств прочитать все, пришедшее по UART и дальше уже продолжить нормальное выполнение.
Самое правильное - кольцевой буфер на некоторое (›2) количество символов и разборки с ним. Можете для старта своего обмена просто передать набор байт, который не встретится в основном обмене.
По совету уважаемого akegor это может быть любая отличная от используемых 0…9,A…F (0x30…0x39, 0x41…0x46, 0x61…0x66) комбинация. Например два байта 0x00…
Приём данных из UART, как и их передачу организовать на буферах в памяти и исключительно в прерываниях. В основной программе только анализ флагов и указателей.