Raspi 4B, HM_MOD_RPI_PCB auf uart4

Debian/Ubuntu basierte CCU

Moderator: Co-Administratoren

Antworten
mhzrh
Beiträge: 16
Registriert: 06.02.2020, 22:23

Raspi 4B, HM_MOD_RPI_PCB auf uart4

Beitrag von mhzrh » 11.04.2021, 14:25

Die Installation von debmatic auf dem Raspberry Pi mit einem Aufsteckmodul (HM_MOD_RPI_PCB) auf der GPIO Leiste, hat den Nachteil, dass der UART0 genutzt wird, und dadurch der integrierte Bluetooth Chip entweder deaktiviert werden muss, oder auf die miniuart verschoben werden muss. Bluetooth wird dadurch reduziert, und vor allem gibt es kein Flow-Control mehr, was für BLE Anwendungen bei mir doch etwas an Stabilität eingebüsst hat. Die Miniuart scheint sich hingegen nicht mit dem HM_MOD_RPI_PCB zu vertragen, zumindest wird eine Kernelmodul pl011_raw_uart geladen, was dies suggeriert, und ich habe es auch nicht hinbekommen. (Die Miniuart ist kein PL011).

Nun hat der RPI ja noch 4 weitere volle (PL011) UARTs. Prinzipiell sollte man also das Modul auch auf einer der anderen UARTs betreiben können.
Da die Sonne hier erst am Nachmittag rauskommt, habe ich das heute morgen mal umgesetzt :P und schreibe hier gerne eine Anleitung, falls noch jemand dieses Problem hat. Das Ganze funktioniert wegen des Pin-Layouts nur mit der HM_MOD_RPI_PCB Platine, also die, mit dem 2x6 Header zum Aufstecken am Ende der PCB Platine.
Mein OS: Raspian (5.10.17-v7l+), sollte aber mit jeder einigermassen modernen Kernel funktionieren.
Das ganze funktioniert ausschliesslich mit eine Pi 4B, da der 3 oder frühere Pis diese zusätzlichen UARTs nicht haben.

Man benötigt ebenso dazu einen Lötkolben und ein kleines Stück Draht, da man zwei der Header-Anschlüsse kurzschliessen muss.

Hardware:
Schaut man sich die Pinleiste des RPI an, z.B. hier: https://www.raspberrypi.org/documentation/usage/gpio/

So sieht das oben, wo man die Leiste normalerweise aufsteckt, folgendermassen aus:

Code: Alles auswählen

3V3	x x 	5V
GPIO 2	x x 	5V
GPIO 3	x x  	GND
GPIO 4 	x x  	GPIO 14 (TXD0/1)
GND	x x  	GPIO 15 (RXD0/1)
GPIO 17	x x  	GPIO 18
Dabei sind 3V3, beide GND Pins GPIO14 (RX), GPIO15 (TX) und GPIO18 (Reset) angeschlossen. Die restlichen Anschlüsse des 2x6 Headers der HM_MOD_RPI_PCB sind "not connected".

Zurück zum RPi, 8 "Zeilen" weiter unten am GPIO Header findet man folgende Konstellation:

Code: Alles auswählen

3V3		x x 	GPIO 24
GPIO 10		x x 	GND
GPIO 9 (RXD4)	x x  	GPIO 25
GPIO 11 	x x  	GPIO 8 (TXD4)
GND		x x  	GPIO 7
GPIO 0		x x  	GPIO 1
D.h. die 3V3 und GND auf der linken Seite (nicht rechts) würden passen. Ebenso passt auch der TXD4 -> RX Anschluss. (Man findet die Belegung z.B. im Manual des Raspberry PI 4, z.B. hier:https://www.raspberrypi.org/documentati ... minary.pdf)
Da die anderen Anschlüsse auf der HM....PCB Platine nicht verbunden sind, kann man also eine Brücke auf der Rückseite des 2x6 Headers einlöten, vom 3. Anschluss oben links zum zweituntersten auf der rechten Seite, also so:

Code: Alles auswählen

__________________________________________
				|x	x|
				|x	x|
				|o	x|
				|x	x|
				|x	o|
				|x	x|
__________________________________________
wenn man von der "Antennenseite" aus auf die Platine schaut. (Die Kreise sind verbunden, die Kreuze lässt man in Ruhe). Dies "fixt" den RXD4->TX Anschluss.

Wenn man die Platine dann an der entsprechenden Stelle weiter unten auf dem Raspberry Pi 4 aufsteckt, gut zählen ;)
Man kann sicherheitshalber mit einem Ohmmeter die beiden 3V3 Anschlüsse ausmessen, die sind kurzgeschlossen, auch im ausgeschalteten Zustand.

Software
Die Kernel-Module "finden" die Hardware mit einem Devicetree-Overlay, und zwar mit pivccu-raspberrypi.dts, welches man sich hier aus dem pivccu repository runterladen kann.

Code: Alles auswählen

wget https://raw.githubusercontent.com/alexreinert/piVCCU/master/dts/pivccu-raspberrypi.dts
Um dieses auf die UART4 anzupassen, muss folgendes geändert werden:
  • das "target" ist &uart4, nicht &uart0
  • der reset pin ist GPIO1, nicht GPIO18 (vgl. die beiden Layouts, oben
  • Sicherheitshalber setze ich in einem zusätzlichen Fragment die GPIOs 7 und 25 auf "Input", damit es keinen Kurzschluss gibt und sie einfach dem RXD4 bzw. GND folgen (GPIO 25 könnte man auch als Output auf GND setzen)
ich nenne mein modifiziertes overlay pivccu-raspberrypi-u4.dts und erhalte insgesamt folgenden Patch:

Code: Alles auswählen

>diff pivccu-raspberrypi.dts pivccu-raspberrypi-u4.dts
8c8
<     target = <&uart0>;
---
>     target = <&uart4>;
11c11
<       pivccu,reset_pin = <&gpio 18 0>;
---
>       pivccu,reset_pin = <&gpio 1 0>;
32a33,45
>       };
>     };
>   };
>   
>   fragment@2 {
>     target = <&gpio>;
>     __overlay__ {
>       pinctrl_names = "default";
>       pinctrl-0 = <&off_pins>;
> 
>       off_pins: off_pins {
>           brcm,pins = <7 25>;
>           brcm,function = <0 0>; /* input */
Dieses kompiliere ich mit

Code: Alles auswählen

dtc -@ -I dts -O dtb -W no-unit_address_vs_reg -o pivccu-raspberrypi-u4.dtbo pivccu-raspberrypi-u4.dts
Das entstandene dtbo-File kopiere ich dann als root nach /boot/overlays

im /boot/config.txt file benötige ich dann nur zwei Overlays und sonst keine Anpassungen:

Code: Alles auswählen

dtoverlay=uart4
dtoverlay=pivccu-raspberrypi-u4
(Einfach die beiden Zeilen unten in der Datei einfügen, Änderungen, die gemäss normaler Anleitung gemacht wurden (enable_uart=1, core_freq, miniuart-bt, etc.) auskommentieren oder löschen. ("Normale Anleitung" ist hier: https://github.com/alexreinert/debmatic ... berrypi.md)

/boot/cmdline.txt muss ebenfalls nicht angepasst werden.

Neustarten, fertig!
Bei Updates von pivccu-modules-raspberrypi oder pivccu-modules-dkms über apt muss man allerdings ein Auge darauf haben, dass nicht dtoverlay=pivccu-raspberrypi (also ohne 'u4') im /boot/config.txt ergänzt wird. Dies dann einfach wieder rauslöschen.

Benutzeravatar
deimos
Beiträge: 5383
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 949 Mal
Kontaktdaten:

Re: Raspi 4B, HM_MOD_RPI_PCB auf uart4

Beitrag von deimos » 11.04.2021, 14:58

Hi,

ein Nachteil der Lösung: Man ist mit dem Funkmodul noch näher am USB3 Controller und dessen Störstrahlung dran. Ich würde da im Zweifel eher zur HB-RF-USB-2 greifen, da hat man dann den gesamten GPIO Header frei und nimmt noch die Funkvorteile mit (Abstand zum Störsender alias Raspi und stabilisierte Versorgungsspannung).

Viele Grüße
Alex

mhzrh
Beiträge: 16
Registriert: 06.02.2020, 22:23

Re: Raspi 4B, HM_MOD_RPI_PCB auf uart4

Beitrag von mhzrh » 11.04.2021, 16:44

Ja, da hast Du wohl recht. Vor allem, wer sich neue Hardware zulegt, sollte das sicher so machen und über die USB gehen.
Ich hatte aber bisher noch nie gross Probleme mit dem Controller bei mir, entweder weil ich nichts am USB angeschlossen habe und/oder alles bei mir die Entfernungen nicht so gross sind.
Und es nervt mich, funktionierende Hardware zu entsorgen. Da verbringe ich liebe einen Sonntagvormittag mit Basteln :lol:

Benutzeravatar
deimos
Beiträge: 5383
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 949 Mal
Kontaktdaten:

Re: Raspi 4B, HM_MOD_RPI_PCB auf uart4

Beitrag von deimos » 11.04.2021, 16:52

Hi,

das Problem mit dem Neu Einbinden des original Device Tree Overlays könntest du vermeiden: Deinstallier einfach das Paket pivccu-modules-raspberrypi. Ggf. musst du dann die Header noch explizit nachinstallieren, damit die bei apt autoremove aufgrund der dann nicht mehr vorhandenen Abhängigkeit als nicht mehr notwendig betrachtet und gelöscht werden.

Und demnächst müsstest du dein Device Tree Overlay nochmals anpassen, ich habe da einige Sachen überarbeitet, welche in Github und im testing APT Repo bereits verfügbar sind. Das kommt die Tage auch nach stable.

Viele Grüße
Alex

mhzrh
Beiträge: 16
Registriert: 06.02.2020, 22:23

Re: Raspi 4B, HM_MOD_RPI_PCB auf uart4

Beitrag von mhzrh » 11.04.2021, 23:19

Cool, danke für den Hinweis

Matthias

Antworten

Zurück zu „debmatic“