Optimizing 256 byte ring buffer

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was just going to go with a 255 byte ring buffer so I could keep the size field in a simple uint8_t, but I though t there has to be a way to eliminate those if it is 255 then zero the pointer tests and of course moving a 256 sized ring buffer using uint8_t pointer (index) variables will do that.  The problem there is that to hold "256" items you need ot move to a uint16_t, but I want to optimize it to be as simple as possible.  I also thought about only using 255 spaces of the 256 size which solves the pointer reset issue and still would leave you with a uint8_t size variable.  I came up with this so far - I've not tested it yet, but no tests to reset pointers, no variable for size at all, and all 256 positions can be used.

 

//256 byte ringbuffer (no overflow ptr checking, all 256 positions used, no count variable)

//clear it
ringbuf_ptrin=0;
ringbuf_ptrout=0;
ringbuf_empty=1;


//is it empty?
if (ringbuf_empty)
  return;

//remove from it (assumes not empty)
AChar=ringbuf_buffer[ringbuf_ptrout];
ringbuf_ptrout++;
if (ringbuf_ptrout==ringbuf_ptrin)
  ringbuf_empty=1;


//is it full?
if (ringbuf_ptrout==ringbuf_ptrin && !ringbuf_empty)
  return;

//add to it (assumes not full)
ringbuf_buffer[ringbuf_ptrin]=AChar;
ringbuf_ptrin++;
ringbuf_empty=0;

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you looked at Dean's "lightweight ringbuffer" stuff? Implementations don't get a lot better than that!

 

I'm intrigued by the way - on an AVR what on earth might you be buffering that requires a s 256 byte deep buffer anyway? Normally you are using ring buffers on things like UART RX where 8/16/32 is usually more than sufficient.

 

(and, of course you use a "binary multiple" so that the wrap can be a simple & )

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Again, it would hlp to tell the quarry of this quest.  What are the parameters that must be reached for your buffering?   A large buffer, but no overflow checking?  That smells like a message system such as Modbus.  But then no ring buffer is needed; each message can start at the beginning.

 

If you are looking for the last few cycles, then what about the overhead of all the other code that you posted?

 

Anyway, based on past discussions the fastest is to have the buffer on a boundary that is a factor of 2, and a size that is a factor of 2.  Then the wrap operation is a simple ANDI with no comparison operations.  The 256 size obviates the need for that.  Keep your pointer in an index register pair.  That failing, have the "segment" of buffer (mod 256, remember?) and load it into _H and put the "offset" into _L.  Only increment _L and let it wrap.  This also simplfies write and read operations -- a single "segment" and dual "offsets".

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I saw a link to one of Dean's ringbuffers, but I don't think it was a lightweight variety perhaps.

 

My current evening project is use an ATMEGA640 as a I/O processor for a Z80 SBC I am building.  Part of what the AVR will do for the Z80 is transparently handle buffering and handshaking (none, software, or hardware).

 

Good idea about the multiple/simple and!

 

I want to keep the code size in the ISR's minimal.  I wonder if trying to code them in asm would be better.

Last Edited: Wed. Mar 27, 2019 - 12:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I meant this:

 

http://www.fourwalledcubicle.com...

 

(and no, there is no .c file - it's all there in the .h because it's all "static inline")

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
...based on past discussions ...

 

Constructing a "delay line": https://www.avrfreaks.net/forum/...

Same summary checklist as above:  https://www.avrfreaks.net/commen... [why didn't I do that first?]  12 cycles was mentioned.

Checklist repeated: https://www.avrfreaks.net/commen... https://www.avrfreaks.net/commen...

 

https://www.avrfreaks.net/commen... Note that in this thread much of the time is spent exploring the requirements and the "fit" of proposed solutions.

 

Discussion again with requirements numbers, links to implementations including a danni: https://www.avrfreaks.net/forum/...

 

https://www.avrfreaks.net/forum/...

 

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks theusch; I'll check through those.