Работа с COM портом с++ builder, Есть небольшие проблемы при работе своего устройства с СОМ Опции

[Diko]

Здавствуйтке.
Уже несколько дней, а то и недель занимаюсь тем, что изучаю, читаю, пробую, эксперементирую, но так положительного резутата и не получил, посему хочу обратиться к специалистам этого форума.
Постановка задачи примерно следующая, есть устройство, мною сделанное, требуется вычитать из него данные в ПК для дальнейшей обработки.
Устройство работает по RS-232. На стороне ПК стоит преобразователь USB-RS232TTL (какой именно, если это принципиально, могу посмотреть).
Обмен реализован следующим образом:
ПК посылает команду начала передачи данных.
после приема команды на передачу устройство передаёт первый пакет .
ПК принимает, анализирует его
если всё ОК, то высылает байт подтверждения, ( так же может послать останов передачи, повтора пакета).
устройство формирует новый пакет исходя из принятого байта.
Вроде всё работает более менее нормально, за исключением следующего. При вычитке данных из буфера время от времени происходит какая-то ситуация при которой вычитываются данные со смещением и тогда происходит ошибка анализа пакета, посылается запрос на повтор пакета, и опять вычитка со смещением и так циклически. До останова передачи данных.
Для раброты с КОМ-портом использую AsyncPro.
Функции вычитки байта и пакета дынных привожу ниже

Код

unsigned char TReadBuffer::ReadByte(char *byte, short int TimeOut)
{
//Ожидаем ответа
TimeCounter = TimeOut;    
        TimeOutCounter->Enabled=true;

while (ComPort->CharReady()==false) {
       if (TimeCounter==0) {
                return erTimeOut;}
        Application->ProcessMessages();
        }
*byte = ComPort->GetChar();
return erNoError;
}

//---------------------------------------------------------------------------

short int TReadBuffer::RecivePacket(unsigned char *buffer, unsigned char Count)
{
unsigned char b;
  for (short int i=0; i<Count; i++){
    
        if (ReadByte(&b, ReadByteTimeOut) == 0) {
                *buffer=b;
                 buffer++;}
                else return erTimeOut;
        }
        ComPort->FlushInBuffer();
  return erNoError;
  }
//---------------------------------------------------------------------------

ComPort->FlushInBuffer(); - поставил дабы при сбое очистить буфер и начать всё сначала. Пробовал ставить как в данный модуль или ставил при возникновении CRC-error... Результат приммерно одинаковый, раз в какое-т овремя происходит смещение чтения.... Не могу понять почему.
Понимаю, что где-то неправильно организованы контроль наличия байта в буфере и чтение, но не могу понять где и что....

AsyncPro позволяет писать логи того что принимается и передаётся, согласно задумке. пакеты передаются правильно. после приёма правильного пакета, передаётся байт необходимости повтора пакета, получается точно такой же пакет! и уже отправляется байт что всё ОК, потом несколько пакетов передаются нормально, и опять ....

Пакеты короткие по 7 байт.

57 32 0B 10 00 00 72
00 3A 02 32 01 00 6B
61 62 63 64 02 00 D4
65 66 67 68 03 00 66
B7 58 84 01 04 00 6E
03 B7 58 8E 05 00 EA

8E 05 00 EA 01 E4 B7
58 06 00 11 01 E4 B7

это то что получается в buffer. до "разыва" всё идёт хорошо, а вот следующий пакет уже содержит часть предыдущего 8E 05 00 EA . Пакет должен был выглядеть 01 E4 B7 58 06 00 11

Не знаю доступно ли я изложил свою проблему, но она есть и я не знаю как её побороть, т.к. опыта в программировании малова-то.
Большое спасибо за помощь

[Diko]

вот непонятно почему тут вы отвечаете 32

а вот тут - 31?
одинаковые же пакеты?

Вот здесь-то как раз и засада В том что устройство отвечает "правильно", а вот ПО на стороне ПК немного неправильно вычитывает из буфера. И соответственно считает, что пакет неверен и отправляет 32 - хочу ещё раз этот пакет. Вот что видно на стороне ПО...
B8 3D 94 01 4F 00 09
E5 B8 3D 9E 50 00 50

CD E5 B8 3D 9E 50 00
E5 B8 3D 9E 50 00 CD

Функция ReadByte для AsyncPro написана идеологически неправильно.
Нельзя ждать там прихода данных и делать ProcessMessages. ProcessMessages очень скверная функция могущая застрять на неопределенное время.
Надо перехватить событие поступления данных и читать столько сколько событие скажет.

AsyncPro - это многопоточный движок. Ему не надо помогать циклами ожидания.

Как-то так я и думал... Точнее я даже в этом был уверен. Почему-то у меня не сложилось с событиями ( что точно я уж не поминю, точно делал функцию приёма в событии но толи не доконца разобрался толи ещё какая-то беда была. Работала функция не совсем так как я хотел, а всвязи с тем что не доконца понимаю что не так, решил сделать так как понимаю, ну или кажется что понимаю. Подозрения на ProcessMessages были, но здесь два но. Первое то что я решил ну раньше или позже будет вычитан байт из буфера ... не важно, никуда из буфера не денеться. Второе я убирал ProcessMessages из функции, координально ничего не изменилось).
Можете ли привести пример как правильно организовать приём "пакета" с использованием событий в AsyncPro, пакет не большой 7 байт.

Таймауты - стандартная фича любого протокола.
Реальное там время или не реальное не так важно в данном случае. В Windows нет понятия реального времени.
В компоненте AsyncPro есть собственное поле задания таймаута. Им и надо пользоваться, а не пытаться заново строить велосипед.

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