Hello Dialog,
Could you clarify for me the role of the mempcy command in the sps service? I am following the program from the point when it receives uart data to when the data gets sent away. In app_sps_scheduler.c on line 221 it says
memcpy((buffer->data_ptr)+buffer->writeIdx, wrdata, writeAmount);
What exactly does this do and how does it work? Does this statement update the TX characteristic value AND send the message to the client that it's been updates (via notify permission)?
Hello, Not sure if you ever found an answer to this. I am trying to follow the SPS code as well, my desire is to use the UART to receive 13 bytes (my packet), then , and only then, initiate a notify. And In the other direction I want to do the same, send 13 bytes (my packet) over BLE, and then (and only then) when that packet is received, initiate a UART Tx to my device. Presently I am able to transmit/receive my 13 byte packet in both directions, however, when multiple packets are sent, eventually things fall apart on the UART to BLE side. I receive a notify, respond to it, find that there are only 3 (or so) bytes, then a short time later receive ANOTHER notify that there are the remaining 10 bytes. In my micro (that is connected to the DA14580's UART ) I am transmitting the entire 13 bytes at once, so I am certain that this is not causing the problem. The problem seems to be that the SPS sends a notify as soon as it gets a single byte, and the only reason it is working most of the time is due to the latency that happens on the client side after the notify. If there is a way to do this, such as with the #define TX_WAIT_LEVEL (74) //3 packets (20 + 2*27) in the app_sps_scheduler.h file, I would really appreciate some insight. Thanks.