ik ga hier maar verder met he volgende probleem (de wet van behoud van ellende).
dat GPIO gebeuren is opgelost, ik gebruik geen GPIO meer.
dus nu kan ik mooi verder testen met de scripts en kom het volgende probleem tegen:
ik maak op de raspberry pi 5 gebruik van 3 uarts
uart2 op pin 7 en 29
uart3 op pin 24 en 21
uart4 op pin 32 en 33
en ook hier geld, het werk goed als ik het programma vanuit thonny run, maar het gaat fout wanneer ik dezelfde code start met een script die start na reboot.
en dit heeft mischien te maken met de verkeerde pinnen toe kennen aan de uart's.
volgens chatgpt zouden andere pinnen (die eigenlijk standaard) zijn moeten worden toegekend aan de uart's:
uart2 op pin 27 en 28
uart3 op pin 7 en 29
uart4 op pin 24 en 21
weet iemand of dit klopt, en dat je zo wel vanuit een script kan starten ?
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Hoe start je dat script op bij boot? Wat heb je waar in gezet?
Wat zijn de exacte namen van die uarts (/dev/tty####)?
En "het werkt niet/het gaat fout" daar heb je niet veel aan, wat werkt er niet, foutmelding oid?
veel is gemaakt met AI, ik ben hier zelf niet zo bedreven in.
hoe het zou moeten werken:
ik heb een raspberry pi 5 die verbonden is met een AVR128DB48.
hiertussen zit een uart:
- uart3
in de AVR heb ik een commando line geschreven die een comando naar de raspberry stuurt over de raspberry uart3.
nu heb ik in de raspberry een python code gemaakt die,
als de raspberry dat commando ontvangt er data in een text file word geschreven.
en later word er vanuit die file met een ander python code in de raspberry een plot gemaakt (grafische weergave).
als ik zonder scripts na reboot test werkt alles naar behoren, ik moet dan vanuit thonny wel 2 x een code runnen:
1e om o.a. de data van de AVR128DB48 te lezen.
2e om de code te starten die de plot maakt.
dat wil ik dus automatiseren.
dat automatiseren met scripts word met systemd gedaan, er zijn blijkbaar ook andere mogelijkheden.
hieronder wat ik zoal heb gedaan:
dus ik heb een " wrapper" gemaakt die (AI text):
- wacht tot bepaalde hardware klaar is (zoals UART3)
- controleert of een bestand of device bestaat
- stelt de juiste omgeving in
- en start daarna pas jouw echte Python?script
GNU nano 8.4 /home/sravo/start_rasp.sh
#!/bin/bash
# 1. Wacht tot het device bestaat
while [ ! -e /dev/ttyAMA3 ]; do
sleep 1
done
# 2. Wacht tot de poort open kan
opened=0
while [ $opened -eq 0 ]; do
python3 - << 'EOF'
import serial
try:
s = serial.Serial('/dev/ttyAMA3', 9600, timeout=0.1)
print("OK")
except:
pass
EOF
if [ $? -eq 0 ]; then
opened=1
else
sleep 1
fi
done
# 3. Extra wachttijd voor stabiliteit
sleep 2
# 4. Start jouw echte script
exec /usr/bin/python3 /home/sravo/Documenten/python/sravo_comp/rasp_comp_6/rasp>
^G Hulp ^O Opslaan ^F Zoeken ^K Knippen ^T Opdracht ^C Positie
^X Afsluiten ^R Inlezen ^\ Vervangen ^U Plakken ^J Uitvullen ^/ Naar regeleen service script:
GNU nano 8.4 /etc/systemd/system/rasp_main.service
[Unit]
Description=Raspberry Pi main data writer
After=network-online.target multi-user.target dev-serial0.device
Wants=network-online.target
[Service]
User=sravo
Group=dialout
WorkingDirectory=/home/sravo/Documenten/python/sravo_comp/rasp_comp_6
ExecStartPre=/bin/sleep 3
ExecStart=/home/sravo/start_rasp.sh
Restart=always
Environment="PYTHONUNBUFFERED=1"
Environment="HOME=/home/sravo"
Environment="PATH=/usr/bin:/usr/local/bin"
[Install]
WantedBy=multi-user.target
[ 19 regels gelezen ]
^G Hulp ^O Opslaan ^F Zoeken ^K Knippen ^T Opdracht ^C Positie
^X Afsluiten ^R Inlezen ^\ Vervangen ^U Plakken ^J Uitvullen ^/ Naar regel
een config.txt:
GNU nano 8.4 /boot/firmware/config.txt
# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
# Additional overlays and parameters are documented
# /boot/firmware/overlays/README
# Automatically load overlays for detected cameras
camera_auto_detect=1
# Automatically load overlays for detected DSI displays
display_auto_detect=1
# Automatically load initramfs files, if found
auto_initramfs=1
# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2
# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1
# Run in 64-bit mode
arm_64bit=1
# Disable compensation for displays with overscan
disable_overscan=1
# Run as fast as firmware / board allows
arm_boost=1
[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1
[cm5]
dtoverlay=dwc2,dr_mode=host
[all]
dtoverlay=disable-bt
dtparam=spi=off
dtoverlay=uart2
dtoverlay=uart3,txd3_pin=24,rxd3_pin=21
dtoverlay=uart4,txd4_pin=12,rxd4_pin=13
dtparam=uart0=on
^G Hulp ^O Opslaan ^F Zoeken ^K Knippen ^T Opdracht ^C Positie
^X Afsluiten ^R Inlezen ^\ Vervangen ^U Plakken ^J Uitvullen ^/ Naar regel
Ik neem aan dat je systemd netjes verteld hebt om je service te starten?
(post bij twijfel de output van:
sudo systemctl status rasp_main)
Dan is de volgende vraag wat zegt journalctl?
sudo journalctl -b -0 -u rasp_mainDe daaropvolgende stap is dat je logging statements (echo "ben nu hier" >> rasp_main.log) toevoegt om te kijken of je script/programma voortgang is zoals je verwacht.
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
En enablen
sudo systemctl enable rasp_mainja dat doe ik inderdaad.
maar maakt het wat uit welke pinnen ik toeken aan de uart ?
ik begin me nu te realiseren dat zo'n script toch op een andere manier werkt als ik verwacht.
ik verwacht dat zo'n script eigenlijk de code uitvoert zoals thonny dat doet, dus inclusief de gebruikte library's en zo.
maar ik begin nu te denken dat je met een script eigenlijk de python code in de terminal uit voert. dus dan gebruikt hij niet automatisch de library's, en moet je alles GPIO en UART's zelf instellen = gedoe.
je zou net als in excel een macro (of het heet anders) moeten kunnen opnemen, je drukt op "record" (je moet wat ouder zijn om te weten dat dat vroeger op een casette recorder zat) je muis bewegingen en muis klikken worden op genomen, en die speel je na een reboot af.
Op maandag 6 april 2026 13:34:09 schreef trix:
ik begin me nu te realiseren dat zo'n script toch op een andere manier werkt als ik verwacht.
ik verwacht dat zo'n script eigenlijk de code uitvoert zoals thonny dat doet, dus inclusief de gebruikte library's en zo.
maar ik begin nu te denken dat je met een script eigenlijk de python code in de terminal uit voert. dus dan gebruikt hij niet automatisch de library's, en moet je alles GPIO en UART's zelf instellen = gedoe.
Nee, in principe zal thonny geen libraries voor je laden en GPIO voor je instellen.
Je python script doet precies hetzelfde vanuit thonny als vanuit een door systemd gestrart shell-script.
Dan kun je makkelijk testen: Open een terminal en start je python script.
henri62
1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
Beter:
sh -c scriptnaamDan krijgt je een "kale" shell. En dat zal wel niet werken door paden die niet kloppen.
Op maandag 6 april 2026 10:07:57 schreef trix:
veel is gemaakt met AI, ik ben hier zelf niet zo bedreven in.
<knip>GNU nano 8.4 /home/sravo/start_rasp.sh <knip> while [ $opened -eq 0 ]; dopyth python3 - << 'EOF' import serial try: s = serial.Serial('/dev/ttyAMA3', 9600, timeout=0.1) print("OK") except: pass EOF if [ $? -eq 0 ]; then opened=1 else sleep 1 fi done
Ik heb hier een beetje moeite mee. Volgens mij geeft te python interpreter altijd '0' als return value, tenzij:
- er een andere waarde aan sys.exit() word gegeven (hier niet van toepassing)
- er een onafgehandele fout optreed (hier ook niet van toepassing door de expect: pass combi)
Dus deze hele test is bogus, en test helemaal niets! AI code?
inderdaad
Op maandag 6 april 2026 15:07:04 schreef blurp:
[...]Nee, in principe zal thonny geen libraries voor je laden en GPIO voor je instellen.
Je python script doet precies hetzelfde vanuit thonny als vanuit een door systemd gestrart shell-script.Dan kun je makkelijk testen: Open een terminal en start je python script.
waarom werkt het dan b.v. met de gpio niet 
[Bericht gewijzigd door trix op (96%)]
interessant document gevonden, moet het nog door lezen, is voor de raspberry.
Running A Program At Start UP
A Beginner's Guide
Op maandag 6 april 2026 18:21:49 schreef trix:
inderdaad[...]
waarom werkt het dan b.v. met de gpio niet
Als het dan niet werkt is dat de eerste plek om het uit te zoeken. Zorg dat het python-script werkt vanuit de terminal. Als dat niet lukt zal het vanuit boot ook niet werken.
KGE
Golden Member
Is een USB naar RS485 adapter geen oplossing? Die regelen zelf RX/TX en naar de computer/Pi toe is het gewoon een USB UART
ik weet niet of dat ook gaat,
dan gaat het van RS485 naar USB,
i.p.v. RS485 naar UART.
nu is USB natuurlijk ook wel een seriele poort, maar of dat dan ook UART is weet ik zo niet
en eigenlijk liever geen losse adapter maar een oplossing voor op de PCB, al zal dat ook wel mogelijk zijn.
Deze site heeft wel wat leuke "Reference designs"
Moet het peersee RS485 zijn?
Als je alles zelf maakt, dan kun je (bijna) net zo goed CAN bus transceivers gebruiken i.p.v. RS485. Bij CAN transceivers heb je geen signaal nodig om de richting om te schakelen.
Je kunt een RS485 transceiver ook (ongeveer) als een CAN transceiver mistbruiken door de "data uitgang" van je microcontroller op de de DE pin van de RS485 transceiver aan te sluiten. Je moet dan ook nog een "failsafe bias" met wat weerstanden maken, zodat de bus een goed gedefineerd "uit" signaal heeft voor de tijd dat alle drivers uit staan.
KGE
Golden Member
Op woensdag 10 juni 2026 19:52:43 schreef trix:
ik weet niet of dat ook gaat,
dan gaat het van RS485 naar USB,
i.p.v. RS485 naar UART.nu is USB natuurlijk ook wel een seriele poort, maar of dat dan ook UART is weet ik zo niet
en eigenlijk liever geen losse adapter maar een oplossing voor op de PCB, al zal dat ook wel mogelijk zijn.
Vanuit de Pi gezien is zo'n USB-RS485 adapter gewoon een /dev/ttyUSBx of /dev/ttyACMx device. Toevallig afgelopen week met zoiets bezig geweest om een ModBus apparaat aan te sturen vanuit een C programma.