On the Raspberry Pi 3 I want to be able to remap the hardware UART TX and RX from the Bluetooth module back to the old location on the GPIO header to use with addon boards which use these pins (xbee and another RF transmitter addon and also a RS485 board) and also disable the software uart from the pins which seems to vary speed with the processor load.

I understand that I need to create a device tree and I found this default template

PhilE wrote:I'll put together an overlay that disables Bluetooth and UART1 and maps UART0/ttyAMA0 to GPIOs 14 & 15.

Thank you for doing this, I havent used the overlays before and need to learn how they work

We have a lot of users who use serial based data loggers via the GPIO header for environmental monitoring and so they dont need bluetooth when on remote sites. They use GSM links to report the data back to their offices.

Followed the rest of the instructions that I used on the RPi 2 from here to get the GPS Module up and running and ntp compiled:http://ava.upuaut.net/?p=726

I also had to delete the console=tty command from the cmdline.txt as the raspi-config utility didn't seem to get rid of it after going to Advanced - Serial and turning off the serial console.
Does the order of the overlay's matter? Right now I'm loading the pi3-disable-bt overlay after the gpio-pps module. Everything else is 100% clean install.

Try using console=serial1 in cmdline.txt. It will get mapped back to ttyAMA0. I'm working on a firmware update that will restore the original behaviour when the overlay is used, but for now this one weird trick is necessary.

PhilE wrote:Try using console=serial1 in cmdline.txt. It will get mapped back to ttyAMA0. I'm working on a firmware update that will restore the original behaviour when the overlay is used, but for now this one weird trick is necessary.

This seems to have fixed the login problems via uart but when i tried running

PhilE,
I started again with another RPi3 and a clean install from NOOBS 1.8 and everything is now working. I think, the only difference is that I didn't run rpi-update this time. Thanks very much for writing this.
Greg

I have seen corruption on ttyS0 on my Pi3, but then I noticed that the red LED was flickering due to under-voltage. This triggers a clock speed reduction. Upgrading to a better supply (2.5A) has solved that problem for me.

@abelectronicsuk The next firmware release, due tonight, will included improved serial port alias handling:

1) It will search for any existing "serial0" in the DT, allowing the pi3-disable-bt alias to also disable the remapping.
2) It now searches for "=serial0", "=ttyAMA0" etc. instead of "config=...", so it will work with "kgdboc=serial0,115200" etc.

Once you update to this firmware, with the pi3-disable-bt overlay applied both "console=ttyAMA0" and "console=serial0" will both be translated to "console=ttyAMA0"; the "console=serial1" hack is then exactly the wrong thing to do, since it will be translated to "console=ttyS0".

Is setting the core_freq to 250 a guaranteed way to ensure that the mini UART will not show any speed fluctuations during operation? Asking because this overlay looks good, but for my usage I'd love to maintain Bluetooth and the ability to use the UART for hardware integration.

Would fixing the core_freq at 250 have any other ramifications on the operation (or lifetime?) of the device?

Yes, setting core_freq=250 should eliminate any UART glitching. It will also limit the VPU compute resource, which will mainly affect the new high quality analogue audio output, and could slightly increase the lifetime of the Pi (if there is any change at all).

2) Is there a way to fix this without loosing the new bluetooth functionality?

More details:
I have an application using /dev/ttyAMA0 on the Pi 2 to talk to an external device using 9600-8e1, but it doesn't work using /dev/ttyS0 on the Pi 3. Connecting a PC using minicom to the Pi 3 instead of the external device it works using 9600-8n1 on the external PC in minicom, but enabling even parity (9600-8e1) on the external PC will only show some of the transmitted characters (and some garbled).

The mini UART (ttyS0) does not support parity. I will create an overlay that uses ttyS0 for the BT modem, which may work for low baud rates and data volumes. Using it will also require the systemd script (/lib/systemd/system/hciuart.service) to be edited.

PhilE wrote:The mini UART (ttyS0) does not support parity. I will create an overlay that uses ttyS0 for the BT modem, which may work for low baud rates and data volumes. Using it will also require the systemd script (/lib/systemd/system/hciuart.service) to be edited.

This is great news I'm using BTLE so the bandwidth needed is low. Looking forward to testing

PhilE wrote:I've pushed the overlay (pi3-miniuart-bt) to the source trees. It will appear in the next release, or you can download prebuilt one here.

I have made a copy of the overlay and included the link in a blog post on (link removed) for all the steps I used to setup the serial console with the overlay. Once the overlay is included in the full release, I will update the post and remove the file.

I hope this is ok?

Last edited by abelectronicsuk on Mon Mar 07, 2016 2:16 pm, edited 1 time in total.