Go Down

Topic: Proper method of receiving UART packet data far exceeding RX buffer size? (Read 283 times) previous topic - next topic

Juraj


Rob_Mohr

has the device a flow control pin?
No, it does not.  It implements TX @ 3.3V signal level, VCC @ 5VDC and GND.  It has a RX pin, however that is only used to change debugging modes on the prototype.  No handshaking possible.

Rob

Rob_Mohr

I've changed the indexing a bit and added a debug print at the end. How's this:

...
@Blackfin BINGO!  With debugging enabled it gets a bad tail every few passes, however with debugging disabled it flies right through every pass without a glitch.  I think the print's are slowing it enough that it's missing some characters in the RX buffer or something.  Since its aligning properly, I don't need the debugs now anyhow, so that's pretty moot!

The only thing I had to change to get it running was to modify the following lines to read as shown:

Code: [Select]

    if( Serial1.available() > 0 )
    {
        while( Serial1.available() )
        {
            cByte = Serial1.read();


I can finally take time now to wrap my head around the other subsystems.  I suspect now that RingBuffer.h has been returned to its default state the I2C libraries should play nice with the rest of my code.

I appreciate the advice and code examples greatly.  I'll let you know how the whole project turns out.

Rob

Robin2

The data will be used to fine tune algorithms associated with the sensor.
That suggests that the firmware on the sensor can be modified. If so, re-write the debug-data-sending to be more Arduino friendly - for example send the data in manageable chunks.

I have no experience with a DUE.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Rob_Mohr

@Robin2

If I had access to the firmware, I would do that.  The prototype sensor is being developed by another company.  I plan to use it eventually, and it is being optimized for the use I have for it, but ultimately the firmware is outside my control.

The Due has a lot of SRAM and flash available, however I'm finding that some libraries are a bit dodgy on it.  It represents a fairly small sliver of the Arduino ecosystem, so I don't think it has had the degree of peer review the other boards have had.

Rob

Paul_KD7HB

Have you determined that your program can process the data faster than it arrives?

If this was my project, I would program a circular buffer to store the data bytes taken from the serial buffer and when the end of the message is reached, begin to process the message data. The circular buffer may need to be 2X your message length.

Paul

Rob_Mohr

@Paul_KD7HB Yes, the state machine implementation that @Blackfin suggested and provided code for is plenty fast enough to capture 3156 byte data packets, and that has been verified. 

I'll do the processing to get a complete packet sent to the modem and SD card before going back to the state machine to grab another packet.  There will be a few missed packets while I'm sending to the modem and SD-CARD, however that is not critical.  I only need the 10 packets collected each 10 minute interval to be close to each other temporally, they do not have to be sequential.

Rob

Paul_KD7HB

This is your FIRST mention of writing the data to an SD card. Have you done a timing test to see how long it takes to write your data to an SD card? Pretty important test!

Paul

Rob_Mohr

This is your FIRST mention of writing the data to an SD card. Have you done a timing test to see how long it takes to write your data to an SD card? Pretty important test!

Paul

Rob_Mohr

@Paul_KD7HB,

Yes, I've created code for all of the sub-components.  Time to write to the SD-card is not critical as it can occur after reading the data from the sensor, and after having turned the sensor and the modem off, thereby conserving power as the SD-card can take a bit by itself.

Rob

Go Up