Raspberry Pi 3 serial dilemma, replace with many Propeller boards.
Rsadeika
Posts: 3,824
In my new robot project I was trying to hook a Raspberry Pi 3 to my Activity Board. Things have changed with the new RPi 3 board.
The RPi UART is now -> /dev/ttyS0, the Bluetooth is now -> /dev/ttyAMA0. When you have the serial port disabled in configuration, the /dev/ttyS0 file disappears, so you cannot access it. Not sure what the Raspberry Pi people are up to. If you fall back to using an RPi 2 board with the new OS, the /dev/ttyAMA0 disappears, so you cannot access that either. I guess there is a way to beat the system, so to speak, but who wants to go through all the hassle to get there, and then do it again every time the system gets updated.
So, I guess my alternative is to add my other Propeller boards too the project, distribute the work load, and have the Activity Board act as the master, that should be simple enough to do, I guess.
I guess what I really need is a Propeller board with about 60 I/O pins, at least, maybe a meg of memory, at least, 16 COGs, at least, an active WiFi, an ADC component, and what else... oh, a useable user system to use all the components. Have I missed anything?
This is really getting to be frustrating, to say the least.
Ray
The RPi UART is now -> /dev/ttyS0, the Bluetooth is now -> /dev/ttyAMA0. When you have the serial port disabled in configuration, the /dev/ttyS0 file disappears, so you cannot access it. Not sure what the Raspberry Pi people are up to. If you fall back to using an RPi 2 board with the new OS, the /dev/ttyAMA0 disappears, so you cannot access that either. I guess there is a way to beat the system, so to speak, but who wants to go through all the hassle to get there, and then do it again every time the system gets updated.
So, I guess my alternative is to add my other Propeller boards too the project, distribute the work load, and have the Activity Board act as the master, that should be simple enough to do, I guess.
I guess what I really need is a Propeller board with about 60 I/O pins, at least, maybe a meg of memory, at least, 16 COGs, at least, an active WiFi, an ADC component, and what else... oh, a useable user system to use all the components. Have I missed anything?
This is really getting to be frustrating, to say the least.
Ray
Comments
Check with Bill Henning and see if he has a solution with his Propeller PI Hat.
Jim
I use a Raspi USB port, setup for serial communication with propeller boards, so
that the serial port is not affected. I am using XBEEs for wireless communication.
Nick
What do their forums say ? - if is this a real usage issue, I'd expect them to fix it - there will be some reason behind the change... Perhaps a Pi4 is being worked on, and needs more serial choices ?
Serial ports work fine on all Pi. Give or take a name change.
I see devices like the XR22804 or FT2234 can add 4 UARTS on one USB connector, so could give a better 'fan-out' to multiple Serial slaves.
A neat thing is that you can arrange that a USB serial port always gets the same name in /dev as you unplug and replug it. You can even give specific devices meaningful names like "/dev/propeller".
You just have to setup some udev rules.
See hear for example:
http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/
If you have the serial port enabled, in config, then the port has a login sequence it goes through, for an external hook up to the Raspberry Pi UART.
Previously, it was setup that once you disable the serial port, the login stuff was disabled, and you could use /dev/ttyAMA0 directly.
Ray
There is some chatter here around this...
https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=138223
Seems they believed they were forced to swap UARTS in order to support the Bluetooth, and that of course, has bitten them, as the UARTS are not interchangeable.
Might have been smarter to patch the Bluetooth instead, to work with the available UART, which would have kept things standard.
Still, it does sound like you can reverse the mapping in software, if you can tolerate losing Bluetooth. Ugh.
If you raise that question in the Pi Forums, what do they say about a fix ?
(also see the remapping forum link I gave above, which may help )
But, I'm pretty sure it's possible to use the UART on GPIO and Bluetooth at the same time. It would be crazy otherwise.
The Pi forum is of course a better place for these questions.
What changed was the UART0/UART1 mapping, which swapped on Pi3.
Where that proves to be a problem (eg someone needs parity), it looks like they can swap-back - but at the cost of no bluetooth....
Ray
Even more Pi-specific, is your particular issue, which seems related to a change in the config handling.
If you can explain to them why what they have done is less than ideal, they may (eventually) release a fix.
Certainly more people are likely to know a solution to this problem on the Pi forum than here.
We can't hold Parallax responsible for changes in the Pi. What would they do apart from go to the Raspi forum to investigate? Well, we can do that to.
In fact I just did because I will want UART and bluetooth both working soon.
The solution seems to be described here: https://www.raspberrypi.org/forums/viewtopic.php?t=138120&p=926637
I have not fully understood it yet, let alone tried it. Maybe later.
I ran into this issue when participating in the Element14 PiIoT challenge. As you found, with the Raspberry Pi 3, the onboard BLE device is tied to a UART. In my instance, after an update on the RasPi 3, the /dev/ttyAMA0 and /dev/ttyS0 (serial0 and serial1) got swapped so the onboard BLE device stopped working as well as the EnOcean device I had connected to the board messing up my OpenHAB config. This also killed the on board WiFi device, so just be aware when updating the RasPi 3.
It took some effort and searching the web to find a resolution, but basically you can actually swap the assignment of ttyS0 and AMAO between serial0 and serial1.
You can have a peek here and see my follow on comments where I got the devices working again.
https://element14.com/community/community/design-challenges/pi-iot/blog/2016/07/09/pi-iot-smarter-spaces-3-remote-horse-feeder-system#comments
At this point I find the existing solution to be non workable, for me. So, I am moving ahead with my idea of using a DNA-RTC and QuickStart board, and the Activity Board will be the master. After playing with some code, for achieving the aforementioned, this is not going to be an easy or pretty solution. Maybe I have to give this some more thought.
Ray
For the RasPi check out the PiFace Digital I/O Expander and RTC devices.
Check out JonnyMac's post Automated Menorah where he used an i2C RTC device for an example of using that sort of device.
It does have some annoyances, like no built in WiFi, so I have to attach a fairly large USB WiFi. But for test purposes, at least /dev/ttyAMA0 is available and works the way I need it too. Hopefully the Raspberry Pi people will fix the annoyance with the GPIO UART for the RPi 3 unit. I hope it will happen within the next year or so.
Now I have the Activity Board hooked up to the RPi 2 via /dev/ttyAMA0, and with a small Python serial program, on the RPi, I can now access the RPi to get the real time and date, as a test run. That removes the DNA-RTC board, since I do not need the RTC part anymore. Plus I will be able to use RPi for data storage instead of using the uSD on the Activity Board, more memory available on the Activity Board, for a larger program. I have added a QuickStart Board for more I/O, I will probably need the full 32K of memory on the Activity Board to get everything coordinated.
Ray
RoboPi works fine on Raspberry Pi 3 (as well as A/B/A+/B+/2/Zero), as I recall just add "FORCE_TURBO=1" to /boot/config.txt
The serial port is /dev/ttyS0 or /dev/ttyAMA0 depending on Raspbian version and board.
http://RoboPi.com
You are welcome.
Jim