Problems with SDK code and 16-bit processors
I am finding several source-files from the SDK with lines like the following. For example, from the tcu_api/tcu_api_host.c file at line 39:
msg_len = buf;
msg_len |= (buf << 8);
msg_len |= (buf << 16);
The above is a problem because msg_len is an int, but the left-shift by 16 assumes an integer-size of greater than 16-bits. Anyone with 16-bit controllers (like me) are in for some real trouble. That's just the simple-case. Other code that might result in values greater than 16 bits would be hard to find.
Do I need to inspect all the source files line-by-line? I think this is/could be a serious problem. Am I missing something?
I am sorry for the late reply.
I think most parts of the SDK use <stdint.h> types like uint32_t which should work correctly using a 16-bit host processor.
If some parts use int and implicitly assume that it is 32 bit as well, then I would say that it is a valid problem in the SDK.
I will forward this problem to the Bluetooth SDK developers from Toshiba.
A quick look through the SDK shows that int is used for:
- counter variables
- return codes
- bool values
In tcu_api_host.c it is used for the bit shifting you mentioned in your post.
The same is true in uart_store_value_isr() in uart_api.c
So I would say if you look at these places first, then there is a good chance to get it going.
Can you please tell me more about your system setup? Which 16-bit processor are you going to use?
In the code I quoted, msg_len is declared as an int, not a uint32_t, and on a 16-bit processor, those three lines of code, and any others declared similarly, won't work. They will execute, but the result can be wrong.
I am (will be) using a Microchip dsPIC33E, but right now, I'm writing a test-app on the PC to talk to one of the EVAL_PAN1026 Evaluation Kit dongles. This lets me learn how to make the PAN1026 do what I need it to do before I put everything into the PIC firmware. Since I am currently working on a PC, I am not concerned about those lines of code at the moment, but...
What I learn and need from this test-app will be applied (SDK source files) to the firmware for the Microchip PIC, and then those lines of code will indeed be a problem.
I was just pointing them out to you, and anyone else that might be operating with 16-bit processors.
Yes, I understood the problem with the msg_len and already got feedback from the Bluetooth SDK developers at Toshiba that they will be looking at this problem and fix it.
They could not give an schedule for this yet, maybe it will be already in the next release.
Please keep an eye on the release notes of the SDK.