defragster
Senior Member+
Question: Is there a way to force Serial1 to on command empty the FIFO into the buffered data? .available() only returns bytes currently buffered. I am assuming this is behind the issue I see below.
Issue: I'm trying to get a timestamp to the start of data arriving ( from a GPS ). Given the baud rate on the port - and given there are 10 bit cycles per character at default N,8,1 - if I know how many bytes have been completed I can guess the start time using simple math of the bytes showing available referred to a running elapsedMicros timer tsGPS:
This is very accurate based on alternate solution info below as reference. But .available() only counts the bytes already pulled from the FIFO, so some messages are off by 1 to 4 whole characters.
I have a more accurate solution working well on T_3.6 at 180 or 240 MHz - but it is getting throttled and occasionally missing ( <1% failure based from other activity ) on the T_3.5 (or T_3.6) running at 120 MHz suggesting it is on the edge as written - or the interrupt is getting skipped even when I upped port priority. I started the CPU CycleCounter as a fast way to ignore intermediate RISING interrupts after the 5 Hz 100 byte message begins and it works reliably. So on the faster T_3.6 I am running both solutions side by side and that is where I see the bytes not accounted for in .availalble() calc above. The average error is 13 uS, but runs from 0 to an extreme of 84 uS - which would be 4 characters.
If I can get the first above solution working to include FIFO bytes it would involve way less system overhead as this serialrx_isr() fires multiple times during the 100 byte message, when I only need the first each 200 ms.
FAILED HACK: I thought calling the uart0_status_isr() would blindly empty all FIFO bytes, but that doesn't seem to be doing the trick as I expected - perhaps because it is under HighWater mark?
Thus the question: Is there a way to count the FIFO bytes - or to trigger the FIFO to empty into the buffered data to be counted? Or is there something else I am missing?
Issue: I'm trying to get a timestamp to the start of data arriving ( from a GPS ). Given the baud rate on the port - and given there are 10 bit cycles per character at default N,8,1 - if I know how many bytes have been completed I can guess the start time using simple math of the bytes showing available referred to a running elapsedMicros timer tsGPS:
Code:
#define GPS_BAUD 460800
GPS_Avail = Serial1.available();
GPS_ = tsGPS - ((1000000*( (GPS_Avail*10) ) ) / GPS_BAUD ); // converted to microseconds from current elapsedMicros tsGPS
This is very accurate based on alternate solution info below as reference. But .available() only counts the bytes already pulled from the FIFO, so some messages are off by 1 to 4 whole characters.
I have a more accurate solution working well on T_3.6 at 180 or 240 MHz - but it is getting throttled and occasionally missing ( <1% failure based from other activity ) on the T_3.5 (or T_3.6) running at 120 MHz suggesting it is on the edge as written - or the interrupt is getting skipped even when I upped port priority. I started the CPU CycleCounter as a fast way to ignore intermediate RISING interrupts after the 5 Hz 100 byte message begins and it works reliably. So on the faster T_3.6 I am running both solutions side by side and that is where I see the bytes not accounted for in .availalble() calc above. The average error is 13 uS, but runs from 0 to an extreme of 84 uS - which would be 4 characters.
Code:
// setup() // attachInterrupt(digitalPinToInterrupt( 9 ), GPS_serialrx_isr, RISING);
FASTRUN void GPS_serialrx_isr() {
static uint32_t tt;
static uint32_t xx = 0;
tt = ARM_DWT_CYCCNT;
if ( tt - xx > RxGapTime ) {
GPS_RX_time = tsGPS; // Start bit transition detected after 'idle' time // GPS_RX_Time = PartSec();
GPS_newData=1;
}
xx = tt;
}
If I can get the first above solution working to include FIFO bytes it would involve way less system overhead as this serialrx_isr() fires multiple times during the 100 byte message, when I only need the first each 200 ms.
FAILED HACK: I thought calling the uart0_status_isr() would blindly empty all FIFO bytes, but that doesn't seem to be doing the trick as I expected - perhaps because it is under HighWater mark?
Thus the question: Is there a way to count the FIFO bytes - or to trigger the FIFO to empty into the buffered data to be counted? Or is there something else I am missing?