It also looks - correct me if I'm wrong - that currently we disable the UART0 by routing UART1 to /dev/ttyAMA0 in order to get a reliable serial console. The UART1 is a crap as the baudrate is derived from system clock. As I understood we can have one or another - never both (working reliably).
There were however evidences of people using Bluetooth and serial at the same time. It looks that it requires "core_freq=250" lock in the /boot/confi.txt.
Do you think that we could get away with it? Would that kind of sw-uart for serial console usable at all?
@ogra,
Right, read your comment and researched a bit. It seems that there are two UARTs on RPi:
* UART0 (Bluetooth /dev/ttyAMA0)
* UART1 (Software mini-UART /dev/ttyS0)
It also looks - correct me if I'm wrong - that currently we disable the UART0 by routing UART1 to /dev/ttyAMA0 in order to get a reliable serial console. The UART1 is a crap as the baudrate is derived from system clock. As I understood we can have one or another - never both (working reliably).
There were however evidences of people using Bluetooth and serial at the same time. It looks that it requires "core_freq=250" lock in the /boot/confi.txt.
Do you think that we could get away with it? Would that kind of sw-uart for serial console usable at all?