Как лучше принять данные из сериал?
- Войдите на сайт для отправки комментариев
Пт, 07/07/2017 - 21:27
byte MessageRx[100]={0}; //массив байтов принимаего сообщения
if (mySerial.available()) {
delay(100);
int k=0;
byte inbyte=0;
while( mySerial.available() && k < 100) {
inbyte = mySerial.read();
MessageRx[k] = inbyte;
k++; }
Serial.print ("Recieve: ");
for (int i = 0; i < k; i++) {
Serial.print(MessageRx[i],HEX); Serial.print (" ");}
Serial.println (""); //распечатаем принятое сообщение в сериал
for (int i = 0; i < 12; i++) MessageRx[i]=0;
Принимаются данные от ЭБУ двигателя автомобиля в виде сообщений, между посылкой каждого байта примерно 1мс. Скорость 10400 бод. между сообщениями от 50 до 150 мс.
1. Хотелось бы избавиться от задержки delay, а то остальное тормозит
2. Принимаемое сообщение длиной 81 байт. Данный скетч (или ЭБУ?) его режет на две части. Нужно понять это делает скетч или ЭБУ. Подсматривая обмен данных ЭБУ и диагностического прибора сниффером, задержка в этом сообщении в 81 байт присутствовала по середине сообщения.
Нужно както записывать это сообщение всё полностью в один массив.
Может считывать можно не через Serial.available()? а еще както,
вот что показал сниффер, Жирным это запрос от диагностики, остальное ответ ЭБУ
82 11 F1 21 1 A6 80 F1 11 4C 61 1 0 0 0 0 0 0 0 0 C A7 1 7B C 6E 0 0 2 B4 0 0 12 21 4 3A 0 0 3 1F B AD 3
112ms
AC 4 2F 3 20 F0 65 0 0 0 0 B 71 2 FF 3 2A 8 AA 1 8F C 5C A0 0 1 2C 3 41 AD 8 1 30 0 0 1 7E B F9 3 AD 0 2 B4
258ms
82 11 F1 21 1 A6 80 F1 11 4C 61 1 0 0 0 0 0 0 0 0 C A7 1 7C C 6D 0 0 2 B3 0 0 12 3F 4 39 0 0 3
110ms
21 B B3 3 AC 4 2F 3 20 F0 5A 0 0 0 0 B B1 2 FB 3 20 8 AA 1 91 C 5C A0 0 1 2C 3 72 AD 8 1 30 0 0 1 7D B F9 3 AD 0 2 31
т.е. ардуина выступает вместо диагностики и получает данные. Вот так коряво получает, сообщение принимаемое 63 байта, это потому что такой размер буфера Serial ? Вот что творится в сериал уже при приеме данных ардуиной
Recieve: 0 FF FF 83 F1 11 C1 6B 8F 40 Recieve: FF FF 83 F1 11 C1 6B 8F 40 Initialization OK!!!!: Otpravil zapros 21 01 Recieve: FF FF FF 80 F1 11 4C 61 1 0 0 0 0 0 0 0 0 E 2C 0 0 D E5 0 0 2 72 0 0 0 0 4 39 0 0 0 0 32 C8 3 9F 4 29 3 20 E5 62 0 0 0 0 E 6E 0 0 0 0 8 AF 0 0 C CC Otpravil zapros 21 01 Recieve: FF FF FF 80 F1 11 4C 61 1 0 0 0 0 0 0 0 0 E 2E 0 0 D E5 0 0 2 71 0 0 0 0 4 3A 0 0 0 0 32 C8 3 9F 4 29 3 20 E5 62 0 0 0 0 E 70 0 0 0 0 8 AF 0 0 C CC Otpravil zapros 21 01 Recieve: FF FF FF 80 F1 11 4C 61 1 0 0 0 0 0 0 0 0 E 2E 0 0 D E5 0 0 2 72 0 0 0 0 4 3A 0 0 0 0 32 C8 3 9F 4 29 3 20 E5 62 0 0 0 0 E 70 0 0 0 0 8 AF 0 0 C CC Otpravil zapros 21 01 Recieve: FF FF FF 80 F1 11 4C 61 1 0 0 0 0 0 0 0 0 E 2C 0 0 D E5 0 0 2 72 0 0 0 0 4 3A 0 0 0 0 32 C8 3 9F 4 29 3 20 E5 62 0 0 0 0 E 70 0 0 0 0 8 B0 0 0 C CF1. Хотелось бы избавиться от задержки delay, а то остальное тормозит
так удалите ее, зачем вообще там задержка?
тогда каждый байт будет писаться в нулевой байт массива
т.е. вместо такого сообщения 0 FF FF 83 F1 11 C1 6B 8F 40 получим несколько коротких однобайтовых :
0
FF
FF
83
F1
11
C1
6B
8F
40
тогда каждый байт будет писаться в нулевой байт массива
вы бредите. Код свой посмотрите внимательно
я так понимаю в буфер mySerial без задержки успевает попасть только один байт, и потом там какоето время ничего нет, поэтому он сразу выходит из цикла while.
MaksVV
Как я вижу, вы с помощью задержки пытаетесь группировать байты в сообщения. Задержка - чрезвычайно ненадежный метод. На практике он работать не будет. Вы сами пишете, что интервал между сообщениями от 50мс. Значит при задержке 100мс у вас в массив может попасть несколько сообщений за раз, буфер переполнится и часть данных пропадет. Вам надо читать Serial без задержек, все подряд, а границы между сообщениями вычмслять по значениям ключевых байт. Например, судя по выводу в сообщении #1, у вас каждый ответ ЭБУ начинается с FF FF FF - вот на это и ориентируйтесь.
вообщето я пытаюсь как раз от задержки избавиться. А скетч который вверху нашел в инете. В принципе так и хотел как вы говорите действовать. Попробую. Хотя на данный момент все работает, после того как я увеличил буфер софтсериал до 100 байт. Но это не айс.