реклама на сайте
подробности

 
 
> Работа с COM портом с++ builder, Есть небольшие проблемы при работе своего устройства с СОМ
Diko
сообщение Nov 16 2016, 19:39
Сообщение #1


Частый гость
**

Группа: Свой
Сообщений: 114
Регистрация: 14-08-07
Из: Харьков, Украина
Пользователь №: 29 773



Здавствуйтке.
Уже несколько дней, а то и недель занимаюсь тем, что изучаю, читаю, пробую, эксперементирую, но так положительного резутата и не получил, посему хочу обратиться к специалистам этого форума.
Постановка задачи примерно следующая, есть устройство, мною сделанное, требуется вычитать из него данные в ПК для дальнейшей обработки.
Устройство работает по 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

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


--------------------
Жизнь сложна и не предсказуема, незачем её усложнять.
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
Diko
сообщение Nov 17 2016, 19:38
Сообщение #2


Частый гость
**

Группа: Свой
Сообщений: 114
Регистрация: 14-08-07
Из: Харьков, Украина
Пользователь №: 29 773



Цитата(zltigo @ Nov 17 2016, 11:43) *
В огороде бузина, а в Киеве дядька - у "любого" протокола таймауты это обязательные АВАРИЙНЫЕ ветки. Использование таймаутов для фрейминга, это фича УБОГИХ протоколов. Использование убогих протоколов с таймаутами для фрейминга в системах типа Windows не имеющих поддержки реального времени есть 100% махровая любительщина sad.gif. Так что протокол менять однозначно, а не бороться до конца жизни с тем, что надежный фреймиг по небольшим таймаутам под Win нереализуем в принципе.

ЭЭхххх, даже не могу ничего возразить - просто потому что "протокол" это очень громко сказано, и определение УБОГИЙ вполне себе подходит. Никогда до этого не сталкивался с организацией передачи данных между устройством и ПК. Посему и наступил на эти грабли. В связи с тем что само по себе устройство не весть что, думал как-то обойтись малой кровью точнее малыми трудозатратами. Т.е. раз в интервал времени сформировать пакет и отправить его на ПК, а уже на стороне ПК всё это собрать. Скорость передачи не имеет большого значения - не первостепенная задача. Сейчас у меня передача 32кБ занимает около 5 минут, меня это вполне устраивает. Чтение данных в таком объёме предполагается раз в месяц в лучшем случае, а то и реже. От скорости передачи СОМ это не зависит, скорость ограничена именно интервалами отправки пакетов. т.е. и на 9600 и на 115200 время передачи занимает одинаковое.
И да это любительщина эпитеты к слову любительщина можно подбирать самостоятельно и долго, я с ними согласен.
В данном проекте я наступил на идиологические грабли. Сделать сейчас как-нибудь чтобы побыстрее, а потом уж переделаю как надо... Сам за такое "вжаривал".
Протокол менять... Ну, менять можно то что есть и работает sm.gif Сейчас вобщем-то ничего нет. Что вы порекомендуете ? Как изменить протокол и как его реализовать ?


Цитата(AlexRayne @ Nov 17 2016, 20:05) *
чем городить такое лучше поправить протокол - для этого не нужно городить железо, и оно будет надежно работать почти везде. неужели невозможно ввести маркер заголовка?
CTS-RTS вам поможет мало. лучше посмотрите в сторону линии DTR-DSR - кажется они дают прерывание и можно повесить обработчик этого события. но вы покладете комп на обработку этих прерываний если они будут лететь интенсивно, а судя по размеру ваших пакетов - они будут свистеть интенсивно. - на вендовой (да и на линуховой) машине гораздо быстрее будет работать обмен с маркером чем с прерыванием.


Да можно ввести и маркеры, сейчас над этим и думаю. Пакеты коротки не потому что они идут с большой скоростью, а просто так сложилось ....
Без особых на причин. 32кб передаются около 5 минут.


--------------------
Жизнь сложна и не предсказуема, незачем её усложнять.
Go to the top of the page
 
+Quote Post
iosifk
сообщение Nov 17 2016, 19:50
Сообщение #3


Гуру
******

Группа: Модераторы
Сообщений: 4 011
Регистрация: 8-09-05
Из: спб
Пользователь №: 8 369



Цитата(Diko @ Nov 17 2016, 22:38) *
И да это любительщина эпитеты к слову любительщина можно подбирать самостоятельно и долго, я с ними согласен.
В данном проекте я наступил на идиологические грабли. Сделать сейчас как-нибудь чтобы побыстрее, а потом уж переделаю как надо... Сам за такое "вжаривал".
Протокол менять... Ну, менять можно то что есть и работает sm.gif Сейчас вобщем-то ничего нет. Что вы порекомендуете ? Как изменить протокол и как его реализовать ?

Протокол с байт-стаффингом. Ищите:
Wake
Ридико Леонид Иванович

Примеры кода там выложены..


--------------------
www.iosifk.narod.ru
Go to the top of the page
 
+Quote Post
zltigo
сообщение Nov 17 2016, 20:36
Сообщение #4


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



QUOTE (iosifk @ Nov 17 2016, 21:50) *
Протокол с байт-стаффингом. Ищите:
Wake

Если без дополнительной скорее всего не нужной шелухи, то останется просто SLIP https://tools.ietf.org/html/rfc1055



--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post

Сообщений в этой теме
- Diko   Работа с COM портом с++ builder   Nov 16 2016, 19:39
- - Diko   Покопался в том что у меня происходит и вот что ув...   Nov 16 2016, 21:29
|- - AlexRayne   Цитата(Diko @ Nov 17 2016, 01:29) B вот к...   Nov 16 2016, 21:54
|- - AlexandrY   Функция ReadByte для AsyncPro написана идеологичес...   Nov 16 2016, 22:02
- - AlexRayne   Цитата(Diko @ Nov 16 2016, 23:39) short i...   Nov 16 2016, 22:03
|- - AlexandrY   Цитата(AlexRayne @ Nov 17 2016, 00:03) За...   Nov 17 2016, 03:36
|- - zltigo   QUOTE (AlexandrY @ Nov 17 2016, 06:36) Та...   Nov 17 2016, 08:43
|- - k155la3   Цитата(zltigo @ Nov 17 2016, 12:43) . . ....   Nov 17 2016, 09:16
||- - Ruslan1   Цитата(k155la3 @ Nov 17 2016, 11:16) А ес...   Nov 17 2016, 09:35
||- - AlexRayne   Цитата(k155la3 @ Nov 17 2016, 13:16) А ес...   Nov 17 2016, 17:05
||- - k155la3   Цитата(AlexRayne @ Nov 17 2016, 20:05) . ...   Nov 18 2016, 10:22
||- - iosifk   Цитата(k155la3 @ Nov 18 2016, 13:22) 1. В...   Nov 18 2016, 10:48
||- - k155la3   Цитата(iosifk @ Nov 18 2016, 14:48) Это с...   Nov 18 2016, 11:05
||- - AlexandrY   Цитата(k155la3 @ Nov 18 2016, 13:05) Если...   Nov 18 2016, 11:10
||- - k155la3   Цитата(AlexandrY @ Nov 18 2016, 15:10) Та...   Nov 18 2016, 11:26
|- - AlexandrY   Цитата(zltigo @ Nov 17 2016, 10:43) В ого...   Nov 17 2016, 10:19
|- - k155la3   Цитата(AlexandrY @ Nov 17 2016, 14:19) . ...   Nov 17 2016, 11:15
|- - zltigo   QUOTE (AlexandrY @ Nov 17 2016, 12:19) На...   Nov 17 2016, 19:12
- - Diko   Цитата(AlexRayne @ Nov 17 2016, 00:54) во...   Nov 17 2016, 06:28
- - k155la3   Цитата(Diko @ Nov 16 2016, 23:39) Здавств...   Nov 17 2016, 07:05
|- - AlexandrY   Цитата(k155la3 @ Nov 17 2016, 09:05) Если...   Nov 17 2016, 07:20
|- - Ruslan1   Вот кусок кода из работающей программы, лет много ...   Nov 17 2016, 07:53
- - Diko   Цитата(k155la3 @ Nov 17 2016, 10:05) без ...   Nov 17 2016, 17:55
||- - Ruslan1   Ага. я тоже за SLIP RFC1055. обрамил кодом команды...   Nov 17 2016, 20:46
|- - AlexandrY   Цитата(Diko @ Nov 17 2016, 21:38) Как изм...   Nov 18 2016, 07:55
|- - Diko   Цитата(AlexandrY @ Nov 18 2016, 10:55) В ...   Nov 18 2016, 20:49
- - Diko   Спасибо. Буду поизучать в этом направлении.   Nov 17 2016, 20:15
- - Diko   Всем откликнувшимся огромное спасибо. Благодаря эт...   Nov 19 2016, 15:43


Reply to this topicStart new topic
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 18th July 2025 - 19:46
Рейтинг@Mail.ru


Страница сгенерированна за 0.01449 секунд с 7
ELECTRONIX ©2004-2016