(Ever had one of those nights where sleep won't come and things are preying on your mind?)
Setting previous posts aside and going back to the first post, here's my revised take on things. Be aware that this is somewhat speculative. It's 3AM, I don't have a test system to hand, and I'm not going to put one of my "production" systems at risk.
What I think is happening is this:
Option 1:The service will show as failed if any command within has a non-zero exit code.may shed light on why it failed.
Option 2:Change the lines in rc.local toReboot and check the contents of /tmp/gpio.log
Option 3: Use one of the availabke tools that can show current GPIO status
Option 4: Test those gpio commands from a logged in terminal with a sudo prefix. Not quite the same as runing under rc.local but may shed some light on things.
Option 5 Check device tree ti see what has been loaded and what has been enabled. Sorry but, no, I don't know how to do that.
If I am correct, the problem is a combination of the OP using the wrong overlay (or the wrong syntax of the overlay) compounded by WiringPi not working on Bookworm.
Again, if I am correct, the fix is the same under both Bullseye and Bookworm: do it properly. Remove WiringPi and the gpio commands, replace dtoverlay=uart0 in config.txt with enable_uart=1, and reboot.
This is not a change in Bookworm nor was it a change in Bullseye.
(NB: I've used release codenames throughout. To clarify Bullseye == 11, Bookworm == 12)
Setting previous posts aside and going back to the first post, here's my revised take on things. Be aware that this is somewhat speculative. It's 3AM, I don't have a test system to hand, and I'm not going to put one of my "production" systems at risk.
- /dev/ttyS0 and /dev/ttyAMA0 are not the same UART. This means the OP's basic assumption that the device node has changed from /dev/ttyAMA0 to /dev/ttyS0 is incorrect. Bullseye should show both UART devices.
- As ths is a 3B+ it's highly likely that bluetooth is enabled in which case /dev/ttyS0 will be routed to the bluetooth hardware not the GPIO pins. Which would explain the lack of incoming data from the microcontroller. Bluetooth being enabled is the default state. A loopback test will also show no input for this reason.
- It further implies that the issue is in fact that uart0 has not been enabled.
- The documentation for the uart0 overlay has not changed between Bullseye and Bookworm:
Code:
Name: uart0Info: Change the pin usage of uart0Load: dtoverlay=uart0,<param>=<val>Params: txd0_pin GPIO pin for TXD0 (14, 32 or 36 - default 14) rxd0_pin GPIO pin for RXD0 (15, 33 or 37 - default 15) pin_func Alternative pin function - 4(Alt0) for 14&15, 7(Alt3) for 32&33, 6(Alt2) for 36&37 - OP has said they are using dtoverlay=uart0 in config.txt. Source
- That's incorrect syntax by the documentation (see above) so it's likely that the overlay is not loading. Further, the description of the overlay does not suggest that it enables the UART but that it changes the pin usage of an already enabled one.
- OP also states they have instaled WiringPi and that they have added a couple of WiringPi commands to their /etc/rc.local. Source. Yet they are also adament that WiringPi is not the problem. Source
- WiringPi was deprecated long ago and is no longer in development. It's hardly surprising that it may not work on Bookworm.
What I think is happening is this:
- Under Bullseye:
- The overlay either fails to load or does nothing as uart0 has not actually been enabled elsewhere.
- The gpio commands in rc.local work and enabled uart0
- udev does its thing and the correct device node is created.
- Under Bookworm:
- The overlay either fails to load or does nothing as uart0 has not actually been enabled elsewhere.
- The gpio commands in rc.local fail so uart0 is not enabled
Option 1:
Code:
systemctl status rc-localCode:
sudo journalctlOption 2:Change the lines in rc.local to
Code:
gpio mode 15 ALT0 2>/tmp/gpio.loggpio mode 16 ALT0 2>>/tmp/gpio.logOption 3: Use one of the availabke tools that can show current GPIO status
Option 4: Test those gpio commands from a logged in terminal with a sudo prefix. Not quite the same as runing under rc.local but may shed some light on things.
Option 5 Check device tree ti see what has been loaded and what has been enabled. Sorry but, no, I don't know how to do that.
If I am correct, the problem is a combination of the OP using the wrong overlay (or the wrong syntax of the overlay) compounded by WiringPi not working on Bookworm.
Again, if I am correct, the fix is the same under both Bullseye and Bookworm: do it properly. Remove WiringPi and the gpio commands, replace dtoverlay=uart0 in config.txt with enable_uart=1, and reboot.
This is not a change in Bookworm nor was it a change in Bullseye.
(NB: I've used release codenames throughout. To clarify Bullseye == 11, Bookworm == 12)
Statistics: Posted by thagrol — Sat Sep 28, 2024 2:49 am