Does this code depend upon SAMD's atomic access to "int" type?

Hi Paul,
the implementation is clearly not interrupt-safe; I believe we should target 32bit MCU in the future so all the considerations should be based on that fact.
Surrounding everything with noInterrupt or ATOMIC_BLOCK-like functions could have a real impact on performance. Limiting the usage to non-IRQ scenarios will make this library "useless".
Do you have any proposal/idea on this topic?

Agreed, disabling interrupts probably adds too much overhead. Using more than 8 bits for the head and tail index probably also slows the code too much on AVR. I'd recommend something like this, and in the documentation mention the maximum total buffer size is limited to 256 bytes on AVR.

class RingBuffer
{
    public:
    uint8_t _aucBuffer[RINGBUFFER_SIZE] ;
#ifdef __AVR__
    uint8_t _iHead ;
    uint8_t _iTail ;
#else
    int _iHead ;
    int _iTail ;
#endif

I do believe this feature will make a lot of people very happy, even if the total size is restricted to 256 bytes on AVR chips.

Any idea what the user-visible API will be in the HardwareSerial class? RingBuffer is meant to remain private, right?

On AVR, RingBuffer::addStorage() would also need to check the _size parameter to limit to the maximum.

Was any decision or proposal ever made for the public API for sketches? Would addStorage() also be in the HardwareSerial object? Or would it be 2 different function names, one for adding to the read buffer and another for writing?

I'd like to try implementing this. Is that ok? Obviously the last thing I want is to publish anything which needs to be kept confidential, or to end up causing compatibility problems.

I'd leave a single (generic) function in RingBuffer class while specializing in classes using it (like Serial.increaseTxBuffer and Serial.increaseRxBuffer). However, no public discussion has been made ATM, but I think that proposing in the dev list is a really good idea.
@PaulStoffregen , feel absolutely free to propose / post a PR 😄

Perhaps the words "Read" and "Write" would be more consistent than "Tx" and "Rx", with the rest of the Arduino API?

Serial.increaseReadBuffer(array1, size1);
Serial.increaseWriteBuffer(array2, size2);

So it's ok to discuss on the public developer list? This is a private area, so I'm always like to double check before posting anything in public.

@facchinm I believe we can close this one? Looks like ancient history 😉