Am I doing something wrong here, or is this a bug?
I’ve never had any problems with this before, whether with the standard Raspberry Pi (2, 3, 4), the Zeros, or even the Banana Zeros.
Did you try with 1,500,000 baud rate? Also in dietpiEnv.txt. I wonder why ttyS2 is present there. Did you add it manually? ttyFIQ0 should be the default/debug UART used by U-Boot etc. Though I see that there is at least not dedicated debug UART port/pins, so probably ttyS2 is needed, being the common GPIO pins 6+8+10 UART2.
But … quite possible that one of the USB ports (in case likely the power port itself) act as USB UART, which would then indeed appear as ttyUSB0. Such could be seen when powering it via other system’s USB port. E.g. on Windows you’d then see another USB communication being setup. Or … somewhat internally GPIO pins 6-8-10 are attached via USB bus, no idea what’s possible .
No, I hadn’t tried it yet, because most terminal programs don’t support it. Following your suggestion, I set Putty to that value, and sure enough! Despite other settings in the ENV file, it still works at this high data rate…
Then the question naturally arises: what good are the settings in the ENV file if they simply do nothing?
I didn’t change anything except the baud rate.
This also matches my rudimentary knowledge. It’s actually a quasi-standard for these parts…
Could be. The 3E/3W has the option to add a USB port to the header by re-soldering a few resistors. I wanted to use that later… Well, that’ll be fun ^^
I will try that later then; maybe you are right…
EDIT say:
I had the serial terminal running. The following error messages now appear every few minutes (always two lines together). Additionally, I no longer have access to the shell. Input is output as echo, but it no longer responds to input.:
[74589.099520] debugfs: Directory '3c:37:12:5f:4e:e0' with parent 'rc' already present!
[74589.099717] aicwf_sdio mmc2:390b:1: Error while (un)registering debug entry for sta 4
[74684.249680] debugfs: Directory '3c:37:12:5f:4e:e1' with parent 'rc' already present!
[74684.249774] aicwf_sdio mmc2:390b:1: Error while (un)registering debug entry for sta 6
[74704.830954] debugfs: Directory '3c:37:12:5f:4e:e0' with parent 'rc' already present!
[74704.834489] aicwf_sdio mmc2:390b:1: Error while (un)registering debug entry for sta 7
[74716.598744] debugfs: Directory '3c:37:12:5f:4e:e1' with parent 'rc' already present!
[74716.598940] aicwf_sdio mmc2:390b:1: Error while (un)registering debug entry for sta 8
EDIT say also:
root@SV-ADS-B:~# shutdown
Failed to connect to bus: Datei oder Verzeichnis nicht gefunden
root@SV-ADS-B:~#
Both in serial terminal and lan-terminal… What the heck…
shutdown now creates the same error but do what he say and shut down…
Can’t anyone explain why settings in the dietpiEnv.txt file have no effect?
There must be a way to adjust the serial port speed and its other parameters (bits, parity, stop bits).
The baudrate for u-boot is hardcoded to 1.5M.
The settings in dietpiEnv.txt affect only the kernel command line, but early boot via U-Boot uses 1.5M baudrate, that’s the gibberish you see.
(Changing the baudrate for u-boot is not so easy, you probably need to build u-boot by yourself)
So why not just use 1.5M also for console? (:
In u-boot, you can set the environment variable baudrate to specify the console baud rate. When you boot the kernel, you can have u-boot pass the kernel contents of the bootargs environment variable. That becomes the kernel command line. In that, you can set the kernel’s console’s baud rate. Most systems I’ve seen have something like this: bootargs=console=ttyS1,115200n8 ... That sets the baud rate independently of u-boot. If, you instead had something like bootargs=console=ttyS1,${baudrate}n8 ..., then the kernel would get the same baud rate as u-boot is using.
Here you need either install dbus, it’s not installed by default on DietPi
sudo apt install dbus
or maybe, because you are using UART, DBUS_SESSION_BUS_ADDRESS is not set correctly. But because it’s shuts down with shutdown now it sounds like more that dbus is missing.
Alternatively you can just use this (no dbus needed)
sudo systemctl poweroff
These message are about wi-fi I would say. Is the Wi-Fi functional?
… because this no longer works with longer cable connections…
Ahh, okay. I didn’t know that. I’ll try it out… Ty for the hint!
What exactly is DBUS, and what is it all used for?
What I’ve also noticed now is that this error doesn’t always appear. Sometimes it’s there, and (nowadays) often it isn’t. I haven’t been able to detect any connection to anything else (called functions, changes to application configurations); it happens completely randomly…
Yes. Wi-Fi works completely smoothly and quickly, without any problems.
Well, that can vary from person to person (-X-). And it works with long cables. It depends on the baud rate and the quality of the cable. With a PI3, I use this interface with about 90 meters of cable between them and 57600 baud.
I usually do that, too. Since the SoC will be located on a mast above the roof, along with the SDR and antenna, it’s quite useful to have the lowest common denominator, the serial interface, as an option to see from “below” where the SoC might be struggling, before having to climb onto the roof to take down the mast and antenna. This works if WLAN and other stuff goes wrong…
-X-
Zusammenfassung
I’ve been alive so long that I still used “mainframe computers” (in the sense of large dimensions) on a teletype terminal with a 1200-7e2, hard drives with a one-meter diameter and 780kB of storage capacity per drive, which could be inserted into a box slightly larger than a washing machine, and where you could even revive the “computer” with a hammer blow when the relays were stuck…