Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Dual serial ports on RPI2, is it so?
135 views
Skip to first unread message
bob prohaska
Jun 22, 2016, 6:26:11 PM6/22/16
to
There's an article at
http://lavalink.com/2012/04/more-on-raspberry-pi-serial-ports/
suggesting that a Raspberry Pi has two independent serial ports
using gpio pins 36, 37, 38 and 39. On the face of it that seems
odd, since the diagram that came with my RPI2 says pin 39 is ground.
I can find no corroboration for this claim, and one counter-claim,
which holds that the second serial port shares pins with the first.
The point of such an arrangement is obscure, at least to me.
Far as I can tell the raspberrypi.org documents are mum.
Can anybody shed light on this notion? It would be _really_
handy to have two simultaneous serial ports on an RPi.
Thanks for reading,
bob prohaska
http://lavalink.com/2012/04/more-on-raspberry-pi-serial-ports/
suggesting that a Raspberry Pi has two independent serial ports
using gpio pins 36, 37, 38 and 39. On the face of it that seems
odd, since the diagram that came with my RPI2 says pin 39 is ground.
I can find no corroboration for this claim, and one counter-claim,
which holds that the second serial port shares pins with the first.
The point of such an arrangement is obscure, at least to me.
Far as I can tell the raspberrypi.org documents are mum.
Can anybody shed light on this notion? It would be _really_
handy to have two simultaneous serial ports on an RPi.
Thanks for reading,
bob prohaska
Martin Gregorie
Jun 22, 2016, 8:05:11 PM6/22/16
to
On Wed, 22 Jun 2016 22:26:10 +0000, bob prohaska wrote:
> There's an article at
> http://lavalink.com/2012/04/more-on-raspberry-pi-serial-ports/
> suggesting that a Raspberry Pi has two independent serial ports using
> gpio pins 36, 37, 38 and 39. On the face of it that seems odd, since the
> diagram that came with my RPI2 says pin 39 is ground.
>
That info is not supported by the RaspberryPi User Guide or the several
> There's an article at
> http://lavalink.com/2012/04/more-on-raspberry-pi-serial-ports/
> suggesting that a Raspberry Pi has two independent serial ports using
> gpio pins 36, 37, 38 and 39. On the face of it that seems odd, since the
> diagram that came with my RPI2 says pin 39 is ground.
>
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
115200).
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
https://www.raspberrypi.org/documentation/usage/gpio/ so it must be OK.
http://www.raspberrypi-spy.co.uk/2012/06/simple-guide-to-the-rpi-gpio-
header-and-pins/ is also useful, as it details how GPIO differs between
the various models from the original model A to the Pi 3.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
dave
Jun 23, 2016, 6:44:03 AM6/23/16
to
'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.
--
Dave
bob prohaska
Jun 23, 2016, 10:21:26 PM6/23/16
to
dave <da...@cyw.uklinux.net> wrote:
>
> 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.
>
Ok, that seems to settle the issue. I'm using RPI2s, but if there's no
>
> 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.
>
pin access the problem is intractable.
Thank you very much!
bob prohaska
Martin Gregorie
Jun 24, 2016, 7:32:19 AM6/24/16
to
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.
Rob Morley
Jun 24, 2016, 10:40:05 AM6/24/16
to
On Fri, 24 Jun 2016 11:32:17 -0000 (UTC)
Martin Gregorie <mar...@address-in-sig.invalid> wrote:
> Of course, its possible that somebody already sells a board that
> already does the signal buffering and level shifting.
>
https://www.abelectronics.co.uk/products/17/Raspberry-Pi--Raspberry-Pi-2-Model-B/51/Serial-Pi-Plus
Martin Gregorie <mar...@address-in-sig.invalid> wrote:
> Of course, its possible that somebody already sells a board that
> already does the signal buffering and level shifting.
>
bob prohaska
Jun 25, 2016, 12:18:31 AM6/25/16
to
Martin Gregorie <mar...@address-in-sig.invalid> wrote:
>>
> There is pin access: pins 8 and 10 on the GPIO strip. Since the pins
>
That's already used for the console.
>>
> There is pin access: pins 8 and 10 on the GPIO strip. Since the pins
>
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
>
Folderol
Jun 25, 2016, 2:31:00 AM6/25/16
to
serial program (guess it depends on what sort of of speed you want). This is
done very successfully on the Arduino.
--
W J G
Martin Gregorie
Jun 25, 2016, 5:28:28 AM6/25/16
to
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.
Dave Liquorice
Jun 25, 2016, 6:02:08 AM6/25/16
to
On Sat, 25 Jun 2016 07:30:59 +0100, Folderol wrote:
> 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.
And AFAIK the 1-Wire interface bit bangs GPIO 4 (by default). Ought
> 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.
to be able to manage few kbps, depending on what else the Pi is
doing...
Couldn't the I2C bus be used?
--
Cheers
Dave.
bob prohaska
Jun 25, 2016, 5:03:53 PM6/25/16
to
Martin Gregorie <mar...@address-in-sig.invalid> wrote:
>>
> 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
In this case, four.
>>
> 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.
>
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.
Martin Gregorie
Jun 25, 2016, 7:14:57 PM6/25/16
to
On Sat, 25 Jun 2016 21:03:52 +0000, bob prohaska wrote:
> In this case, four. [RPis]
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?
[*] It had to be booted once with USB kbd and monitor because when I got
it, sshd was disabled by default: now it is enabled as standard.
> 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.
>
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.
> In this case, four. [RPis]
>
>> and the topology of the network. Also, why the console has to be on a
>
> Ideally, a ring, with each Pi monitoring the console port of the next.
>
>> serial connection rather than plugging a screen+keyboard into HDMI+USB
>> or using an Ethernet link.
> 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.
>
OK, I understand what you want, but I get a brain itch from aspects of
>> and the topology of the network. Also, why the console has to be on a
>
> Ideally, a ring, with each Pi monitoring the console port of the next.
>
>> serial connection rather than plugging a screen+keyboard into HDMI+USB
>> or using an Ethernet link.
> 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.
>
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?
[*] It had to be booted once with USB kbd and monitor because when I got
it, sshd was disabled by default: now it is enabled as standard.
> 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.
>
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.
bob prohaska
Jun 25, 2016, 9:10:20 PM6/25/16
to
Martin Gregorie <mar...@address-in-sig.invalid> wrote:
>>
> 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.
The external access is via Ethernet, as all four RPI2s are on the Internet.
>>
> 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.
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.
> 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?
>
with worst-case problems like the need to repeatedly run fsck in single user.
>
> 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.
>
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
Folderol
Jun 26, 2016, 3:10:46 AM6/26/16
to
On Sun, 26 Jun 2016 01:10:19 +0000 (UTC)
bob prohaska <b...@www.zefox.net> wrote:
<snip>
> 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.
--
W J G
bob prohaska <b...@www.zefox.net> wrote:
<snip>
> 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
>
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.
--
W J G
Rob
Jun 26, 2016, 3:39:14 AM6/26/16
to
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.
Dave Liquorice
Jun 26, 2016, 5:59:04 AM6/26/16
to
On 26 Jun 2016 07:39:13 GMT, Rob wrote:
> 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.
This uDEV does work as far as the symlink to ttyUSB device always
> 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.
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
USB<>RS232 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.
--
Cheers
Dave.
Rob
Jun 26, 2016, 6:12:13 AM6/26/16
to
Dave Liquorice
Jun 26, 2016, 4:37:06 PM6/26/16
to
On 26 Jun 2016 10:11:50 GMT, Rob wrote:
>> Looking at you NUT and the serial connection to a UPS provided by
a
>> USB<>RS232 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.
https://lists.alioth.debian.org/pipermail/nut-upsdev/2013-May/006457.h
>> Looking at you NUT and the serial connection to a UPS provided by
a
>> USB<>RS232 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.
tml
https://forum.pfsense.org/index.php?topic=63967.0
https://bugs.launchpad.net/ubuntu/+source/nut/+bug/535583
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 USB<>RS232
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.
--
Cheers
Dave.
Ahem A Rivet's Shot
Jun 26, 2016, 4:59:53 PM6/26/16
to
On 26 Jun 2016 10:11:50 GMT
port because the USB implementation is flaky, but it should be an easy
enough to do.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Folderol
Jun 26, 2016, 5:04:34 PM6/26/16
to
suspect it could be down to flaky handling of USB itself within motherboards.
--
W J G
bob prohaska
Jun 26, 2016, 10:50:52 PM6/26/16
to
Folderol <gen...@musically.me.uk> wrote:
>
> 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.
>
I'm starting to wonder the same thing. Of the four RPI2s I have, using pl2303 adapters,
>
> 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.
>
two seem to work fine and two don't. The problem is clearly associated with particular
RPI2s, not the adapters. As it happens, those two hosts use SanDisk Extreme 32GB USB
flash drives while the two hosts without problems either have no external storage or an
old-fashioned mechanical hard drive. The failures are in the form of hard lockup on
the USB side, requiring total disconnection to reset.
As it happens I'm using FreeBSD, not Linux, but the story seems otherwise similar.
I just ordered two FTDI adapters from Digi-Key, I hope my luck is better than yours!
Thanks for posting,
bob prohaska
Dave Liquorice
Jun 27, 2016, 12:59:17 PM6/27/16
to
On Mon, 27 Jun 2016 02:50:52 +0000 (UTC), bob prohaska wrote:
>> 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.
I have a hunch that it could be power handling. With me it's only the
>> 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.
one connected to the APC UPS that gives the most problems. Swapping
around adapters (I have three bought at the same time) doen't make
any difference the UPS is always the less stable.
> I'm starting to wonder the same thing. Of the four RPI2s I have, using
> pl2303 adapters, two seem to work fine and two don't. The problem is
> clearly associated with particular RPI2s, not the adapters. As it
> happens, those two hosts use SanDisk Extreme 32GB USB flash drives while
> the two hosts without problems either have no external storage or an
> old-fashioned mechanical hard drive.
groups? If the problem moves it's Pi board problem if it doesn't it's
the adapter or something to do with how the Pi is being used.
I think there is some particular combination of handshake line setup
and data stream that pushes the required power just that little bit
too much and the chip crashes. This clears the "fault" state so it
instantly reconnects.
> The failures are in the form of hard lockup on the USB side, requiring
> total disconnection to reset.
the APC serial connection is not quite standard. So perhaps I don't
have the right conditions to keep the chip crashed only to crash it.
--
Cheers
Dave.
Andrew Gabriel
Jul 3, 2016, 7:14:17 PM7/3/16
to
In article <nkl0mm$tdb$1...@news.albasani.net>,
I have not seen a distro which sets up the BCM2835 i/o to drive both
UARTs, even though the function exists in the i/o core.
You could use a USB to serial adaptor.
Another option would be an SPI or I2C UART, but you would need to
knock up a driver for it I suspect.
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
UARTs, even though the function exists in the i/o core.
You could use a USB to serial adaptor.
Another option would be an SPI or I2C UART, but you would need to
knock up a driver for it I suspect.
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
bob prohaska
Jul 3, 2016, 11:05:59 PM7/3/16
to
That's what I'm doing. Started out with PL2303TA-based units. Out of
four (on four RPI2s) two worked fine and two locked up routinely, usually
within 24-48 hours. Substituting FTDI-based adapters has (up to 4 days)
solved the problem with the two pl2303 units that were locking up.
It's looking as if the problem isn't with the PL2303, but rather with
the particular RPI2 it's plugged into. The offending RPI2s both use
USB 3 flash drives for outboard storage, the two RPI2s which support
the PL2303s use either a USB 2 hard drive or no external storage.
Very difficult to figure why that might make a difference, but so
far that's the experience.
It should be emphasized that this is with FreeBSD-11, not Raspian,
but both are open source and likely use similar uplcom drivers.
four (on four RPI2s) two worked fine and two locked up routinely, usually
within 24-48 hours. Substituting FTDI-based adapters has (up to 4 days)
solved the problem with the two pl2303 units that were locking up.
It's looking as if the problem isn't with the PL2303, but rather with
the particular RPI2 it's plugged into. The offending RPI2s both use
USB 3 flash drives for outboard storage, the two RPI2s which support
the PL2303s use either a USB 2 hard drive or no external storage.
Very difficult to figure why that might make a difference, but so
far that's the experience.
It should be emphasized that this is with FreeBSD-11, not Raspian,
but both are open source and likely use similar uplcom drivers.
Andrew Gabriel
Jul 4, 2016, 3:47:15 AM7/4/16
to
In article <nlcjqm$e4n$1...@news.albasani.net>,
One issue with USB to serial adaptors is there are a lot of poor
Chinese fakes of the pl2303 and FTDI chips out there, and they do
the sort of thing you describe. Make sure you buy from a trustworthy
source.
Chinese fakes of the pl2303 and FTDI chips out there, and they do
the sort of thing you describe. Make sure you buy from a trustworthy
source.
0 new messages