コアのBluetooth 4.2ドキュメントhereでは、データの整合性(P2456)のCRCチェックについて説明しています。これは、以下の詳細:CRC Bluetooth低エネルギー4.2
4E 01 02 03 04 05 06 07 08 09
CRCを生産:6D D2、私が試してみました
以下の例では
異なるメソッドの数は、例を再現するように見えることはできません。誰でも上記のCRCを生成するためのサンプルコードを提供できますか?
コアのBluetooth 4.2ドキュメントhereでは、データの整合性(P2456)のCRCチェックについて説明しています。これは、以下の詳細:CRC Bluetooth低エネルギー4.2
4E 01 02 03 04 05 06 07 08 09
CRCを生産:6D D2、私が試してみました
以下の例では
異なるメソッドの数は、例を再現するように見えることはできません。誰でも上記のCRCを生成するためのサンプルコードを提供できますか?
これはBLEにどのように関係しているのか分かりませんが、ここではわかります。 この例はC++で書かれていますが、プログラミング言語に移植するのは簡単です。
unsigned short crc16(data_p, length)
char *data_p;
unsigned short length;
{
unsigned char i;
unsigned int data;
unsigned int crc;
crc = 0xffff;
if (length == 0)
return (~crc);
do {
for (i = 0 data = (unsigned int)0xff & *data_p++;
i < 8;
i++, data >>= 1) {
if ((crc & 0x0001)^(data & 0x0001))
crc = (crc >> 1)^POLY;
else
crc >>= 1;
}
} while (--length);
crc = ~crc;
data = crc;
crc = (crc << 8) | (data >> 8 & 0xFF);
return (crc);
}
あなたは一例で使用されるUAPが0x47
であるということであるドキュメントに記載されている例の重要な部分を残しました。 CRCはUAPで初期化する必要があります。 (奇妙なことに、ビットが反転し、上位バイトで、入ってくるデータビットに対して)
以下のコードはこの例を計算しています。結果はd26d
です。 CRCは最下位ビットが最初に送信されるため、6d d2
が送信されます。受信側では、同じCRCがCRCを使ってすべて計算され、結果はゼロになります。受信側が送信された内容を確認する方法です。
#include <stdio.h>
static unsigned crc_blue(unsigned char *payload, size_t len) {
unsigned crc = 0xe200; // UAP == 0x47
while (len--) {
crc ^= *payload++;
for (int k = 0; k < 8; k++)
crc = crc & 1 ? (crc >> 1)^0x8408 : crc >> 1;
}
return crc;
}
int main(void) {
unsigned char payload[] = {
0x4e, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09};
printf("%04x\n", crc_blue(payload, sizeof(payload)));
unsigned char recvd[] = {
0x4e, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x6d, 0xd2};
printf("%04x\n", crc_blue(recvd, sizeof(recvd)));
return 0;
}
あなたのコードは、そのデバイス用に適切にUAPを初期化する必要があります。
Um、構文エラー、不必要なステートメント、POLY定義の欠落、不正な初期化...、明らかにテストされていません。 –