I'm using DSPS v 5.150.2 to communicate between a sensor and a Windows 10 PC.
The problem I am having is that after a few seconds of transmitting data the DSPS program will call ASSERT_WARNING(0) at user_periph_push. I believe this means that the read buffer is overflowing.
我有这两个UART的传感器输出(祝福)d USB(PC) at the same time to compare the data, and it seems that it is exactly the same. The sensor doesn't have flow control but the data seems to be sent out as soon as it is received, so I don't see why the buffer is being filled up.
I am able to lower the rate at which the sensor performs readings, which slows down the data flow but it will still crash eventually. The only thing that seems to stop the crashing is lowering the baud rate from 115200 to 19200 or lower, but this causes packet loss.
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.
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