UART adaptations for modern Raspbian

[stephanmantler]

• Modernized tty naming ("serial0" / "serial1")
• Added 2400 / 4800 speeds
• Made open() nonblocking (fixes hang on open() call)

[uraimo]

Thanks Stephan for submitting this!
The CHIP's Debian does not have those serialn links (yet?), could you revert it to "ttyS0"?

Regarding the links, on my Pi3 with Stretch they point to:

• serial0 -> ttyS0
• serial1 -> ttyAMA0

Where AMA0 was the serial accessible via P14-15 that was normally returned by UARTs(for:).
Since you return serial0(S0) for all the Pis before the 3, did something change lately and S0 is now associated with Pin 14-15?
If not, can you return serial1 instead in that case? And also return serial1 first for the Pi3? The idea in all those factories is to always return the most easily reachable (the one that does not need additional config) interface first even if the natural ordering is not followed.

[hpux735]

The names of these device files can vary wildly. I would suggest searching a list of possible serial device names.

Examples include:
ttyS<x>
ttyAMA<x>
ttymxc<x>

[stephanmantler]

AFAIK /dev/serial0 etc. are automatically symlinked to the ‘logical’ choice on Raspberry Pi’s (ttyAMA0 on Pi/Pi2; ttyS0 on Pi3) so that should work as intended (I hope).

One nice consequence is that the constructor can be used to instantiate any references to /dev/* directly (and not just /dev/tty*) in case the predefined lists are inaccurate or insufficient (eg. with USB ports).

I’ll revert the change for the CHIP.

[uraimo]

(ttyAMA0 on Pi/Pi2; ttyS0 on Pi3) so that should work as intended (I hope).

Yeah, I could verify it only on the Pi1 but I'm pretty confident that's correct, after reading this (tl;dr: the fast ttyAMA0 is ootb used for the bluetooth chip on Pi3).

I would suggest searching a list of possible serial device names.

Yep, this would definitely be an improvement, making the whole thing less static. I'm opening a separate issue for this (#57) since it requires additional considerations.

[stephanmantler]

Turns out the non blocking flag requires some additional changes. I’ll submit another pull request soon that reverts non blocking opening (which should really have been a separate patch) and implements the prioritized list approach more or less as discussed.

[uraimo]

Perfect, thanks!