Is 9 bit data support for UART on the horizon?

[mechatroniks-git]

I have a device that is running 9N1 that I want to interface with. I know the ATtiny hardware supports it and megaTinyCore does not.

By any chance, is this on the roadmap to support?

[SpenceKonde]

No, this will never be added to the core.

Both classic and modern AVR UARTs support 9-bit serial at the hardware level. However, it is never supported in Arduino. Because the bit configuration is specified at runtime not compile time, the Serial class must include code to handle all supported options in the binary, meaning everyone would be suffer with a much larger binary, and because each character is now 2 bytes, a buffer of the same size would take twice as much memory, and every piece of code that handles a character needs to be rewritten to accommodate this, including provisions for interrupt safety since reading a word is not atomic like reading a byte is. It would not be fair to everyone else to impose a huge flash and ram penalty for a feature that will be used by a fraction of a percent of the userbase. I spent several days just to reduce the size that serial compiled to by just 100 bytes, because some of the most popular modern tinyAVR parts have only 4k of flash. I estimate the cost of supporting 9-bit mode would be several times that. Something like that does not meet my criteria for inclusion, and the vast majority of users would see it as a regression because it increases flash usage substantially in exchange for a feature they would never use.

This should be handled by a third party library which only supports 9-bit serial (what I see as the most likely route to success is essentially duplicating the way the official USART class files are structured, namely with the ISRs and the declaration of each instance of NineBitSerial for a given USART in it's own .c file, which will only get pulled in if that port is referenced from the sketch thus allowing other USARTs to be used normally.
It would only need to be written once in order to cover the AVR Dx. megaAVR 0-series (ex, 4809), and tinyAVR 0/1/2-series, as well as any other modern AVRs released in the foreseeable future like the AVR EA-series. It is likely that the serial ports in the hardware will remain in their current form, except little things, like a possible fix to start of frame detection interrupt mechanism and maybe to fix the port override behavior (both issues listed in the errata for many parts) until the next end-of-classic-avr-beginning-of-modern-avr scale revolution..

As a starting point I'd take the hardware serial from the cores, and remove all the code that is conditionally compiled when USE_ASM_RXC/USE_ASM_TXC/USE_ASM_DRE is defined as 1 leaving the code used with those macros are defined as 0 instead (the assembly would need complicated and difficult changes to adapt for this - by the way, the reason I wrote that horrifying assembly was because it saves flas, which it the same reason I am not implementing 9-bit serial as part of the core.
To get one universal library, i wouldint include a NineBitSerial.pins(), and I'd first make it work with a requirement that the user set the TX pin output and enable the pullup on RX before calling begin()
For the 9-bit itself you'd need to change the uint8_t array used as a ring buffer to a uint_16 array, everyplace the buffer or head/tail were used, you'd have to adapt them tothe fact that one character now takes up 2 bytes not 1...

It's a lot of work for an incredibly small number of users; the only way that I would write it is if someone paid me a few hundo for it.

[mechatroniks-git]

Thanks for the detailed response. All makes sense.

I see that Teensy handles it with an #define in the core, you need to uncomment

//#define SERIAL_9BIT_SUPPORT

If I do try to get it working (might do this one on Teensy), I'll follow what they did, as it appears to be an elegant implementation