LPCOpen 11Uxx V2.06 Ringbuffer bug

[lpcware]

Content originally posted in LPCWare by pat180269 on Tue Oct 27 03:12:31 MST 2015
There is a bug in ring_buffer.c

The macros used for adjusting the head and tail pointers are

#define RB_INDH(rb)                ((rb)->head & ((rb)->(count-1))
#define RB_INDT(rb)                ((rb)->tail    & ((rb)->(count-1))

but they should be

#define RB_INDH(rb)                ((rb)->head % ((rb)->count))
#define RB_INDT(rb)                ((rb)->tail    % ((rb)->count))

The code is very confusing because data is inserted at the head and popped from the tail which is counter intuitive.

[lpcware]

Content originally posted in LPCWare by DavidKiryat8 on Tue May 24 21:05:20 MST 2016
I was only bitten by this "bug"!
I do call it a bug since it is an unexpected requirement that easy to not see.
If it hit more than one person then conclusions should be in order.
The main problem is that the LPC Open documentation is vastly lacking.
The help file is in old Microsoft help format instead of a standard pdf.
This is a lack of respect for developers.
Also there seems to be no system in place at NXP for timely corrections of NXP examples.
This criticism is meant to be a positive force for change.
Thanks

[lpcware]

Content originally posted in LPCWare by starblue on Wed Oct 28 01:56:54 MST 2015

---

Quote: pat180269
There is a bug in ring_buffer.c

---

No, it is not a bug.
The documentation in ring_buffer.h specifies that count must be a power of two. Then % and & are equivalent, but & is much faster.

Though it would be nice if the init routine checked that count is indeed a power of two.

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Tue Oct 27 10:30:31 MST 2015
The 'and' calculations are correct when 'count' is a power of two.
Usually produces more compact and faster code.

Mike.