This is a very simple implementation of the BD_ADDR::BD_ADDR(const char * address_string, BD_ADDR_TYPE address_type) constructor in BTstackLib.cpp.
It uses a six-step loop to set the indiviual bytes in the internal address field. It expects the input address_string to be a human readable, null-terminated, 17 char length string on the format "00:00:00:00:00:00\0" and uses strtoul() to convert the chars at the pointer into the byte value and then skip past the next ':' delimiter and repeat the process until the input string ends or a '\0' is found.
There are no checks or safeguards in this implementation and it can be considered a draft PR at the moment. It the input string is not exactly what is expected, the parsed result can in no way be guaranteed.
This is a very simple implementation of the `BD_ADDR::BD_ADDR(const char * address_string, BD_ADDR_TYPE address_type)` constructor in [`BTstackLib.cpp`](libraries/BTstackLib/src/BTstackLib.cpp#L398).
It uses a six-step loop to set the indiviual bytes in the internal `address` field. It expects the input `address_string` to be a human readable, null-terminated, 17 char length string on the format `"00:00:00:00:00:00\0"` and uses `strtoul()` to convert the chars at the pointer into the byte value and then skip past the next `':'` delimiter and repeat the process until the input string ends or a `'\0'` is found.
There are no checks or safeguards in this implementation and it can be considered a draft PR at the moment. It the input string is not exactly what is expected, the parsed result can in no way be guaranteed.
Thank you!
Well, my use case is that I have a list of BT addresses for some Ruuvi sensors in a config file (json) that is parsed at boot, then I run periodic scans for BLE devices to find these and read their data.
When I parse the file, I want to create BD_ADDR items to compare discoveries with and since I get the addresses as strings/char*'s from the ArduinoJson library, creating BD_ADDR items directly from a char* would be helpful. Right now, I am basically doing a parse from char* to uint8_t[] and then using the latter to create the BD_ADDR item that's later used when comparing the known address to the one coming in the BLE advertisement package.
I can look at updating or writing an example for this constructor if that would be a useful addition to the PR!
Thank you!
Well, my use case is that I have a list of BT addresses for some Ruuvi sensors in a config file (json) that is parsed at boot, then I run periodic scans for BLE devices to find these and read their data.
When I parse the file, I want to create `BD_ADDR` items to compare discoveries with and since I get the addresses as strings/`char*`'s from the ArduinoJson library, creating `BD_ADDR` items directly from a char* would be helpful. Right now, I am basically doing a parse from `char*` to `uint8_t[]` and then using the latter to create the `BD_ADDR` item that's later used when comparing the known address to the one coming in the BLE advertisement package.
I can look at updating or writing an example for this constructor if that would be a useful addition to the PR!
You could also check the return value of sscanf, and if it's not 6 then set everything to 0 or panic() or something.
I think you could replace this loop with a simple sscanf:
````
sscanf(address_string, "%d:%d:%d:%d:%d:%d", address, address + 1, address + 2, address + 3, address + 4, address + 5);
````
You could also check the return value of sscanf, and if it's not 6 then set everything to 0 or `panic()` or something.
Oh, that sounds like a better option, thank you! My C programming is very rusty since I haven't done it much since basically before 2010, the project I'm doing this for is my way of getting back into both C and embedded 😊
I'll try this out and update the PR once I've got something that feels stable!
Oh, that sounds like a better option, thank you! My C programming is very rusty since I haven't done it much since basically before 2010, the project I'm doing this for is my way of getting back into both C and embedded 😊
I'll try this out and update the PR once I've got something that feels stable!
Hello again! I've tried out using sscanf now but I'm not getting it to work, when I attach a picoprobe and run a debug I can see an isr_hardfault in the call stack:
I cannot understand why, I tried a simple program on replit doing just the sscanf and that works fine with what is supposed to be the exact same inputs and input types as well as output and output types and that works just as expected: https://replit.com/@janlindblom/tryingsscanfincpp?v=1#main.cpp
Hello again! I've tried out using `sscanf` now but I'm not getting it to work, when I attach a picoprobe and run a debug I can see an `isr_hardfault` in the call stack:
I cannot understand why, I tried a simple program on replit doing just the `sscanf` and that works fine with what is supposed to be the exact same inputs and input types as well as output and output types and that works just as expected: https://replit.com/@janlindblom/tryingsscanfincpp?v=1#main.cpp
I think the problem is I gave the wrong format string. You want to read a byte, not an int, so we want %hhd (half-half-int, aka byte on 32b CPUs), not %d. On x86 misaligned ints are OK so the code I suggested will run but will not do what you want. On the ARM, misaligned ints are a HW fault and will crash instead.
I think the problem is I gave the wrong format string. You want to read a byte, not an int, so we want `%hhd` (half-half-int, aka `byte` on 32b CPUs), not `%d`. On x86 misaligned ints are OK so the code I suggested will *run* but will not do what you want. On the ARM, misaligned ints are a HW fault and will *crash* instead.
Try
````
sscanf(address_string, "%hhd:%hhd:%hhd:%hhd:%hhd:%hhd", address, address + 1, address + 2, address + 3, address + 4, address + 5);
````
Oh that makes sense, thank you for indulging and helping me out!
I have a new version of the implementation now that I just tried and that seems like it's working, it would seem I had to use %hhx to find the hex representation of the byte. I'll make or update an example to show constructor in use too but it seems like it's working now!
Oh that makes sense, thank you for indulging and helping me out!
I have a new version of the implementation now that I just tried and that seems like it's working, it would seem I had to use `%hhx` to find the hex representation of the byte. I'll make or update an example to show constructor in use too but it seems like it's working now!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This is a very simple implementation of the
BD_ADDR::BD_ADDR(const char * address_string, BD_ADDR_TYPE address_type)constructor inBTstackLib.cpp.It uses a six-step loop to set the indiviual bytes in the internal
addressfield. It expects the inputaddress_stringto be a human readable, null-terminated, 17 char length string on the format"00:00:00:00:00:00\0"and usesstrtoul()to convert the chars at the pointer into the byte value and then skip past the next':'delimiter and repeat the process until the input string ends or a'\0'is found.There are no checks or safeguards in this implementation and it can be considered a draft PR at the moment. It the input string is not exactly what is expected, the parsed result can in no way be guaranteed.
Nice! Is there something specific you're implementing this for? An example (or editing a pre-existing example) might be helpful.
Thank you!
Well, my use case is that I have a list of BT addresses for some Ruuvi sensors in a config file (json) that is parsed at boot, then I run periodic scans for BLE devices to find these and read their data.
When I parse the file, I want to create
BD_ADDRitems to compare discoveries with and since I get the addresses as strings/char*'s from the ArduinoJson library, creatingBD_ADDRitems directly from a char* would be helpful. Right now, I am basically doing a parse fromchar*touint8_t[]and then using the latter to create theBD_ADDRitem that's later used when comparing the known address to the one coming in the BLE advertisement package.I can look at updating or writing an example for this constructor if that would be a useful addition to the PR!
I think you could replace this loop with a simple sscanf:
You could also check the return value of sscanf, and if it's not 6 then set everything to 0 or
panic()or something.Oh, that sounds like a better option, thank you! My C programming is very rusty since I haven't done it much since basically before 2010, the project I'm doing this for is my way of getting back into both C and embedded 😊
I'll try this out and update the PR once I've got something that feels stable!
Hello again! I've tried out using
sscanfnow but I'm not getting it to work, when I attach a picoprobe and run a debug I can see anisr_hardfaultin the call stack:I cannot understand why, I tried a simple program on replit doing just the
sscanfand that works fine with what is supposed to be the exact same inputs and input types as well as output and output types and that works just as expected: https://replit.com/@janlindblom/tryingsscanfincpp?v=1#main.cppI think the problem is I gave the wrong format string. You want to read a byte, not an int, so we want
%hhd(half-half-int, akabyteon 32b CPUs), not%d. On x86 misaligned ints are OK so the code I suggested will run but will not do what you want. On the ARM, misaligned ints are a HW fault and will crash instead.Try
Oh that makes sense, thank you for indulging and helping me out!
I have a new version of the implementation now that I just tried and that seems like it's working, it would seem I had to use
%hhxto find the hex representation of the byte. I'll make or update an example to show constructor in use too but it seems like it's working now!Thx!