CITROEN-ARDUINO

[xmetal]

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

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

Проверку на изменения может сделать так?

if (!digitalRead(9))
  {
    CAN.readMsgBuf(&len, buf);
    canId = CAN.getCanId();
.......................
.......................
  arrcmp = memcmp(DATA, DATA2, 161); // перенести сюда 
  }

  if ((millis() - time0) > 100 && arrcmp != 0){
    Serial.write(DATA, 161);
    memcpy(DATA2, DATA, 161);
    time0 = millis();  
  }

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

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

[T_r_D]

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

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

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

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

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

[T_r_D]

Вот что имел в виду:

PHP код:

void CompareOut(){
arrcmp = memcmp(DATA,DATA2,161);
} 


И вызывать это если ID совпал. Тоесть например:

PHP код:

          if(canId == 0x1E0)
          {
            bitWrite(DATA[21],0,bitRead(buf[0],5));
            bitWrite(DATA[21],1,bitRead(buf[0],2));
            bitWrite(DATA[21],2,bitRead(buf[1],7));
            bitWrite(DATA[21],3,bitRead(buf[2],5));
            bitWrite(DATA[21],4,bitRead(buf[3],7));
            bitWrite(DATA[21],5,bitRead(buf[4],5));
CompareOut();
          } 


Так должна ещё скорость увеличится.

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

[xmetal]

Данные которые складываются в массив DATA приходят же не за одно сообщение, так вот в момент когда приходит первое сообщение нужно запретить сравнение массивов. Когда приходит последнее сообщение и массив DATA завершает свое формирование, сравнение можно разрешить. Для этого нужен флаг запрет/разрешение.

Сообщение от T_r_D

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

Можно самому написать сравнение, тапример так:

PHP код:

byte compare(byte *data1, byte *data2, byte first, byte last) {
  for (byte i = first; i < last+1; i++) {
    if (data1[i] != data2[i]) {
      return 1; // если не равны, возвращаем 1
    }
  }
  return 0; // если равны, возвращаем 0
} 


data1, data2 - массивы, first и last начальный и конечный индексы массивов для сравнения (начиная с 0).

[T_r_D]

Сообщение от xmetal

Данные которые складываются в массив DATA приходят же не за одно сообщение, так вот в момент когда приходит первое сообщение нужно запретить сравнение массивов. Когда приходит последнее сообщение и массив DATA завершает свое формирование, сравнение можно разрешить. Для этого нужен флаг запрет/разрешение.

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


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

[xmetal]

Сообщение от T_r_D

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

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

Сообщение от T_r_D

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

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

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

[T_r_D]

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

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

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

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

PHP код:

if ((millis() - time0) > 100 && Compare){
arrcmp = memcmp(DATA,DATA2,161);
  if (arrcmp != 0)
  {
      Serial.write(DATA, 161); //41 + 54 +64
      memcpy(DATA2,DATA,161); //Присваиваем массиву DATA2 160 байт массива DATA
  }
time0 = millis();
Compare = false;
} 


Так по идеи должно работать ещё быстрее

[devova]

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

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

[xmetal]

Сообщение от T_r_D

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

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

[T_r_D]

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

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

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

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

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