отследить изменение переменной. Опции

[Jenya7]

есть пакет с данными uint8_t packet[20] . переменная uint32_t занимает 4 байта. соответственно если я хочу посмотреть изменилась ли переменная в следующей посылке я могу сделать так

Код

if (new_packet[0] != old_packet[0] || new_packet[1] != old_packet[1] || new_packet[2] != old_packet[2] || new_packet[3] != old_packet[3])

или так

Код

if(memcmp(new_packet, old_packet, 4) != 0)

вопрос какой способ быстрее?

[Dog Pawlowa]

Ну, для начала желательно знать, что за ядро.
То, что предложил ув. zltigo, имеет смысл только для 32-битного ядра.

[Jenya7]

Ну, для начала желательно знать, что за ядро.
То, что предложил ув. zltigo, имеет смысл только для 32-битного ядра.

это Cortex-M3

Нет, разное происходит. При таком варианте у вас может быть проблема с невыровненным доступом.
Идеальный вариант - объявить упакованную структуру. которая разложит байты пакета согласно логического содержания, ну а дальше оперировать полями этой структуры.

Код

__packed struct packet {
       ...
       uint32_t ref;
       ...
   };
  
   struct packet *old_packet;
   struct packet *new_packet;
  
   if (old_packet->ref != new_packet-<ref)
   {
       do_stuff();
   }

__packed зависит от вашего компилятора.

функция принимает массив uint8_t . к тому же что может быть невыравненно в массиве?
ок. допустим. все равно я думаю это будут те же операции на уровне ассемблера.

Сообщение отредактировал Jenya7 - Dec 15 2015, 11:40

[msalov]

функция принимает массив uint8_t . к тому же что может быть невыравненно в массиве?

Адрес 0x0F сгодится для указателя на uint8_t, но не сгодится для uint32_t.

ок. допустим. все равно я думаю это будут те же операции на уровне ассемблера.

Будущему вам будет проще читать

Код

if (old_packet->ref != new_packet-<ref)

нежели

Код

if (new_packet[0] != old_packet[0] || new_packet[1] != old_packet[1] || new_packet[2] != old_packet[2] || new_packet[3] != old_packet[3])

да и ошибку допустить будет сложнее в первом случае, вот и вся премудрость.

[Jenya7]

Адрес 0x0F сгодится для указателя на uint8_t, но не сгодится для uint32_t.

допустим первая переменная – uint8_t , вторая – uint8_t , третья – uint32_t тогда
if(*((uint32_t*)&new_packet[2]) != *((uint32_t*)&old_packet[2]))
и так далее.

[zltigo]

допустим первая переменная – uint8_t , вторая – uint8_t , третья – uint32_t тогда
if(*((uint32_t*)&new_packet[2]) != *((uint32_t*)&old_packet[2]))
и так далее.

Нет, это фигня. В общем случае НЕЛЬЗЯ.

так какой метод МАКСИМАЛЬНО хорош по вашему мнению?
меня интересует СКОРОСТЬ исполнения.

Тот о котором написано, что так надо делать ВСЕГДА. Что можно было не понять?

[Jenya7]

Нет, это фигня. В общем случае НЕЛЬЗЯ.

Тот о котором написано, что так надо делать ВСЕГДА. Что можно было не понять?

а как не фигня?
какая структура. у меня функция принимает массив uint8_t.

Код

tBleStatus aci_gatt_update_char_value(uint16_t servHandle,
                      uint16_t charHandle,
                      uint8_t charValOffset,
                      uint8_t charValueLen,  
                      const uint8_t *charValue)

вот сюда - uint8_t *charValue - я должен передать свой пакет.
и для сравнения я получаю его как uint8_t *charValue а не как структуру

Сообщение отредактировал Herz - Dec 17 2015, 11:58

[zltigo]

какая структура. у меня функция принимает массив uint8_t.

1) Не массив, а УКАЗАТЕЛЬ на массив
2) Преобразовать этот указатель в указатель на пакованную структкру и работать с ЭЛЕМЕНТАМИ этой сруктуры.
3) Что Вас удивило со структурой, если поняли, что преобразовывать указатель на массив в указатель на long можно?

[Jenya7]

1) Не массив, а УКАЗАТЕЛЬ на массив
2) Преобразовать этот указатель в указатель на пакованную структкру и работать с ЭЛЕМЕНТАМИ этой сруктуры.
3) Что Вас удивило со структурой, если поняли, что преобразовывать указатель на массив в указатель на long можно?

и все это для того чтобы сравнить неколько переменных? мне кажется быстрее уж сделать тем же memcmp

[zltigo]

и все это для того чтобы сравнить неколько переменных? мне кажется быстрее уж сделать тем же memcmp

Ну и каша у Вас с голове . Рано Вам реальным программирванием заниматься если не понимаете разницы между преобразованиями типов данных и работой данными. "Все это" НИ ОДНОГО БИТА КОДА НЕ ДОБАВЛЯЕТ. "Вcе это" только ИНСТУКЦИИ компилятору, как ему МАКСИМАЛЬНО эффективно сделать работу при ОНОВРЕМЕННОМ обеспечении читаемомти человеком.