Строка 134: for (int i = 0; i < 54; i++) DATA[i + 41] = MULTIFRAME[i]; правильно, что копирует 54 байта, а не 55?

Строка в конце Serial.write(DATA, 161); передает 161, а не 162 байта, правильно? Зачем объявляли 162 байта?

Проверку на изменения может сделать так?
Перенести memcmp выше, а то получается, что оно постоянно вызывается.
Вообще по логике получается, что данные в DATA еще полностью не заполнились, а уже идет сравнение с DATA2 и если оно несовпадает, то идет отправка на планшет.
Надо вводить флаг, который будет разрешать/запрещать сравнение DATA с DATA2.

(millis() - time0) > 100 - некая задержка чтобы DATA успел заполнится, не совсем понял?

По порядку.
Да- 54 байта это правильно. Максимальная длина этого мультифрейм 9*6=54

162 объявлено с запасом. Тут тоже всё корректно.

С сравнением массивов согласен. Нужно убрать в if который возникает при приходе пакета и желательно только мне нужного. Над этим подумаю- спасибо. Можно уменьшить количество проверяемый информации, но тогда увеличится код. В каждом if пришедшего пакета проверять изменения для конкретного id. Тоесть сравнивать только те байты, которые он может изменять.

Про флаг подробнее можно?

Про задержку в 100мс. Сделана чтоб не грузить особо COM и планшет. Быстрее чем 10 раз в секунду мне данные не нужны.

Вот что имел в виду:
И вызывать это если ID совпал. Тоесть например:
Так должна ещё скорость увеличится.

А если узнать как сравнивать кусок массива, а не весь, то будет ещё быстрее.
Ну скажем байты с 10 по 15. И передавать эти значения в функцию CompareOut(15,20);

Данные которые складываются в массив DATA приходят же не за одно сообщение, так вот в момент когда приходит первое сообщение нужно запретить сравнение массивов. Когда приходит последнее сообщение и массив DATA завершает свое формирование, сравнение можно разрешить. Для этого нужен флаг запрет/разрешение.
Можно самому написать сравнение, тапример так:
data1, data2 - массивы, first и last начальный и конечный индексы массивов для сравнения (начиная с 0).

А вот нету конечного сообщения. Это всё в динамике отображается. Тоесть нужно отображать любое изменение массива за период 100мс


А самописное сравнение с for будет ли быстрее memcmp?

ХЗ, а почему бы ему тормозить? ))


Экран же понимает, когда можно начинать выводить. Я не очень представляю как выглядят данные с которыми ты работаешь, поэтому мне сложно что-то конкретное советовать.

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

xmetal
Спасибо за пример сравнения.

По поводу данных.
Ведройд не сохраняет в себе ни каких значений, он тупо считает и выводит то, что на него приходит.

Ардуина кладёт в массив данные с интересующих меня ID, данные по шине идут естественно один пакет за раз, а мне иногда нужны данные из разных пакетов, так что дуина их складывает в массив, а потом все изменения выкидывает в порт.
Тоесть выдаёт всё за раз.

Вот что в итоге сотворил.
При каждом приходе интересующего меня ID данные складываются в массив и пишется флаг Compare = true;
Ну а дальше проверяется в основном цикле вышли ли 100мс и состояние флага.
И если вышли и флаг true, то сравниваются массивы и если не равны, то выдаём данные в порт и записываем данные из массива 1 в массив 2 (тоесть с тем, с которым в дальнейшем будем сравнивать).
Так по идеи должно работать ещё быстрее

Здравствуйте уми мира этого.
Вот начал читать ваш топик і понял што ето то што мне нужно. В обшех чертах у меня идея очень похожея, заменить монохромний дисплей на 7inch андроид, но рендерить на КОDI(XBMC). Почему сделать интерфейс для KODI? потому што я python developer и мне попросту проще так.
Итак мне уже идут CAN шилд на MCP2515 и MAX3053ЕСА и у меня Ситроен с-elysee с штатной RD45 магнитолой. Читал про небходимость утилити снифить і рендерить CAN коди (идея про 3 колонки), думал што навероє удобно подключить raspberry pi по SPI и уже там снифить и рендерить, єсли вам идея нравитса могу помочь в етом.
В общем ребята спасибо что развиваите єту тему, я хотел би присоєдинитса к вам, но сами понимаите, ратота, жена - отнимають много в ремени у меня. Но я буду старатса не отставать).
Когда мне все прийдет я залю скетч и посмотрю как ето работаєт у меня, если што задам вопроси.

P.S. я сам из Украини и руский не мой родной язик, так што простите за ошибки в написании

Вот! Я и хочу сказать, что когда дуина начинает складывать данные из разных пакетов, нельзя разрешать сравнение массивов. Разрешать нужно только когда в массив положился последний кусок данных. Возможно в тестах на столе все данные успевали собраться за 100 мс, так как нету другого трафика в кан шине. А в реальных условиях какое-то сообщение притормозилось, таймер вышел, данные пошли в планшет и получили кашу.

xmetal Стоп- стоп!
У нас есть цикл, в нём есть определение приёма пакета и если приняли, то куча ифов.
На данный момент заменено на switch.
Задетектили приём пакета, пошли вниз по коду, если есть, то изменили что-то в массиве, если нет, то просто сделали пробежку сверху вниз, сравнили массивы и побежали на следующий круг.
В этом цикле как бы не может быть много пакетов.
Если приняли нужный нам пакет, то сравнив у нас естественно массивы не совпали и мы выдали весь пакет целиком в порт, не важно что записали всего один бит, передали всё равно 161 байт. Ну и в буферный масив перекинули данные основного массива чтоб потом сравнивать дальше.

Так что складывание данных только из одного пакета за цикл и сравнение тоже.

Сейчас оптимизировал это свитчем и сделал сравнение только если пришёл интересующий меня пакет. В порт лететь стало меньше. Проблема ушла с кашей.

То что не ловит переодически пакеты это уже где-то с железом косяк. Даже на минимальном скетче есть потери пакетов (просто когда пакеты в консоль выводятся). После пропайки TJA, укорочения хвоста витухи в машине стало полутчше,но всё равно теряет. Видимо вместо дисплея в разъём втыкать нужно чтоб лишних проводов и скруток не было.

На этой недели проверю.