Hi, I have been using the nRF8001 Arduino SDK with nRF8001 chip. I wanted to set the data for the different services I'm using and thought I would go ahead and use the services.c file generated by nRFGO Studio. But the file that nRFGO Studio generates (and I have the latest 1.16.1 version) won't work with the Arduino SDK. The function calls in services.c to lib_aci.h functions are wrong. Is there any version of nRFGO Studio that could be used to generate a working services.c file?
Runar & Star Destroyer, Thank you for your answers. I understand that the Arduino version of the ACI library uses a circular queue to allow multiple nRF8001 commands to be saved on the local processor and sent out only as the radio is ready to handle more commands. That is good but does not replace the old services_update_pipes interface in applications like mine that support multiple services between my device and the remote device. Even with simple devices and few services the queue approach will often have problems. The reason is that you can only make the queue so big in the hal_aci_tl.cpp file in the BLE library directory. Each queue entry takes 30-40 bytes so large queues can take a lot of bytes. And the default queue size as delivered is only 2 buffers. And once the queue is full with commands waiting to be sent all later commands fail until the radio accepts more data and the queue empties some.
I notice your examples seem to assume commands will always be accepted and queued up. But I have found that in real use things can "get dropped on the floor" because of full queue conditions. I need reliable operation in my application so can't allow commands to silently disappear. What I liked about the services.c implementation of sending data is that it allowed things to be saved until they could be sent successfully and made it explicit with the "is_freshest" flags how you wanted overrun conditions handled. I edited the services.c file that nRFGO Studio generates to work with the Arduino version of lib_aci and think I will use it for my application. Maybe others can make the hal_aci_tl command queue big enough to never have data get dropped. Or maybe their applications can handle dropped data. But for me I think the mix of the queue's and services.c approach is best.
I would think it would be nice to add another format option to nRFGO Studio so it could generate a services.c (well, actually, services.cpp) file that could work with the Arduino SDK. It wouldn't take many changes to the code generator. And then people could have a choice of how they wanted to handle their communication with the nRF8001. But that is just my suggestion. I will stick with my hand edited file for now so this issue could be closed I guess.
Runar & Star Destroyer, Thank you for your answers. I understand that the Arduino version of the ACI library uses a circular queue to allow multiple nRF8001 commands to be saved on the local processor and sent out only as the radio is ready to handle more commands. That is good but does not replace the old services_update_pipes interface in applications like mine that support multiple services between my device and the remote device. Even with simple devices and few services the queue approach will often have problems. The reason is that you can only make the queue so big in the hal_aci_tl.cpp file in the BLE library directory. Each queue entry takes 30-40 bytes so large queues can take a lot of bytes. And the default queue size as delivered is only 2 buffers. And once the queue is full with commands waiting to be sent all later commands fail until the radio accepts more data and the queue empties some.
I notice your examples seem to assume commands will always be accepted and queued up. But I have found that in real use things can "get dropped on the floor" because of full queue conditions. I need reliable operation in my application so can't allow commands to silently disappear. What I liked about the services.c implementation of sending data is that it allowed things to be saved until they could be sent successfully and made it explicit with the "is_freshest" flags how you wanted overrun conditions handled. I edited the services.c file that nRFGO Studio generates to work with the Arduino version of lib_aci and think I will use it for my application. Maybe others can make the hal_aci_tl command queue big enough to never have data get dropped. Or maybe their applications can handle dropped data. But for me I think the mix of the queue's and services.c approach is best.
I would think it would be nice to add another format option to nRFGO Studio so it could generate a services.c (well, actually, services.cpp) file that could work with the Arduino SDK. It wouldn't take many changes to the code generator. And then people could have a choice of how they wanted to handle their communication with the nRF8001. But that is just my suggestion. I will stick with my hand edited file for now so this issue could be closed I guess.
