More small print:
gs_hb_peripheral_address(initially set to the device addresses provided in the example described)
Yes indeed. This demo system does not discover suitable peers to communicate with, their addresses are hardwired into the code.
BLE_GAP_ADDR_TYPE_RANDOM_STATIC, {0x00, 0x0D, 0x80, 0x20, 0x12, 0xD9}
So the first challenge is to find out the MAC address of the eval-kit board that I’m using – an ancient V1.0 board. Fortunately my google phone has a program that scans the BLE ether.
So I plug it in and hey presto…
Nada! 🙁
Time to have a think…
—
So could this be an endian issue? I know that the ARM M0 is little endian, but the BLE addresses appear to be big-endian. Is there some issue here?
Poking around the internet I find this useful, though not very convincing message.
Hi Stephen,
Bluetooth low energy uses both Little- and Big-endian, so it might be confusing sometimes. For example, The service discovery protocol transfer multiple-byte fields in standard network byte order (Big Endian), while Multi-octet fields within the GATT Profile shall be sent least significant octet first (Little Endian). I am not sure why it is so.
Everything is of course specified in the Core Spec, where you can find more information.
Best Regards
So perhaps if I reverse the address bytes.
BLE_GAP_ADDR_TYPE_RANDOM_STATIC, {0xea, 0xaa, 0x2f, 0x36, 0x04, 0xc7}
/* BLE MAC 0xC704362FAAEA */
Try again…
Yay! “My” first program that compiles and talks to another program that I have compiled. A breakthrough moment :-/