I'm using DSPS v 5.150.2 to communicate between a sensor and a Windows 10 PC.
我所拥有的问题是，在传输数据几秒钟后，DSPS程序将在User_PeriPH_Push上调用Assert_Warning（0）。我相信这意味着读取缓冲区溢出。
我的同时将传感器输出到UART（BLE）和USB（PC）以比较数据，似乎它完全相同。传感器没有流量控制，但在收到时，数据似乎会发出，所以我没有看到为什么要填满了缓冲区。
我能够降低传感器执行读数的速率，这会减慢数据流，但最终仍将崩溃。唯一似乎停止崩溃的唯一就是将波特率降低到115200至19200年或更低，但这会导致丢包。
Any idea on how to fix this without slowing down the data rate? Perhaps I can empty the buffer every time it fills up?
Thanks.
Keywords:
Device:
I've also found that the bluetooth chip is outputting only the first 27 characters of the data packet, but the packets are 45 characters in length. This might be part of the problem
Hi RoninKreinin,
So you have connected the DSPS peripheral to a sensor that outputs measurements using a UART interface with no flow control, so i suppose that you are no using sleep mode, are my assumptions correct ? Regarding that the bluetooth chip outputs only the 27 characters, i dont quite get that, the device notifies the central with data, the length of the characteristic is 160 bytes in the DSPS and in order for the link to be able to support that it will execute an MTU exchange procedure, that means that the device will send over to the other side of the link in one connection interval as many packets as the central allows him (that depends on the central) and each packet will have 20 bytes of payload if its the first packet in the current connection interval and the rest packets will have 27 bytes of payload.
In your case yes, the periph_to_ble_buffer at some point it will get an indication that 8 bytes are available from the UART FIFO but when the code will try to fit those data in the buffer there will be no room to fit the data so what you will get will be that ASSERTION. Now i dont think that all the data that the device has received from the UART are transfered on the other side, the last data should be missing. Regarding how to fix this, if you dont have a flow control scheme then you wont be able to control the incoming data from the sensor and you are going to loose data and the DSPS isn't designed to operate without flow control, if you think that flashing the buffers will help you can try re-initializing the read and write indexes but i dont think that this is valid solution, since as mentioned DSPS is not able to operate without flow control, if an overflow occurs you will have to find a way to re-initialize the system and this will mean offcourse that you will loose data.
Thanks MT_dialog
对不起,我没有解释27个字符problem well. The problem seems to be that the da14580 cannot write all of the data to memory before the next data package is received. If I change the sampling rate, the number of characters that will be saved to memory will change accordingly, so the 27 was just a value for the specific sampling rate I was using.
The data that the sensor sends looks like this:
Haaaa BBBB CCCC DDDD EEEE FFFF GGGG HHHH IIII
Laaaa BBBB CCCC DDDD EEEE FFFF GGGG HHHH IIII
where it alternates from H to L.
The data received over bluetooth would look something like:
HAAAA BBBB CCCC DDDD EEEE FLAAAA BBBB CCCC DDDD EEEE .... and so on.
So the first package would be cut off at a certain number of characters and the next one would be sent.
If I lower the sampling rate low enough, the entire package will be sent, but the rate is too low for the application that I need. Also the buffer would still overflow after around 5 minutes of running.
As for flow control, I will see if that is possible to add to the sensor
Thanks
Hi RoniKreinin,
Like i said, the device along with the DSPS fw operates properly using flow control, the fact that the device isn't able to get all the data that the sensor sends is most probably because the sending of the data overlaps with BLE interrupts so the 580 isn't able to cope with the BLE and the UART interaction, you need flow control in order to stop data transmition on the other side when needed.
Thanks MT_dialog