RPI4 CM /dev/ttyAMA0 lijkt niet te werken.

[bucovaina89]

Ik heb een WaveShare CM4-ETH-RS485-BASE-B gekocht om verschillende modbus devices uit te lezen. Nu heb ik een Alvin water niveau sensor erop aangesloten maar via /dev/ttyAMA0 krijg ik die sensor maar niet uitgelezen. Als ik dan met een modbus-USB adapter probeer (A/B exact hetzelfde aangesloten maar dan op de modbus-USB adapter) werkt het wel meteen. Ik heb de wiki gevolgd (link) maar dat werkt ook niet.

code:

root@stats2:~# grep uart /boot/config.txt 
dtoverlay=uart0
dtoverlay=uart3
dtoverlay=uart4
dtoverlay=uart5
enable_uart=1
root@stats2:~# cat /boot/cmdline.txt 
console=tty1 root=PARTUUID=ae700d28-02 rootfstype=ext4 fsck.repair=yes rootwait plymouth.ignore-serial-consoles
root@stats2:~#

code:

root@stats2:~# ls -lah /dev/ttyAMA*
crw-rw---- 1 root dialout 204, 64 Sep 29 06:36 /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 65 Sep 29 06:33 /dev/ttyAMA1
crw-rw---- 1 root dialout 204, 66 Sep 29 06:33 /dev/ttyAMA2
crw-rw---- 1 root dialout 204, 67 Sep 29 06:33 /dev/ttyAMA3
root@stats2:~# ls -lah /dev/serial*
lrwxrwxrwx 1 root root 7 Sep 29 06:33 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Sep 29 06:33 /dev/serial1 -> ttyS0
root@stats2:~#

code:

root@stats2:~# mbpoll  -P none -s 1 -d 8 -1 -a 1 -t 4 -c 15 -o 10 /dev/ttyAMA0 -r 1 -b 9600
mbpoll 1.0-0 - FieldTalk(tm) Modbus(R) Master Simulator
Copyright © 2015-2019 Pascal JEAN, https://github.com/epsilonrt/mbpoll
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'mbpoll -w' for details.

Protocol configuration: Modbus RTU
Slave configuration...: address = [1]
                        start reference = 1, count = 15
Communication.........: /dev/ttyAMA0,       9600-8N1 
                        t/o 10.00 s, poll rate 1000 ms
Data type.............: 16-bit register, output (holding) register table

-- Polling slave 1...
Read output (holding) register failed: Connection timed out

root@stats2:~#

(timeout op de usb-modbus adapter is minimaal 0.03s dus 10s lijkt me erg royaal.

Het zou GPIO14/15 moeten zijn

code:

root@stats2:~# raspi-gpio get 
BANK0 (GPIO 0 to 27):
GPIO 0: level=1 fsel=0 func=INPUT pull=UP
GPIO 1: level=1 fsel=0 func=INPUT pull=UP
GPIO 2: level=1 fsel=0 func=INPUT pull=UP
GPIO 3: level=1 fsel=0 func=INPUT pull=UP
GPIO 4: level=1 fsel=3 alt=4 func=TXD3 pull=NONE
GPIO 5: level=1 fsel=3 alt=4 func=RXD3 pull=UP
GPIO 6: level=1 fsel=0 func=INPUT pull=UP
GPIO 7: level=0 fsel=0 func=INPUT pull=UP
GPIO 8: level=1 fsel=3 alt=4 func=TXD4 pull=NONE
GPIO 9: level=1 fsel=3 alt=4 func=RXD4 pull=UP
GPIO 10: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 11: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 12: level=1 fsel=3 alt=4 func=TXD5 pull=NONE
GPIO 13: level=1 fsel=3 alt=4 func=RXD5 pull=UP
GPIO 14: level=1 fsel=4 alt=0 func=TXD0 pull=NONE
GPIO 15: level=1 fsel=4 alt=0 func=RXD0 pull=UP
GPIO 16: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 17: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 18: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 19: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 20: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 21: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 22: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 23: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 24: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 25: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 26: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 27: level=0 fsel=0 func=INPUT pull=DOWN
BANK1 (GPIO 28 to 45):
GPIO 28: level=1 fsel=2 alt=5 func=RGMII_MDIO pull=UP
GPIO 29: level=0 fsel=2 alt=5 func=RGMII_MDC pull=DOWN
GPIO 30: level=1 fsel=0 func=INPUT pull=UP
GPIO 31: level=1 fsel=0 func=INPUT pull=NONE
GPIO 32: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 33: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 34: level=0 fsel=7 alt=3 func=SD1_CLK pull=NONE
GPIO 35: level=1 fsel=7 alt=3 func=SD1_CMD pull=UP
GPIO 36: level=1 fsel=7 alt=3 func=SD1_DAT0 pull=UP
GPIO 37: level=1 fsel=7 alt=3 func=SD1_DAT1 pull=UP
GPIO 38: level=1 fsel=7 alt=3 func=SD1_DAT2 pull=UP
GPIO 39: level=1 fsel=7 alt=3 func=SD1_DAT3 pull=UP
GPIO 40: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 41: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 42: level=0 fsel=1 func=OUTPUT pull=DOWN
GPIO 43: level=1 fsel=0 func=INPUT pull=DOWN
GPIO 44: level=1 fsel=0 func=INPUT pull=NONE
GPIO 45: level=1 fsel=0 func=INPUT pull=NONE
BANK2 (GPIO 46 to 53):
GPIO 46: level=0 fsel=0 func=INPUT pull=UP
GPIO 47: level=0 fsel=0 func=INPUT pull=UP
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK pull=DOWN
GPIO 49: level=0 fsel=4 alt=0 func=SD0_CMD pull=DOWN
GPIO 50: level=0 fsel=4 alt=0 func=SD0_DAT0 pull=DOWN
GPIO 51: level=0 fsel=4 alt=0 func=SD0_DAT1 pull=DOWN
GPIO 52: level=0 fsel=4 alt=0 func=SD0_DAT2 pull=DOWN
GPIO 53: level=0 fsel=4 alt=0 func=SD0_DAT3 pull=DOWN
root@stats2:~#

De behuizing heeft LEDs voor TX en RX activiteit op elke modbus connectie. Ik zie op de correcte RS485 connector activiteit op de TX LED, maar nooit RX. De water niveau sensor antwoordt dus niet als hij op de "dedicated" connectoren van de behuizing hangt. Maar dus wél als hij op die USB adapter hangt. De sensor werkt dus en het commando dat ik uitvoer heeft de correcte argumenten om de sensor uit te lezen.

Ik vermoed dat er ergens iets mis is met de seriële/GPIO setup maar ik weet bij god niet wat.

Hier staat nog "DOWN" bij beide pins die ik "nodig" heb. Geen idee wat die "DOWN" betekent.

code:

root@stats2:~# raspi-gpio funcs
GPIO, DEFAULT PULL, ALT0, ALT1, ALT2, ALT3, ALT4, ALT5
0, UP, SDA0, SA5, PCLK, SPI3_CE0_N, TXD2, SDA6
1, UP, SCL0, SA4, DE, SPI3_MISO, RXD2, SCL6
2, UP, SDA1, SA3, LCD_VSYNC, SPI3_MOSI, CTS2, SDA3
3, UP, SCL1, SA2, LCD_HSYNC, SPI3_SCLK, RTS2, SCL3
4, UP, GPCLK0, SA1, DPI_D0, SPI4_CE0_N, TXD3, SDA3
5, UP, GPCLK1, SA0, DPI_D1, SPI4_MISO, RXD3, SCL3
6, UP, GPCLK2, SOE_N_SE, DPI_D2, SPI4_MOSI, CTS3, SDA4
7, UP, SPI0_CE1_N, SWE_N_SRW_N, DPI_D3, SPI4_SCLK, RTS3, SCL4
8, UP, SPI0_CE0_N, SD0, DPI_D4, I2CSL_CE_N, TXD4, SDA4
9, DOWN, SPI0_MISO, SD1, DPI_D5, I2CSL_SDI_MISO, RXD4, SCL4
10, DOWN, SPI0_MOSI, SD2, DPI_D6, I2CSL_SDA_MOSI, CTS4, SDA5
11, DOWN, SPI0_SCLK, SD3, DPI_D7, I2CSL_SCL_SCLK, RTS4, SCL5
12, DOWN, PWM0_0, SD4, DPI_D8, SPI5_CE0_N, TXD5, SDA5
13, DOWN, PWM0_1, SD5, DPI_D9, SPI5_MISO, RXD5, SCL5
14, DOWN, TXD0, SD6, DPI_D10, SPI5_MOSI, CTS5, TXD1
15, DOWN, RXD0, SD7, DPI_D11, SPI5_SCLK, RTS5, RXD1
16, DOWN, -, SD8, DPI_D12, CTS0, SPI1_CE2_N, CTS1
17, DOWN, -, SD9, DPI_D13, RTS0, SPI1_CE1_N, RTS1
18, DOWN, PCM_CLK, SD10, DPI_D14, SPI6_CE0_N, SPI1_CE0_N, PWM0_0
19, DOWN, PCM_FS, SD11, DPI_D15, SPI6_MISO, SPI1_MISO, PWM0_1
20, DOWN, PCM_DIN, SD12, DPI_D16, SPI6_MOSI, SPI1_MOSI, GPCLK0
21, DOWN, PCM_DOUT, SD13, DPI_D17, SPI6_SCLK, SPI1_SCLK, GPCLK1
22, DOWN, SD0_CLK, SD14, DPI_D18, SD1_CLK, ARM_TRST, SDA6
23, DOWN, SD0_CMD, SD15, DPI_D19, SD1_CMD, ARM_RTCK, SCL6
24, DOWN, SD0_DAT0, SD16, DPI_D20, SD1_DAT0, ARM_TDO, SPI3_CE1_N
25, DOWN, SD0_DAT1, SD17, DPI_D21, SD1_DAT1, ARM_TCK, SPI4_CE1_N
26, DOWN, SD0_DAT2, -, DPI_D22, SD1_DAT2, ARM_TDI, SPI5_CE1_N
27, DOWN, SD0_DAT3, -, DPI_D23, SD1_DAT3, ARM_TMS, SPI6_CE1_N
28, NONE, SDA0, SA5, PCM_CLK, -, MII_A_RX_ERR, RGMII_MDIO
29, NONE, SCL0, SA4, PCM_FS, -, MII_A_TX_ERR, RGMII_MDC
30, DOWN, -, SA3, PCM_DIN, CTS0, MII_A_CRS, CTS1
31, DOWN, -, SA2, PCM_DOUT, RTS0, MII_A_COL, RTS1
32, DOWN, GPCLK0, SA1, -, TXD0, SD_CARD_PRES, TXD1
33, DOWN, -, SA0, -, RXD0, SD_CARD_WRPROT, RXD1
34, UP, GPCLK0, SOE_N_SE, -, SD1_CLK, SD_CARD_LED, RGMII_IRQ
35, UP, SPI0_CE1_N, SWE_N_SRW_N, -, SD1_CMD, RGMII_START_STOP, -
36, UP, SPI0_CE0_N, SD0, TXD0, SD1_DAT0, RGMII_RX_OK, MII_A_RX_ERR
37, DOWN, SPI0_MISO, SD1, RXD0, SD1_DAT1, RGMII_MDIO, MII_A_TX_ERR
38, DOWN, SPI0_MOSI, SD2, RTS0, SD1_DAT2, RGMII_MDC, MII_A_CRS
39, DOWN, SPI0_SCLK, SD3, CTS0, SD1_DAT3, RGMII_IRQ, MII_A_COL
40, DOWN, PWM1_0, SD4, -, SD1_DAT4, SPI0_MISO, TXD1
41, DOWN, PWM1_1, SD5, -, SD1_DAT5, SPI0_MOSI, RXD1
42, DOWN, GPCLK1, SD6, -, SD1_DAT6, SPI0_SCLK, RTS1
43, DOWN, GPCLK2, SD7, -, SD1_DAT7, SPI0_CE0_N, CTS1
44, NONE, GPCLK1, SDA0, SDA1, -, SPI0_CE1_N, SD_CARD_VOLT
45, NONE, PWM0_1, SCL0, SCL1, -, SPI0_CE2_N, SD_CARD_PWR0
46, UP, SDA0, SDA1, SPI0_CE0_N, -, -, SPI2_CE1_N
47, UP, SCL0, SCL1, SPI0_MISO, -, -, SPI2_CE0_N
48, UP, SD0_CLK, -, SPI0_MOSI, SD1_CLK, ARM_TRST, SPI2_SCLK
49, UP, SD0_CMD, GPCLK0, SPI0_SCLK, SD1_CMD, ARM_RTCK, SPI2_MOSI
50, UP, SD0_DAT0, GPCLK1, PCM_CLK, SD1_DAT0, ARM_TDO, SPI2_MISO
51, UP, SD0_DAT1, GPCLK2, PCM_FS, SD1_DAT1, ARM_TCK, SD_CARD_LED
52, UP, SD0_DAT2, PWM0_0, PCM_DIN, SD1_DAT2, ARM_TDI, -
53, UP, SD0_DAT3, PWM0_1, PCM_DOUT, SD1_DAT3, ARM_TMS, -
root@stats2:~#

En dit staat ook op de wiki pagina, maar ik begrijp er helemaal niets van. Ook geen idee of ik iets aan die weerstanden zou moeten veranderen.

Note: the default mode is semi-automatic, which requires program control of transceiver mode; The 0R resistor on the back can be modified if automatic sending and receiving is required.

Mode switching: each channel is controlled by two 0R resistors.
Semi-automatic mode: the 0R resistor is on the "Semi-auto" end, and the user program controls the transceiver mode.
Full-automatic mode: The 0R resistor is on the "Full-auto" end, and the transceiver mode is automatically switched according to the transmission direction.

Nog een Edit: Ik draai Debian 11.3 (Niet Raspbian). Misschien kan dat ermee te maken hebben dat de UART moeilijk doet?

[ Voor 28% gewijzigd door bucovaina89 op 29-09-2022 16:01 ]

[bucovaina89]

En nog een kleine update. Ik heb nu 2 usb - modbus adapters aan op de usbpoorten aangesloten en een echo/cat gedaan van /dev/ttyUSB0 naar /dev/ttyUSB1 (A+/B- tussen de 2 connectors verbonden met een kabeltje uiteraard). Ik krijg gibberish terug, maar op zich, er komt data door dus dat werkt. Doe ik hetzelfde op /dev/ttyAMA0 > /dev/ttyAMA1 (de onboard RS485 poorten), ... niets ... Buiten dan de TX LED van /dev/ttyAMA0. Die merkt wel dat er activiteit is. Maar RX van /dev/ttyAMA1 gaat niet aan.

code:

echo "test" > /dev/ttyAMA0 #in terminal 1
cat < /dev/ttyAMA1         # in terminal 2

Om maar te zeggen, de hardware die ik aansluit lijkt te werken. De onboard RS485 poorten om een of andere reden niet.

[SA007]

Dat stuk over semi-automatic mode is erg belangrijk.

Je usb adapter staat altijd op de 'full auto' mode, deze staat standaard op semi-auto.

De namen zijn onzinnig, in de schema's heet dit TXDEN, maar dat houdt in dat je met gpio pinnen schakelt tussen zenden en ontvangen op die poort.
Uit het schema haal ik:
TXDEN_COM0 = GPIO10
TXDEN_COM1 = GPIO27
TXDEN_COM2 = GPIO7
TXDEN_COM3 = GPIO21

Standaard zijn deze 3.3V via een pull-up en dat is wel zenden/niet ontvangen.
Je zal dus een gpio moeten bedienen om te kunnen ontvangen of de jumpers omsolderen.

[bucovaina89]

@SA007 : HELD!!

In een gok dat het dat misschien was heb ik die weerstanden al proberen om te solderen maar ik krijg ze er niet af (hamermethode daar gelaten). Ik heb mijn soldeerbout al op 450 graden gezet maar er komt geen soldeersel in het lint, het wil dus niet smelten. Ofwel is mijn techniek fout, ofwel is er speciaal soldeersel gebruikt. Ik gok op techniek fout.

Of alternatief: wat bedoel je juist met de gpio "bedienen"? Hoe doe ik dat?

[bucovaina89]

@SA007 : je bent effectief een held , de boel omgesoldeerd en hup, het werkt



Ik moet duidelijk nog wel werken aan mijn SMD soldeertechniek want echt elegant ziet mijn gesoldeer er niet uit

[bucovaina89]

En misschien nog een vraagje, wat is dan het nut van semi-automatic? Welk device werkt daar dan beter mee?

Edit: typo

[ Voor 6% gewijzigd door bucovaina89 op 01-10-2022 08:27 ]

[SA007]

Het verschil is de tijd waarin je tussen zenden/ontvangen kan schakelen.

Dus bij slaves die heel snel reageren of hoge baudrates kan het zijn dat de automatic mode niet snel genoeg schakelt naar ontvangen en je communicatieproblemen hebt.
Maar dat is wel best zeldzaam.

[bucovaina89]

Dus ergens zou je dan kunnen zeggen dat het ietwat "apart" is dat ze die standaard op semi-automatic zetten want het dekt verre van de helft van de use cases? (tenzij die bakjes veelal voor iets gebruikt worden waar ik geen weet van heb)