RING BUFFER 18LF4620 Oshonsoft

[camerart]

You can just use the output part of the ring buffer as the data input for your original receive and parse routine.

Any time the buffer output pointer is different to the input pointer, get the value at the output point and treat it as you originally treated the received serial byte, loading it in to a linear buffer.


Your original problem was the processing or parsing time of a full buffer, if I remember right? It had to be completed between two interrupts.

Adding a small circular buffer ( eg. 8 or 16 bytes) gives you almost the time it would take the circular buffer to fill, to parse and do whatever you want with a complete received string, before timing matters again.

After that is complete and the main loop continues, it can rapidly move the content from the circular buffer and "catch up" with data coming in.

Hi R,
I think you're correct, but I wan't sure, well done. Now the INTERRUPT is as mentioned, 80uS, so much smaller.

I've been using what I've learnt plus the smaller INTERRUPT to repair the original LINEAR BUFFER, which I'll try first. At the moment I'm stuck on CSV's, but may be able to figure it out.

I'll have to re-read this post, later, as you appear to suggest that a RING BUFFER can be smaller that a LINEAR one, and be better.
Thanks,
C.

 

[rjenkinsgb]

Imagine two people each doing different tasks on a production line:

The first completes and hands on the item on an exact fixed schedule; the second can usually do his part in less time, but occasionally more.

Passing the items direct one to the other, the first guy occasionally drops the item to where the second guys hand should! be to catch it, but he's not ready and the item gets lost.

That's your existing situation, with data at a fixed interval from the serial port, and occasionally a delay while you parse the linear buffer content.

The small ring buffer will acting as a FIFO, a first-in, first-out store, between the two.

It's like putting a small ramp shute between the first guy to the second - the items can stack occasionally until the second guy catches up, so nothing lost when the two different timings do not match up.

The two existing parts, interrupt input and linear buffer processing, still do exactly what they did before, just without any critical timing between them.

 

[camerart]

Imagine two people each doing different tasks on a production line:

The first completes and hands on the item on an exact fixed schedule; the second can usually do his part in less time, but occasionally more.

Passing the items direct one to the other, the first guy occasionally drops the item to where the second guys hand should! be to catch it, but he's not ready and the item gets lost.

That's your existing situation, with data at a fixed interval from the serial port, and occasionally a delay while you parse the linear buffer content.

The small ring buffer will acting as a FIFO, a first-in, first-out store, between the two.

It's like putting a small ramp shute between the first guy to the second - the items can stack occasionally until the second guy catches up, so nothing lost when the two different timings do not match up.

The two existing parts, interrupt input and linear buffer processing, still do exactly what they did before, just without any critical timing between them.

Hi R,
I follow the idea, but I am slow at programming, I'll come back to RING BUFFERS later.
Thanks.
C.

 

[camerart]

Hi,
I been trying to make a LINEAR INTERRUPT?PARSE program first, rather frustratingly! I had 3x goes so far, and hope I'm improving each time.
Here is the latest:

With 'correct' $Sentences, it appears to be ok, but I've had faults, with corrupt $Sentences. I'm not sure why?
EDIT: I've changed it slightly, and think it is working now. I would eppreciate any feedback for other simulators please.
C.

 

[camerart]

Hi,
#44 program slightly changed and may be woking now.

If it is, thanks. I hope to try to make a RING next.
C.