Dual serial ports on RPI2, is it so?

That info is not supported by the RaspberryPi User Guide or the several web pages I looked at. There would appear to be just one UART, which uses GPIO Pin 8 for the transmit line and pin 10 for the receive line, BUT be aware that these pins only have 3.3v, so you'll need external buffering circuitry even for a 5v (TTL level) connection as well as for a 12v RS232 connection. Use /boot/cmdline.txt to set its baud rate (default is

Programs can access the UART as /dev/ttyAMA0 - finding this was the hardest part of pulling this stuff together. AFAICT its only documented in a forum question on the RPi home website.

https://pinout.xyz/ shows a nice interactive diagram (linked to from

AIUI the Pi does have two uarts; a full-function hardware one and a 'mini-uart' which has limited functionality. One of the changes on the Pi3 is to pinch the full-function uart for the Bluetooth interface and use the mini-uart for the console.

The article you have seen seems to confuse the issue by using on-chip GPIO port numbers not the Pi header numbers - the GPIO pins they quote are not accessible on the Pi.

I suspect (but may well be wrong) that the second uart could be made available, but only from bare-metal software, not from Linux.

Ok, that seems to settle the issue. I'm using RPI2s, but if there's no pin access the problem is intractable.

Thank you very much!

bob prohaska

There is pin access: pins 8 and 10 on the GPIO strip. Since the pins operate at 3.3v and should be buffered to avoid accidental damage to the RPI, the obvious way to use them is to buy a prototype expansion card and put the buffering and voltage changing (to TTL or 12v levels) circuitry on that.

Of course, its possible that somebody already sells a board that already does the signal buffering and level shifting.

That's already used for the console.

I need _both_ uarts: One for the console (presently 8 and 10) and a second to monitor 8 and 10 on the next Pi in the cluster.

Apologies for not being clear!

bob prohaska

I wonder if it's practical to bit bang a couple of other pins with a software serial program (guess it depends on what sort of of speed you want). This is done very successfully on the Arduino.

If you can describe what you're trying to put together that might help us to make better suggestions, e.g. how many RPis you need to link together and the topology of the network. Also, why the console has to be on a serial connection rather than plugging a screen+keyboard into HDMI+USB or using an Ethernet link.

And AFAIK the 1-Wire interface bit bangs GPIO 4 (by default). Ought to be able to manage few kbps, depending on what else the Pi is doing...

Couldn't the I2C bus be used?

In this case, four.

Ideally, a ring, with each Pi monitoring the console port of the next.

Remote access to u-boot and single user mode for troubleshooting.

The assumption is that at least one Pi will reboot to multi-user after a power outage or other catastrophe. With a ring, one can find a pi in multi-user mode, get on the console of the next, put it in multi-user and so on around the ring until everything is back to normal.

As it happens I'm using FreeBSD-11, but I believe the same applies to Raspian: U-boot and single user talk to the console and HDMI, but do not listen to the USB keyboard.

Thanks for reading,

bob prohaska

OK, I understand what you want, but I get a brain itch from aspects of it: I can see that the ring can self-monitor, but with the monitoring chain only circulating in one direction. However, doesn't this demand that at least one RPi has to deal with connections from two places (its neighbour and your remote access), which raises two issues:

- either this point needs a third UART or you'll end up connecting two lines to the same UART, which doensn't sound as if it would end well

- You still have a single point of failure unless there's some switching mechanism that allows your monitoring line to connect to an arbitrary ring member.

Given that my RPi, a 512Gb model B that was among the first of these to appear, has always been run headless [*] and has never failed to come up in multi-user mode, I'd be inclined to use Ethernet and replace the ring with a central dumb switch: what have I missed?

Somebody else probably knows this: I've never run an RPi in single user mode and can't remember when I last ran any Linux in that mode. RedHat Linux has been my default OS at home since 2001 and Fedora since 2005.

The external access is via Ethernet, as all four RPI2s are on the Internet. When the lights come back on, one tries to ssh into each host in turn. Hopefully one of them will ask for a password. Then it's time to work around the ring until they all come up.

It sounds like you might be thinking of getting into each RPI2 via the console port chain; it could be done but is horribly confusing (I tried it!). Much easier to ssh into pi A, open a cu session to B, get B running multi-user then ssh into B via a new terminal window and open a cu session to C. This assumes B and C won't initially respond to ssh on their own.

It's true that if a Pi can't be brought up multi-user then the chain of recovery is broken to the next Pi that comes up by itself.

Nothing at all. This is a "suspenders over a belt" approach meant to cope with worst-case problems like the need to repeatedly run fsck in single user.

FreeBSD is much newer to ARM than Linux. The big push has been to ARM64, with more modest but still effective efforts on ARMv6. Eventually the need for single user access will go away, but that will take some time. Right now FreeBSD-ARM is still developing rapidly, with all the bugs that implies..

It would have been very nice if the RPIs had two independently-usable serial ports. Since they don't I'll just learn to live with USB-serial adapters.

Thanks for reading!

bob prohaska

One of the problems with USB/serial is that if you sneeze they are likely to drop out, then come back as a different port number. Some years ago I got round this (not on a RasPi) by having regular messages sent and re-scanning all possible port numbers if they timed out.

After getting fed up with this recently, I researched the matter and it turns out it is possible to assign descriptive names to the ports using device rules. You match a specific USB serial device using its device code and/or serial number and assign it a name, and the udev daemon creates a symlink in /dev that points to the name that device got at that time.

When you open it using the symlink instead of the ttyUSB name you always get the same device no matter what number it got.

Thinking about it, this capability has probably been overhauled and destroyed by systemd. I am still running the version without systemd.

This uDEV does work as far as the symlink to ttyUSB device always being correct. However if the software has the symlink/device open when the hardware goes away and comes back that software handle no longer points to anywhere useful.

Looking at you NUT and the serial connection to a UPS provided by a USBRS232 convertor. USB side throws a wobbly, NUT driver doesn't notice, or get told about, the change and promptly floods /var/log/messages with complaints about not being able to communicate with the UPS.

File a bug report or better yet fix it yourself and send a patch.

It does seem a bit kludgy to make the application reopen a serial port because the USB implementation is flaky, but it should be an easy enough to do.

communicate

UPS.

I think the problem is partly hardware (Prolific PL2303 based devices) that ocassionaly disappear then come back. But also partly the software that doesn't handle the condition properly. I'm trying to side step the problem by swapping a PL2303 based USBRS232 adapter with a FT232RL based one from FTDI. Trouble is the problem only happened occasionally, once in a couple of months or so and the FTDI has only been in about a month.

It might not help. I've occasionally had the same problem with FTDI adaptors. I suspect it could be down to flaky handling of USB itself within motherboards.