Request for change: Change "LN_BUF_SIZE" in "if (Buffer->WriteIndex >= LN_BUF_SIZE)" to a number or a Variable

[stighelmerpersson]

In the file ln_buf.h there is this section:

static inline void addByteLnBuf(LnBuf Buffer, uint8_t newByte)
{
Buffer->Buf[Buffer->WriteIndex++] = newByte;
if (Buffer->WriteIndex >= LN_BUF_SIZE)
Buffer->WriteIndex = 0;
}*

The change is to change the text "LN_BUF_SIZE" to a number or a new variable, so a number lower than LN_BUF_SIZE can be selected.

By changing the text "LN_BUF_SIZE" to a number or a new variable, ex. 100, it will then count up to 100 - and then reset to 0 - and then preventing doing the reset "inside" a package - and crash.

The number must be determined by the max. size of the package "minus" 128.

[kiwi64ajs]

Hmmm... we need to be careful about changing this, as there are some subtle logic/assumptions that allow a pointer to the beginning of the packet in the buffer to be treated as a contiguous array of bytes. This avoids copying each byte to a temporary buffer for subsequent use.

There is a trade-off in doing stuff like this but on a constrained AVR, it made sense. Maybe this is no longer true...

[kiwi64ajs]

The tricky bit happens here.

Once we know the length of a packet that is being assembled in the ring-buffer, it checks to see if it will fit without wrapping around, and if it will wrap, it moves the existing bytes from the end of the ring-buffer to the beginning, so the packet being assembled in the ring-buffer will be a linear array of bytes so a pointer to the beginning of the packet will point to a contiguous array of bytyes containing the packet, after all the bytes have been received.

Doing it this way means the overhead of adding bytes to the ring-buffer is low when called from an interrupt handler, but ensuring the packet bytes in the buffer are contiguous is performed in the main line/thread code, which is not in an interrupt handler.

Could you help me understand the problem you are encountering and why the existing logic crashes now, when it didn't before? I single-stepped through this code by hand, testing/validating its behaviour. Something must have changed.