HardwareSerial buffer overflows (small?)

Hi team,

I’m busy using the new hardware serial capability on the 6502 but I’m experiencing odd behaviours. Digging deeper into it, it appears that the HW serial buffer is 8 bytes and so high transfer rates (well, 115200) overflow this before I get a chance to read it.

Evidence:
Serial.println(UART_2_RX_BUFFER_SIZE); -> 8
Serial1.read(); returns a high bit set e.g. greater than 255. This is because it’s set in the internal buffer read function, I think.
Serial.println(UART_2_SpiUartGetRxBufferSize()); -> returns a max of 8, and generally the error bit is set on the read prior when it is 8 too.

So…can this buffer be increased @Aaron ? Or can we get an interrupt handler to push things into a software buffer? Or am I totally down the wrong path?

Thanks.

1 Like

So this one was a bit odd. It appears I was blowing the heap and getting a load of weird behaviours as a result. The buffer still seems small though, it’d be great to get 64 bytes if that’s not going to hurt.

During my problems freeMemory() went down to ~6kb but…that’s still quite a bit. I was using Arduino Strings (yeah, I know) to receive ~1kb of data into. It appeared to screw up the serial receive a long time before I got any data, so I’m still finding it hard to put my finger on, but changing it to have a (frankly) horrible statemachine that processes the data char-by-char has nearly resolved all my issues. Certainly no more lost chars and no high bit set.

The only remaining issue is that when LoRaWAN is compiled in, the main command I TX (I’m doing some BT scanning on an HM-10/19 device) needs to be sent more than once to get it to work. It works 100% fine when it’s in it’s own sketch, so…there’s something not quite perfect.

When I get a chance I will install a loopback and see if I can reproduce.

1 Like