И размеры с обеих сторон

И crc, если передавать эти пакеты без самой контрольной

Чуда не бывает, надо пошагово делать и смотреть.

Если с контрольной, то размеры по прежнему совпадают, но не контрольные при пересчете

Чуда не бывает, надо пошагово делать и смотреть.

Согласен

Сделал

Ты размер структуры проверял?

Да

16 байт

Только uint32 как значения и uint8 контрольной использовались для передачи данных

uint8_t crc8(const uint8_t *array,.......) - вот это ?

Да

А как ты принимаешь пакет?

Uart

Readbytes

В буфер

Надо кусок кода для понимания.

Минуту

while (Serial.available()) { int c = Serial.read(); crc.add(c); } Serial.println(crc.getCRC());

Нет, иначе, минуту

if (SoftSerial.readBytes((byte*)&buf, sizeof(buf))) { myCrc.restart(); myCrc.add((uint8_t *)&buf, sizeof(buf) - sizeof(buf.crc)); uint8_t crc = myCrc.getCRC(); ... }

Readbytes

Во. Выведи что возвращает этот метод readBytes, тоже 16 ?

да, 16

if (SoftSerial.readBytes((byte*)&buf, sizeof(buf))) { myCrc.restart(); myCrc.add((uint8_t *)&buf, sizeof(buf) - sizeof(buf.crc)); uint8_t crc = myCrc.getCRC(); ... }

это принимающая сторона

void foo() { ... myCrc.restart(); myCrc.add((uint8_t *)&buf, sizeof(buf) - sizeof(buf.crc)); buf.crc = myCrc.getCRC(); SoftSerial.write((uint8_t*)&buf, sizeof(buf)); ... }

void foo() { ... myCrc.restart(); myCrc.add((uint8_t *)&buf, sizeof(buf) - sizeof(buf.crc)); buf.crc = myCrc.getCRC(); SoftSerial.write((uint8_t*)&buf, sizeof(buf)); ... }

это отправитель

void foo() { ... myCrc.restart(); myCrc.add((uint8_t *)&buf, sizeof(buf) - sizeof(buf.crc)); buf.crc = myCrc.getCRC(); SoftSerial.write((uint8_t*)&buf, sizeof(buf)); ... }

buf как определен ?

struct Str { float val_f; int val_i; int val_l; uint8_t crc; }; Str buf;

на данный момент нагружена структура так

на переопределения uint к int не обращайте внимания, рефакторинг не провёл

buf как определен ?

по обе стороны

И crc надо считать на буфере. И добавлять её в конец. После передачи отрезать crc считать на буфере и сравнивать.

А уже потом расковыривать содержимое.

ещё раз. на сторне отправителя считаю весь буфер, без сrc, затем рассчитанный crc я закидываю в конец. только затем я пакет отправляю, успешно принимаю, все значения верны. "расковыриваю", как вы выразились, пакет и затем считаю вновь принятый буфер без последнего crc в нём. в конце я сравниваю рассчитанный на принимающей стороне crc относительно crc в самом пакете, который в рассчёт не брал

И crc надо считать на буфере. И добавлять её в конец. После передачи отрезать crc считать на буфере и сравнивать.

и у меня результат описанный выше. я изначально сделал, как вы посоветовали, посему и обратился под конец, когда зашёл в тупик

""расковыриваю", как вы выразились, пакет и затем считаю вновь принятый буфер без последнего crc в нём. " CRC считается на буфере.

т.е. проходит сериализация. По полученному массиву раcсчитывается CRC. На удалённой стороне, после приёма, опять рассчитывается CRC на принятом массиве. И только потом проводится десериализация.

ещё раз. на сторне отправителя считаю весь буфер, без сrc, затем рассчитанный crc я закидываю в конец. только затем я пакет отправляю, успешно принимаю, все значения верны. "расковыриваю", как вы выразились, пакет и затем считаю вновь принятый буфер без последнего crc в нём. в конце я сравниваю рассчитанный на принимающей стороне crc относительно crc в самом пакете, который в рассчёт не брал

"Все значения верны" - Т.е. побайтно проверял что в структуре? Если нет, вот ниже есть код Serial.print("BUF: "); uint8_t *array = (uint8_t *)&buf; for(int i = 0; i < sizeof(buf); ++i) { Serial.print("%02X ", array[i]); } Serial.println("");

и вот вывести этот буфер с crc до отправки и после приёма и сравнить.

сейцчас проверю

И ещё лучше, буфер до отправки без CRC, саму CRC, потом с добавленной CRC, и на другой стороне, принятый с CRC, отрезанную CRC и остаток без CRC.

Если это совпадает, то на вход расчёта CRC на двух сторонах подать одинаковые данные и убедится, что результат один.

На момент разработки не ставьте функции в конструкции if, лучше int _size=Serial.readBytes; Serial.print("_size="); Serial.println(size); if (_size)... Вы же алгоритм ищите, а не сжатием текста занимаетесь. После оптимизация.

На момент разработки не ставьте функции в конструкции if, лучше int _size=Serial.readBytes; Serial.print("_size="); Serial.println(size); if (_size)... Вы же алгоритм ищите, а не сжатием текста занимаетесь. После оптимизация.

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

Я имел ввиду, что чем больше информации будет выведено, тем легче поймать ошибку.

Можно через define отрезать вывод.

Я имел ввиду, что чем больше информации будет выведено, тем легче поймать ошибку.

В данном случае при выводе всего пакета будет виден размер. Но так то да.

Я имел ввиду, что чем больше информации будет выведено, тем легче поймать ошибку.

С твоим примером все правильно, т.к. еще у Serial стоит таймаут и чтение может быть не полноценным

Передавайте первый байт размер пакета. Организуйте побайтовый прием и будет вам счастье. А crc лучше таблично считать. Самый быстрый код по времени.

Name : CRC-8 Poly : 0x31 x^8 + x^5 + x^4 + 1 Init : 0xFF Revert: false XorOut: 0x00 Check : 0xF7 ("123456789") MaxLen: 15 байт (127 бит) - обнаружение одинарных, двойных, тройных и всех нечетных ошибок */ const unsigned char Crc8Table[256] = { 0x00, 0x31, 0x62, 0x53, 0xC4, 0xF5, 0xA6, 0x97, 0xB9, 0x88, 0xDB, 0xEA, 0x7D, 0x4C, 0x1F, 0x2E, 0x43, 0x72, 0x21, 0x10, 0x87, 0xB6, 0xE5, 0xD4, 0xFA, 0xCB, 0x98, 0xA9, 0x3E, 0x0F, 0x5C, 0x6D, 0x86, 0xB7, 0xE4, 0xD5, 0x42, 0x73, 0x20, 0x11, 0x3F, 0x0E, 0x5D, 0x6C, 0xFB, 0xCA, 0x99, 0xA8, 0xC5, 0xF4, 0xA7, 0x96, 0x01, 0x30, 0x63, 0x52, 0x7C, 0x4D, 0x1E, 0x2F, 0xB8, 0x89, 0xDA, 0xEB, 0x3D, 0x0C, 0x5F, 0x6E, 0xF9, 0xC8, 0x9B, 0xAA, 0x84, 0xB5, 0xE6, 0xD7, 0x40, 0x71, 0x22, 0x13, 0x7E, 0x4F, 0x1C, 0x2D, 0xBA, 0x8B, 0xD8, 0xE9, 0xC7, 0xF6, 0xA5, 0x94, 0x03, 0x32, 0x61, 0x50, 0xBB, 0x8A, 0xD9, 0xE8, 0x7F, 0x4E, 0x1D, 0x2C, 0x02, 0x33, 0x60, 0x51, 0xC6, 0xF7, 0xA4, 0x95, 0xF8, 0xC9, 0x9A, 0xAB, 0x3C, 0x0D, 0x5E, 0x6F, 0x41, 0x70, 0x23, 0x12, 0x85, 0xB4, 0xE7, 0xD6, 0x7A, 0x4B, 0x18, 0x29, 0xBE, 0x8F, 0xDC, 0xED, 0xC3, 0xF2, 0xA1, 0x90, 0x07, 0x36, 0x65, 0x54, 0x39, 0x08, 0x5B, 0x6A, 0xFD, 0xCC, 0x9F, 0xAE, 0x80, 0xB1, 0xE2, 0xD3, 0x44, 0x75, 0x26, 0x17, 0xFC, 0xCD, 0x9E, 0xAF, 0x38, 0x09, 0x5A, 0x6B, 0x45, 0x74, 0x27, 0x16, 0x81, 0xB0, 0xE3, 0xD2, 0xBF, 0x8E, 0xDD, 0xEC, 0x7B, 0x4A, 0x19, 0x28, 0x06, 0x37, 0x64, 0x55, 0xC2, 0xF3, 0xA0, 0x91, 0x47, 0x76, 0x25, 0x14, 0x83, 0xB2, 0xE1, 0xD0, 0xFE, 0xCF, 0x9C, 0xAD, 0x3A, 0x0B, 0x58, 0x69, 0x04, 0x35, 0x66, 0x57, 0xC0, 0xF1, 0xA2, 0x93, 0xBD, 0x8C, 0xDF, 0xEE, 0x79, 0x48, 0x1B, 0x2A, 0xC1, 0xF0, 0xA3, 0x92, 0x05, 0x34, 0x67, 0x56, 0x78, 0x49, 0x1A, 0x2B, 0xBC, 0x8D, 0xDE, 0xEF, 0x82, 0xB3, 0xE0, 0xD1, 0x46, 0x77, 0x24, 0x15, 0x3B, 0x0A, 0x59, 0x68, 0xFF, 0xCE, 0x9D, 0xAC }; unsigned char Crc8(unsigned char *pcBlock, unsigned char len) { unsigned char crc = 0xFF; while (len--) crc = Crc8Table[crc ^ *pcBlock++]; return crc; }

мой лог отправитель. BUF: 5A 64 F9 41 4D 02 00 00 BB AE 00 00 52 00 00 00 crc: 82. 589 44731 31.17. Отправлено пакетов: 3 получатель. BUF: 5A 64 F9 41 4D 02 00 00 BB AE 00 00 52 00 00 00 crc: 23 . 589 44731 31.17. Принято пакетов: 3

Передавайте первый байт размер пакета. Организуйте побайтовый прием и будет вам счастье. А crc лучше таблично считать. Самый быстрый код по времени.

принял, опробую

наверно да, избавлюсь от контрольной в пакете и буду просто передавать перед пакетом отдельно контрольную. спасибо за помощь и внимание

protobuf почти все эти проблемы решает.

Хотя если формат пакета один, то смысла может не иметь, но зато позволит легко расширить.

Я кажись разгадал в чем проблема. Самое интересное в вырванивании структуры struct Str { float val_f; // 4 байта int val_i; // 4 байта int val_l; // 4 байта uint8_t crc; // 1 байт, но выравнивается до 4 байта }; sizeof(buf) = 16 sizeof(buf.crc) = 1 У отправителя myCrc.add((uint8_t *)&buf, sizeof(buf) - sizeof(buf.crc)); buf.crc = myCrc.getCRC(); хеш считается 15 байт, а не 12 байт. Поле buf.crc может быть мусором.

Почти правильно разгадал. Вот правильная версия. Возможно перед отправкой поле crc имеет 0. Когда считаешь хеш, то 3 байта из 4 от поля crc тоже считаются. На приеме crc уже не пустой и когда считывается хеш, то 3 байта поля crc уже с другими значениями. Вот поэтому у тебя crc разные

Я кажись разгадал в чем проблема. Самое интересное в вырванивании структуры struct Str { float val_f; // 4 байта int val_i; // 4 байта int val_l; // 4 байта uint8_t crc; // 1 байт, но выравнивается до 4 байта }; sizeof(buf) = 16 sizeof(buf.crc) = 1 У отправителя myCrc.add((uint8_t *)&buf, sizeof(buf) - sizeof(buf.crc)); buf.crc = myCrc.getCRC(); хеш считается 15 байт, а не 12 байт. Поле buf.crc может быть мусором.

Ещё раз, protobuf ))) Или struct _point { int x; int y; double time; } attribute((packed)) point;

Ещё раз, protobuf ))) Или struct _point { int x; int y; double time; } attribute((packed)) point;

Мне просто было интересно почему так у человека странно работало) Таки да, протобуф решает проблемы с выравниванием и проблемы разных архитектур. А то на одном устройстве int 4 байта, на другом int 8 байт

Я кажись разгадал в чем проблема. Самое интересное в вырванивании структуры struct Str { float val_f; // 4 байта int val_i; // 4 байта int val_l; // 4 байта uint8_t crc; // 1 байт, но выравнивается до 4 байта }; sizeof(buf) = 16 sizeof(buf.crc) = 1 У отправителя myCrc.add((uint8_t *)&buf, sizeof(buf) - sizeof(buf.crc)); buf.crc = myCrc.getCRC(); хеш считается 15 байт, а не 12 байт. Поле buf.crc может быть мусором.

Кстати нет. Если little-endian

Кстати нет. Если little-endian

м? Имеется ввиду допустим на ардуине int - 2 байта, на esp32 int - 4 байта. Протобуф это вывозит, нежели самому структурами Не увидел на какое сообщение был ответ

И вообще, crc в структуре делать нечего, она к данным не имеет отношения. Это уровень канала.

Кстати нет. Если little-endian

Ну смотри. Вот структура перед отправкой до подсчета хеша 5A 64 F9 41 4D 02 00 00 BB AE 00 00 00 00 00 00 Обрати внимание на 4 последних байта, они нули. Считаем хеш 15 байт. Т.е. хеш всех байтов, кроме последнего. Записываем в структуру хеш. Вот структура перед отправкой. 5A 64 F9 41 4D 02 00 00 BB AE 00 00 52 00 00 00 У получателя будет считаться хеш 15 байт с уже измененным байтом : 5A 64 F9 41 4D 02 00 00 BB AE 00 00 52 00 00 00 И это little endian

Так то да. Поэтому CRC нечего делать в данных.

Оно вообще считается на буфере, после сериализации.

да

всё именно так и оказалось

вы были правы

спасибо за помощь!

т.е. CRC считалось с учётом CRC? :)

т.е. crc считалось в 12 байт у отправителя, а 15 у принимающей

я не так использовал sizeof для вывода в консоль размера массива изхначально

и да, использовал протобуф

Ещё раз, protobuf ))) Или struct _point { int x; int y; double time; } attribute((packed)) point;

packed лучше не использовать без надобности - unaligned access на некоторых процессорах может приводить к падению...

packed лучше не использовать без надобности - unaligned access на некоторых процессорах может приводить к падению...

По моему, почти всегда будет.

packed лучше не использовать без надобности - unaligned access на некоторых процессорах может приводить к падению...

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

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

это почти всегда, но это не самое страшное

лучше в таких случаях использовать attribute((aligned)) для каждого поля структуры - да, это много писанины...

а для crc в конце есть offsetof

Ой, столько интересного пропустил откручивая гайки

Боюсь тут на таком (lua) никто не сочиняет. Не проще поставить Arduino IDE, загрузить нужный пакет для вашей платы и посмотрев примеры сочинять своё. "Сначала на червя, потом плавно переходим на блесну, а потом уж ... другие способы ловли."

))).. боюсь так и прийдется наверно делать...

Парни кто какие стабилизаторы использует на питание esp32

Я вчера там целый список привёл импульсных пин совместимых, если нужно питать от напряжения больше 5В. Если нужно от 5.5 и ниже, я бы привёл другой список.