RPI5 /dev/ttyAMA0 nicht ansprechbar?

[Otto123]

geht noch einfacher: Quelle https://di-marco.net/blog/it/2020-06-06-raspberry_pi_3_4_and_0_w_serial_port_usage/
Man kann die Schnittstelle mit sich selbst testen:
1. PIN 8 und 10  zur Sicherheit mit einem Widerstand ca. 700 Ohm verbinden (Wert ziemlich egal)
2. python module serial installieren

Code Auswählen Erweitern

sudo apt install python3-serial3. Script in Datei kopieren: z.B. nano serial_uart_test_TxRx.py

Code Auswählen Erweitern

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import serial
test_string = "Test serial port ...".encode('utf-8')
port_list = ["/dev/ttyAMA10","/dev/ttyAMA0","/dev/ttyS0","/dev/ttyS1"]
for port in port_list:
  try:
    serialPort = serial.Serial(port, 9600, timeout = 2)
    print ("Serial port", port, " ready for test :")
    bytes_sent = serialPort.write(test_string)
    print ("Sended", bytes_sent, "byte")
    loopback = serialPort.read(bytes_sent)
    if loopback == test_string:
      print ("Received ",len(loopback), "bytes. Port", port,"is OK ! \n")
    else:
      print ("Received incorrect data:", loopback, "on serial part", port, "loopback \n")
    serialPort.close()
  except IOError:
    print ("Error on", port,"\n")
4. Test starten

Code Auswählen Erweitern

python3 serial_uart_test_TxRx.py

[RalfRog]

geht noch einfacher:

Klar    (evtl. ist das IF reserviert wenn ne Console drauf liegt oder dort Bootmeldungen kommen)

Otto hatte weiter oben schon mal die Doku zitiert - da gibt es einen Abschnitt "UART konfigurieren":
https://www.raspberrypi.com/documentation/computers/configuration.html#configuring-uarts

Dort heisst es:

On the Raspberry Pi, one UART is selected to be present on GPIO 14 (transmit) and 15 (receive) - this is the primary UART. By default, this will also be the UART on which a Linux console may be present. Note that GPIO 14 is pin 8 on the GPIO header, while GPIO 15 is pin 10.

On Raspberry Pi 5, the primary UART appears on the Debug header

Wenn UART0 der Primary ist liegt er daher vermutlich nicht auf GPIO14/15 sondern als AMA10 auf dem Debug-Header. Vielleicht musst du zusätzlich noch den UART1 aktvieren, der dann auf GPIO14/15 landet.   
-> Schuss ins Blaue   "dtparam=uart1=on" in Kombination mit "dtoverlay=disable-bt"


Bzw. ein Stück weiter unten heisst es noch:

/dev/serial0 and /dev/serial1 are symbolic links which point to either /dev/ttyS0 or /dev/ttyAMA0.

On the Raspberry Pi 5, /dev/serial0 is a symbolic link that points to /dev/ttyAMA10.

Due to changes in Bookworm, /dev/serial1 does not exist by default. You can re-enable serial1 by setting the following values in config.txt:

dtparam=krnbt=off

Alles in Allem irgendwie nicht leicht zu überblicken.

[IPWF]

Statt ttyAMA0 kann man auch mal ttyS0 oder ttyS1 probieren.
Auf manchen RPi-kompatiblen Boards klappt es damit.

[RappaSan]

Gute Idee, ich such den USB-Adapter mal raus. Ist irgendwo in den Tiefen des Kellers...
Otto's python module serial  probiere ich dann als erstes aus (weniger Sucharbeit).

[RappaSan]

"On Raspberry Pi 5, the primary UART appears on the Debug header"
Wo soll der sein? Zwischen den beiden HDMI-Anschlüssen?

[RalfRog]

Ich denke ja. Hab ja keinen.
https://m.youtube.com/watch?v=kP2S3JUH-qk

[RappaSan]

Es sieht so aus, als wäre das addon-board unter die Räder gekommen.
Per minicom -b 38400 -o -D /dev/ttyAMA0 kommt beim V Befehl etwas zurück, aber es ist ein ziemliches durcheinander.
Andere Baudraten, Paritätswechsel oder Stopbits ändern nichts daran.
Im alten thread meinte locutus damals, das in so einem Fall der bootloader per ISP-Programmierer neu geflasht werden muß.
Also muß ich mir mit einem Arduino Nano erst mal ein solches Teil herstellen.

[RalfRog]

Hi
Da kommst du mit Ottos Hinweis (#15) bestimmt schneller zum Ziel (wenn nichts anderes die Schnittstelle in Beschlag nimmt).
Die Port-List probiert ja fix die relevanten /dev/tty's durch und RX/TX ist mal schnell mit nem Widerstand gebrückt.

Die Herausforderung ist vermutlich die richtigen dtparam/dtoverlay zu finden.
Beim querlesen im Forum der Raspberryseite wird  letzten Dezember beim Pi5 teilweise von Bugs in den Overlays berichtet.

Gruß Ralf

[RappaSan]

Ich hab das Board in einen funktionierenden Pi3 mit entsprechender älterer Software ausprobiert, dabei hat es sich eben herausgestellt, daß dieses add-on board keine verwertbare Kommunikation mehr bereitstellt, daher ist auch eine CUL initialisierung nicht mehr möglich.
Der minicom-check ergab nur noch Salat auf der Schnittstelle.
Das hier vorhandene 2. Board funktioniert auf gleichem Pi3 einwandfrei und liefert auch lesbare Antworten ab.
Mir ist nur rätselhaft, wie das alles passieren konnte - das Board wurde immer auf die richtigen Pins gesteckt, natührlich auch Stromlos.

[RappaSan]

Der bootloader des ATMEGA644-chips war tatsächlich platt.
Nach erneutem flashen per Arduino Nano und mithilfe des AVRDUDESS Programms konnte ich rpiaddon.hex neu aufspielen.
Allerdings tat sich FHEM schwer mit der Einstellung  der Baudrate.
Im Log immer die Meldung:
024.06.08 09:42:55 3: Setting CUL868 serial parameters to 38400,8,N,1
2024.06.08 09:43:04 1: Cannot init /dev/ttyAMA0, ignoring it (CUL868)

Ein Test mit minicom brachte auch keine lesbare Kommunikation zustande.
Erst als ich in minicom die Parameter mehrfach hin und zurück auf 38400 8N1 geschaltet habe, kam Klartext an.
minicom beendet und in FHEM nachgesehen.
Siehe da -initialized 

Im Log:
2024.06.08 09:58:56 0: Server started with 7 defined entities (fhem.pl:28849/2024-05-07 perl:5.036000 os:linux user:fhem pid:911)
2024.06.08 10:08:38 1: PERL WARNING: Use of uninitialized value $clock in string eq at ./FHEM/00_CUL.pm line 371.
2024.06.08 10:08:38 3: set CUL868 ITClock 250
2024.06.08 10:08:47 3: Setting CUL868 serial parameters to 38400,8,N,1
2024.06.08 10:08:47 1: /dev/ttyAMA0 disconnected, waiting to reappear (CUL868)
2024.06.08 10:09:51 3: Setting CUL868 serial parameters to 38400,8,N,1
2024.06.08 10:09:51 3: CUL868: Possible commands: ABbCEeFfGhIiKkLlMmNORTtUuVWXxYZz
2024.06.08 10:09:51 2: Setting CUL868 fhtid from 1034 to 1257
2024.06.08 10:09:51 1: /dev/ttyAMA0 reappeared (CUL868)

Seltsames Verhalten...

Nachtrag: Ein reboot hat alles wieder zunichte gemacht, Kommunikation ist wieder im Eimer.

[Wernieman]

Hört sich danach an, das die Config "hinne" ist, bzw. der GFlashSpeicher dazu. Kannst Du nochmals probieren, komplett neu zu flaschen?

[RappaSan]

Schon geschehen, keine Verbesserung.
Das Board auf einen Pi3 läuft dort.
Dann müßte der Pi5 eher hinne sein.
Für mich sieht:s so aus, als würde etwas die Initialisierung der Schnittstelle stören:
Setting CUL868 serial parameters to 38400,8,N,1
Cannot init /dev/ttyAMA0, ignoring it (CUL868)

[Wernieman]

Hast Du noch USB-Scan in FHEM drin?

[Otto123]

Hast Du mal meinen Vorschlag aus #12 verfolgt?

[RappaSan]

@Wernieman: Du meinst initialUsbCheck? Abgeschaltet bzw. auskommentiert.
@Otto: Hab ich versucht, aber ohne positiven Effekt.

Wie schon erwähnt sieht es für mich so aus, als würde die Baudrate nicht richtig gesetzt werden können.
Hab ja wie in#24 erwähnt es einmal !! hinbekommen, daß der CUL ordentlich lesbare Antworten ablieferte - ich weiß bis heute nicht wie das gelungen ist und das Verhalten reproduziert werden kann.
Man kann in minicom auch sehen, daß da etwas geantwortet wird, aber nichts in Klartext. Daher auch die Logmeldung "Cannot init /dev/ttyAMA0, ignoring it ".