raspberry pi 5 GPIO23 met script werkt niet

Waarom wil je zelf de DE/!RE pin zelf aansturen?

Daar gaat nooit op tijd werken, zeker niet met een script.

In linux wordt de DE/!RE pin in de (serial) driver aangestuurd met de juiste timing.

In de device tree staan als het goed is een paar keywords die de RS485 functionaliteit voor de betreffende UART enablen (als dat supported is).

Het lijkt er dus op dat je al support voor RS485 aan hebt staan met de betreffende GPIO pin, dan klopt het dat je een device busy krijgt want de driver heeft de GPIO geclaimed. Dus vergeet de directe aansturing maar, dat is niet de manier in linux.

In C moet je met een ioctl() call de wat specifieke RS485 functies enablen.Dat is bijvoorbeeld hoe de pin connected is: active low of high, wat timing dingetjes etc.
Zie https://docs.kernel.org/driver-api/serial/serial-rs485.html

In python moet je waarschijnlijk dan ook wat doen om zo te communiceren. Zijn vast wat methods in de uart class.

-edit- Ik ken de details van de RPi5 niet, heb je die RS485 buffer er zelf bij geknutseld of zit die op het (rpi) bord?
Waarschijnlijk moet je een devicetree overlay dan laden om het goed te krijgen.

Je moet een stuk nauwkeuriger zijn in je probleemomschrijving.

wanneer ik de python code vanuit een script start, zodanig dat de script na powerup start, krijg ik een error "GPIO busy"

- Welk script? Welke route om na powerup gelijk te starten (er zijn er 20)?
- Waar staat die error (logfile? Welke logfile? Terminal? glazen bol? AI interpretatie van het voorgaande?)
- Wat is de preciese formulering van de error.

hij kan de python code niet starten omdat de GPIO 23 bezet is

Strikt genomen is dit natuurlijk gel*l, de python interpreter kijkt niet naar GPIO, weet niet eens wat dat is.

Waarschijnlijk bedoel je dat ergens in je python-script een library-call niet werkt. Maar nu kijk ik in mijn glazen bol.

Welke call, welke library, laat je script zien. Wie is "hij"?

zat ik te denken aan een "workarround"

Gebruik een andere GPIO.

Als dat niet kan omdat een bestaande module voor RS485 gebruikt, vertel ons dan welke module.

Op zondag 29 maart 2026 11:32:38 schreef blurp:
Gebruik een andere GPIO.

Gaat niet werken in een script of je moet best wel traag de boel oversturen. Echt niet doen, er zijn betere manieren, zie mijn vorige post.

Je script (gebruiker die het start) heeft waarschijnlijk geen rechten op de GPIO. Probeer het eens als root.

ik kan even niet overal op reageren.

Op zondag 29 maart 2026 11:26:44 schreef henri62:
Waarom wil je zelf de DE/!RE pin zelf aansturen?

om dat ik dat bij de AVR's ook doe

Dus vergeet de directe aansturing maar, dat is niet de manier in linux.

dat vermoeden had ik ondertussen ook

-edit- Ik ken de details van de RPi5 niet, heb je die RS485 buffer er zelf bij geknutseld of zit die op het (rpi) bord?

die MAX3485 zit niet op het raspberry bord, dus bij geknutseld

Waarschijnlijk moet je een devicetree overlay dan laden om het goed te krijgen.[/quote]

In C moet je met een ioctl() call de wat specifieke RS485 functies enablen.Dat is bijvoorbeeld hoe de pin connected is: active low of high, wat timing dingetjes etc.
Zie https://docs.kernel.org/driver-api/serial/serial-rs485.html

In python moet je waarschijnlijk dan ook wat doen om zo te communiceren. Zijn vast wat methods in de uart class.

dat ga ik eens bekijken.

Op zondag 29 maart 2026 12:52:18 schreef trix:
[...Waarom wil je zelf de DE/!RE pin zelf aansturen?...]
om dat ik dat bij de AVR's ook doe

Dat was meer een retorische vraag

Als je zelf de buffer op een extra GPIO hebt gezet moet je eens kijken of je een shield kunt vinden waar ook een RS485 buffer op zit EN of er dan een devicetree overlay bij zit.
Die kun je dan verbouwen naar je correcte GPIO pin en die file dan op een of andere manier laden, hints hierover staan overal op het RPI forum, weet ik zo ook even niet uit mijn hoofd.

ik neig op het moment toch naar een hardware oplossing, er zijn blijkbaar RS485 IC's die de DE/RE niet nodig hebben. en dat is waarschijnlijk kleiner dan een shield.

MAX13487E is blijkbaar zo'n "autodirection" IC

Dat IC ken ik, maar dan moet je je hardware weer gaan verbouwen.

Het gaat niet om die shield, maar de overlay file die erbij zit. Dan kun je kijken hoe die overlay opgebouwd is zodat je die aan kunt passen voor jezelf.

[Bericht gewijzigd door henri62 op maandag 30 maart 2026 00:26:55 (18%)]

Ik heb het even bij elkaar geraapt wat er moet gebeuren.

Waarschijnlijk moet je device tree file er zo uitzien:

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2712";  // Pi 5 SoC

    fragment@0 {
        target = <&uart3>; // AANPASSEN naar jouw uart?
        __overlay__ {
            status = "okay";

            linux,rs485-enabled-at-boot-time;

            rs485-rts-active-high;
            rs485-rts-delay = <0 0>;

            rts-gpios = <&gpio 23 0>; // Jouw GPIO
        };
    };
};

Ik neem even aan dat je uart3 gebruikt, de file heet dan bijvoorbeeld rs485-uart3.dts.

Die moet je dan compileren met de devicetree compiler:

dtc -@ -I dts -O dtb -o rs485-uart3.dtbo rs485-uart3.dts

En copieren naar de overlays locatie:

sudo cp rs485-uart3.dtbo /boot/firmware/overlays/

In de file: /boot/firmware/config.txt

enable_uart=1
dtoverlay=uart#   # AANPASSEN naar jouw uart, bijvoorbeeld 3?

In python gebruik je denk ik de serial class, dan kun je dit daar doen om de serialport in RS485 mode te zetten met auto DE/RE:

serport.rs485_mode = serial.rs485.RS485Settings(
    rts_level_for_tx=True,
    rts_level_for_rx=False,
    delay_before_tx=0,
    delay_before_rx=0
)

Waar 'serport' natuurlijk de classnaam is die je gebruikt.

Als het niet werkt dan hoor ik het graag, pas ik het aan voor de volgende persoon die er tegenaan loopt.

ga ik vanavond testen, bedankt.

In python gebruik je denk ik de serial class, dan kun je dit daar doen om de serialport in RS485 mode te zetten met auto DE/RE:

je kan denk ik toch niet de seriele poort op een raspberry pi 5 in RS485 mode zetten. er zal toch altijd een uart ---> RS485 omzetter nodig zijn, die weer DE/RE pinnen heeft.

dit in "RS485 mode" zetten houd denk ik in dat er automatisch een pin hoog/laag word bij write/read.

[Bericht gewijzigd door trix op maandag 30 maart 2026 10:22:14 (14%)]

dit in "RS485 mode" zetten houd denk ik in dat er automatisch een pin hoog/laag word bij write/read.

Precies. En een Pi-5 zou dat out-of-the-box moeten kunnen, met één regeltje in /boot/firmware/config.txt:

dtoverlay=uart0,rs485

(misschien moet je uart0-pi5 hebben, ik heb geen pi5 om te testen. En kies juiste uart nummer)

En dan hoef je in je code verder niets te doen, de uart-HW van broadcom toggled netjes RTS voor je als ie gaat zenden. Net als je van de AVR gewend bent.

Herkenbaar verhaal! Ik ben sinds kort, komend van microcontrollers, ook bezig met raspberry pi. Jongens jongens. Wat ooit ingewikkeld was (bv remote access over internet) wordt nu simpel, EN helaas: wat simpel was (zoals een seriele bus), wordt nu toch een stuk ingewikkelder.

Een belangrijke oorzaak is dat de pi dus linux daait, met vele processen tegelijkertijd.
De kernel is de baas over hoe de processen de resources gebruiken.
Een IO Pin is een resource, en kan maar door 1 proces tegelijk gebruikt worden.
Een IO pin moet dus 'aangevraagd' worden. Die aanvraag lukt alleen als de pin 'vrij' is.

Als je een melding als 'IO pin busy' ziet dan lijkt het mij zeer waarschijnlijk dat er nog een ander proces deze pin bezet houdt.

Je kan dus bijvoorbeeld met "ps -aux | grep pio" uitzoeken of er een ander proces is dat over pio gaat. Met "kill -9 <pid>" kan je vervolgens hangende processen of daemons zoals "pigpiod" stoppen. En dan nogmaals je programma opstarten.

hey een lotgenoot ......succes.

ga ik straks ook eens proberen. bedankt.

nogmaals je programma opstarten

is bij mij reboot, programma moet gaan draaien bij power up.

Op maandag 30 maart 2026 14:07:04 schreef trix:
hey een lotgenoot ......succes.

ga ik straks ook eens proberen. bedankt.

[...]
is bij mij reboot, programma moet gaan draaien bij power up.

Ja helemaal goed, maar hak de olifant in stukken voor je hem opeet. Stap 1 is dus om je communicatie te laten lopen. En dan start / stop je vanaf de console, dus python <programmanaam>. Niet met reboot. Pas als dat werkt doe je Stap 2: het programma automatisch op laten starten, bijvoorbeeld via een systemd daemon.

Je moet wel zelf even kunnen bekijken of jouw programma 1 of 0 of 4 keer draait in het geheugen. Blijf niet te lang hangen in Thonny. Een editor als Nano en de command line brengen je ook een heel eind.

ja nano word ook gebruikt.

ik heb het ook met systemd geprobeerd, maar dat kreeg ik ook toen ook niet werkend.
het is redelijk wat gedoe (in ieder geval voor mij) wat ook met een ander IC is op te lossen.

kom er vandaag niet aan toe, word morgen.

Op maandag 30 maart 2026 10:02:13 schreef trix:
[...]
je kan denk ik toch niet de seriele poort op een raspberry pi 5 in RS485 mode zetten. er zal toch altijd een uart ---> RS485 omzetter nodig zijn, die weer DE/RE pinnen heeft.

Ja klopt, je moet nog steeds een transceiver hebben, maar ik neem aan dat je die al ergens op hebt zitten en aangesloten.

dit in "RS485 mode" zetten houd denk ik in dat er automatisch een pin hoog/laag word bij write/read.

Precies! Out of the box zou dat (als je devicetree klopt) die gpio pin mee moeten togglen met de transmit van seriele data. Wordt door de devicedriver of het serial framework geregeld.

Het kan zijn dat je het level andersom moet zetten in de devicetree file. Ligt eraan hoe je de pin aangesloten hebt. Eventueel met een scoop tzt checken of het klopt.

Wat 'blurp' zegt is niet helemaal correct, dat is mooi als de chip op het cpu board zelf zit en de fabrikant er al een correcte devicetree bij gemaakt heeft.
Of als je een shield hebt die redelijk standaard is, en er is in die overlays directory al een file met de juiste settings (sommige shields hebben een eeprom met de bijbehorende overlay file).

Waarschijnlijk is daar geen enkele file correct met de juiste GPIO definitie er in. Dat is wat onhandiger te controleren omdat het compiled files zijn. DIe kun je met dtc wee decompilen om ze te bekijken.

Waarschijnlijk is daar geen enkele file correct met de juiste GPIO definitie er in.

Integendeel. Welke pin voor DE gebruikt wordt ligt vast (altijd RTS). Dus waarschijnlijk is elke overlay goed, want het hangt niet af van hoe de RX485 level converter aangesloten is welke pin je moet gebruiken.

Op dinsdag 31 maart 2026 08:23:24 schreef blurp:
[...]

Integendeel. Welke pin voor DE gebruikt wordt ligt vast (altijd RTS).

Dat is niet helemaal correct, als je de hardware functionaliteit van de UART wilt gebruiken is het gedeeltelijk waar. Verschillende ALT functies van de pinmux kunnen gebruikt worden dan zijn er een beperkt aantal mogelijkheden. Het ligt eraan welke pinnen precies uitbedraad zijn op de header en of die hier een andere dubbelfunctie hebben. Is altijd een beetje een puzzel.

Dat ligt eraan hoe je ALT functies gemapped zijn in de overlay(s). De vraag is of die betreffende pin (of pins, kunnen er meerdere zijn) vrij is (denk het wel anders hebben ze bij de RPI dat wel een beetje dom gemaakt).
Dus welke GPIO dat precies is moet ik ook opzoeken.

Is dat niet GPIO23 is, heb je pech en moet je dus je aansluiting veranderen naar de pin die er wel bij hoort, dan kun je een standaard overlay gebruiken.
Dat is inderdaad wel de beste methode want de hardware van de UART doet dan het werk.

Wat ik zo snel kan vinden:

Voor UART0 vind ik dat het GPIO17 blijkbaar is. Is niet op de 40-pin header beschikbaar volgens mij? -> Wel dus, dan zou je die moeten gebruiken. GPIO14/15 + GPIO17.

Voor UART3 is de (hardware mappable) RTS NIET op de 40-pin header bedraad helaas, dus kun je een standard overlay vergeten.

Je kunt wel een andere GPIO overriden, maar dat doet de kernel het voor je, dat is minder effectief.

@trix GPIO23 is ongeveer de slechtste keuze om je DE aan te sluiten, die kun je nergens fatsoenlijk naar mappen. Dus als je al een PCB hebt gemaakt moet je de software override gebruiken.

GPIO 23 was ook gewoon uit de lucht gegrepen,...niet bij nagedacht, dat er "goede & slechte" pinnen zijn.

Heb je een breadboard gemaakt of hoe zit het aangesloten? Kun je dat nog veranderen?

nee op een PCB, maar die moet nog wel een keer worden gewijzigd.
maar ik neig toch naar een hardware oplossing. dan is het later ook eenvoudiger als ik moet switchen naar een andere raspberry.

wat ik moet versturen over de TX is altijd 3 bytes met 9600 baud, dan 248 bytes ontvangen vervolgens weer 3 bytes verzenden, dus dat is allemaal niet zo spannend.

[Bericht gewijzigd door trix op woensdag 1 april 2026 08:15:19 (30%)]

Dan is de beste oplossing nu: een overlay maken voor jouw config.

En dat "niet spannend", gaat zo dadelijk toch spannend worden. Zit geen handshake op is ik weet uit ervaring dat zoiets faliekant de mist in kan gaan.

handshake,...iets met de klok en de klepel, leesvoer dus

wat gelezen, dat moet dan een software handshake worden, anders weer GPIO "gedoe" met de raspberry. omdat ik weet hoeveel bytes er precies over de Tx pin en RX pin gaan.
eerst 3 bytes voor verzoek: stuur data naar mij, dan komt een vaste tijd later de 248 bytes binnen.
zo kan het "bijna" niet fout gaan, ik controleer namelijk op het aantal ontvangen bytes, als dit niet klopt (wat ik nog niet heb mee gemaakt) dan vraag ik de data nog een keer.