HB-RF-USB - USB Funkmodul für piVCCU

Virtualisierte CCU für Raspberry Pi und Clones

Moderator: Co-Administratoren

quickmic
Beiträge: 446
Registriert: 20.01.2011, 14:39

Re: HB-RF-USB - USB Funkmodul für piVCCU

Beitrag von quickmic » 01.02.2019, 17:18

Hallo Alex

Ich habe grade versucht deine Kernelmodule zu kompilieren auf Debian amd64.
Es scheint als ob es ein Problem gibt beim generic_raw_uart gibt.

Code: Alles auswählen

root@CCUx86:/opt/piVCCU/kernel# make
make -C /lib/modules/4.9.0-8-amd64/build M=/opt/piVCCU/kernel modules
make[1]: Entering directory '/usr/src/linux-headers-4.9.0-8-amd64'
  CC [M]  /opt/piVCCU/kernel/generic_raw_uart.o
/opt/piVCCU/kernel/generic_raw_uart.c: In function 'generic_raw_uart_get_gpio_pin_number':
/opt/piVCCU/kernel/generic_raw_uart.c:722:31: error: too many arguments to function 'fwnode_get_named_gpiod'
     struct gpio_desc *gpiod = fwnode_get_named_gpiod(fwnode, label, 0, GPIOD_ASIS, label);
                               ^~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/src/linux-headers-4.9.0-8-common/include/asm-generic/gpio.h:13:0,
                 from /usr/src/linux-headers-4.9.0-8-common/include/linux/gpio.h:51,
                 from /opt/piVCCU/kernel/generic_raw_uart.c:39:
/usr/src/linux-headers-4.9.0-8-common/include/linux/gpio/consumer.h:137:19: note: declared here
 struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
                   ^~~~~~~~~~~~~~~~~~~~~~
/usr/src/linux-headers-4.9.0-8-common/scripts/Makefile.build:307: recipe for target '/opt/piVCCU/kernel/generic_raw_uart.o' failed
make[4]: *** [/opt/piVCCU/kernel/generic_raw_uart.o] Error 1
/usr/src/linux-headers-4.9.0-8-common/Makefile:1528: recipe for target '_module_/opt/piVCCU/kernel' failed
make[3]: *** [_module_/opt/piVCCU/kernel] Error 2
Makefile:152: recipe for target 'sub-make' failed
make[2]: *** [sub-make] Error 2
Makefile:8: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.9.0-8-amd64'
Makefile:23: recipe for target 'all' failed
make: *** [all] Error 2
Hast du villeicht einen Tipp?


quickmic
Beiträge: 446
Registriert: 20.01.2011, 14:39

Re: HB-RF-USB - USB Funkmodul für piVCCU

Beitrag von quickmic » 01.02.2019, 17:23

ups, sorry hatte ich uebersehen. Ich teste nochmal...

quickmic
Beiträge: 446
Registriert: 20.01.2011, 14:39

Re: HB-RF-USB - USB Funkmodul für piVCCU

Beitrag von quickmic » 01.02.2019, 17:32

Super, ist sauber durchgelaufen. Spitzen Arbeit die du da leistest!

quickmic
Beiträge: 446
Registriert: 20.01.2011, 14:39

Re: HB-RF-USB - USB Funkmodul für piVCCU

Beitrag von quickmic » 01.02.2019, 18:50

Ich brauch bitte nochmal deine Hilfe... Ich versuche grade dein Modul nativ auf Debian Stretch ans laufen zu bekommen.
Ich denke ich bin auch schon recht weit, aber irgendwo passt noch was nicht.

Ich hab folgende Module geladen...

Code: Alles auswählen

modprobe eq3_char_loop
modprobe meson_raw_uart
modprobe hb_rf_usb
modprobe pl011_raw_uart
modprobe generic_raw_uart
modprobe dummy_rx8130
modprobe plat_eq3ccu2
modprobe fake_hmrf
modprobe dw_apb_raw_uart
modprobe led_trigger_timer
modprobe rpi_rf_mod_led
modprobe rtc-rx8130
Dann hab ich die /etc/config/multimacd.conf modifiziert:

Code: Alles auswählen

Coprocessor Device Path = /dev/raw-uart
#Cuse Device Name = ttyS0
Log Level = 3
Log Identifier = multimac
Log Destination = Syslog
HmIP Cmdline Pattern = */crRFD*
Bidcos Cmdline Pattern = *rfd -c*
Transparent Cmdline Pattern = *update*
Bidcos Exe Pattern = */bin/rfd
Default Subsystem = HmIP
Loop Master Device = /dev/eq3loop
Loop Slave Device Bidcos = mmd_bidcos
Loop Slave Device HmIP = ttyS0
devices schaut im Moment so aus:

Code: Alles auswählen

agpgart        cdrw		dri	   fuse       kmsg		net		    ptmx      sda1	snd	tty1   tty16  tty22  tty29  tty35  tty41  tty48  tty54	tty60  ttyS0	vcs   vcsa   vcsu   vfio
autofs	       char		dvd	   gpiochip0  log		network_latency     pts       sda2	sr0	tty10  tty17  tty23  tty3   tty36  tty42  tty49  tty55	tty61  ttyS1	vcs1  vcsa1  vcsu1  vga_arbiter
block	       console		eq3loop    hidraw0    loop-control	network_throughput  random    sda5	stderr	tty11  tty18  tty24  tty30  tty37  tty43  tty5	 tty56	tty62  ttyS2	vcs2  vcsa2  vcsu2  vhci
bsg	       core		fake-hmrf  hpet       mapper		null		    raw-uart  sg0	stdin	tty12  tty19  tty25  tty31  tty38  tty44  tty50  tty57	tty63  ttyS3	vcs3  vcsa3  vcsu3  vhost-net
btrfs-control  cpu_dma_latency	fb0	   hugepages  mem		port		    rtc       sg1	stdout	tty13  tty2   tty26  tty32  tty39  tty45  tty51  tty58	tty7   uhid	vcs4  vcsa4  vcsu4  vhost-vsock
bus	       cuse		fd	   initctl    memory_bandwidth	ppp		    rtc0      shm	tty	tty14  tty20  tty27  tty33  tty4   tty46  tty52  tty59	tty8   uinput	vcs5  vcsa5  vcsu5  vmci
cdrom	       disk		full	   input      mqueue		psaux		    sda       snapshot	tty0	tty15  tty21  tty28  tty34  tty40  tty47  tty53  tty6	tty9   urandom	vcs6  vcsa6  vcsu6  zero
beim start via "/bin/multimacd -f /etc/config/multimacd.conf -l 0 -c" kommt folgendes:

Code: Alles auswählen

oot@CCUx86:/opt/piVCCU/kernel# /bin/multimacd -f /etc/config/multimacd.conf -l 0 -c
2019/02/01 18:47:34.680 <Debug> FastMacResponder::ThreadFunction() started Id=1558
2019/02/01 18:47:34.680 <Warning> UpstreamCharConnection could not create slave device ttyS0: Inappropriate ioctl for device
2019/02/01 18:47:34.681 <Warning> UpstreamCharConnection could not create slave device mmd_bidcos: Inappropriate ioctl for device
2019/02/01 18:47:34.680 <Debug> MacController::ThreadFunction() started. Id=1559
2019/02/01 18:47:34.681 <Debug> C<: #0 COMMON IdentifyRequest
2019/02/01 18:47:34.681 <Debug> C< @1893205: bin:FD 00 03 FE 00 01 14 1E
2019/02/01 18:47:34.681 <Debug> Subsystem 1 ThreadFunction() started. Id=1561
2019/02/01 18:47:34.681 <Debug> Subsystem 2 ThreadFunction() started. Id=1562
2019/02/01 18:47:34.681 <Debug> SubsystemManager::ThreadFunction() started. Id=1560
2019/02/01 18:47:34.797 <Debug> C> @1893321: #213 LLMAC RX @29387ms -76dBm 0A 84 70 F1 D0 02 1D 87 D9 00 18 26 2E 5C 00 00 00 12 DC 00 00 00 00 00 00 00
2019/02/01 18:47:34.797 <Debug> C> @1893321: #214 LLMAC RX @ 2384ms -75dBm 2B 86 70 18 56 B2 00 00 00 00 B0 27
2019/02/01 18:47:34.797 <Debug> C> @1893321: #215 LLMAC RX @10920ms -57dBm A3 86 10 35 47 33 00 00 00 0A 88 AD 0E 0B 00
2019/02/01 18:47:34.797 <Debug> C> @1893321: #216 LLMAC RX @27444ms -84dBm 68 84 5E 4A 32 72 00 00 00 89 1A F7 00 00 00 00 00 08 EA FF
2019/02/01 18:47:34.797 <Debug> CRC error. Calculated 0xA6E1.
2019/02/01 18:47:34.797 <Debug> C> @1893321: #218 LLMAC RX @10104ms -63dBm A1 86 70 18 6B D8 00 00 00 00 C6 28
2019/02/01 18:47:34.797 <Debug> CRC error. Calculated 0xE5EE.
2019/02/01 18:47:34.797 <Debug> C> @1893321: #220 LLMAC RX @30104ms -63dBm A1 A2 58 18 6B D8 18 62 01 00 00
2019/02/01 18:47:34.798 <Debug> C> @1893322: #221 LLMAC RX @30232ms -60dBm A1 82 02 18 62 01 18 6B D8 01 01 08 00 2D
2019/02/01 18:47:34.799 <Debug> Unexpected start of frame after 3 bytes
2019/02/01 18:47:34.802 <Debug> C> @1893327: #0 COMMON Response Ack 44 75 61 6C 43 6F 50 72 6F 5F 41 70 70
2019/02/01 18:47:34.802 <Info> Copro application running.
2019/02/01 18:47:34.802 <Debug> C<: #1 TRX GetVersion
2019/02/01 18:47:34.802 <Debug> C< @1893327: bin:FD 00 03 01 01 02 9E 1B
2019/02/01 18:47:34.912 <Debug> C> @1893436: #1 TRX Response Ack 03 04 08 01 00 01 01 22 00
2019/02/01 18:47:34.912 <Info> Vapp=030408 Vbl=010001 Vhmos=012200
2019/02/01 18:47:34.912 <Debug> C<: #2 COMMON GetSGTIN
2019/02/01 18:47:34.912 <Debug> C< @1893436: bin:FD 00 03 FE 02 04 98 03
2019/02/01 18:47:34.921 <Debug> C> @1893446: #2 COMMON Response Ack 30 14 F7 11 A0 00 1F 58 A9 A7 16 AF
2019/02/01 18:47:34.921 <Info> SGTIN=30 14 F7 11 A0 00 1F 58 A9 A7 16 AF
2019/02/01 18:47:34.921 <Debug> C<: #3 LLMAC GetDefaultRfAddress
2019/02/01 18:47:34.921 <Debug> C< @1893446: bin:FD 00 03 03 03 08 92 0F
2019/02/01 18:47:34.926 <Debug> C> @1893451: #3 LLMAC Response ACK @255: 00 FF FF
2019/02/01 18:47:34.926 <Info> RF address=65535
2019/02/01 18:47:34.926 <Debug> C<: #4 LLMAC GetSerialNumber
2019/02/01 18:47:34.926 <Debug> C< @1893451: bin:FD 00 03 03 04 07 00 2E
2019/02/01 18:47:34.933 <Debug> C> @1893458: #4 LLMAC Response ACK @20549: 50 45 51 31 39 34 35 32 36 33
2019/02/01 18:47:34.933 <Info> Serial Number=PEQ1945263
2019/02/01 18:47:34.934 <Debug> C<: #5 LLMAC GetTimestamp
2019/02/01 18:47:34.934 <Debug> C< @1893458: bin:FD 00 03 03 05 02 86 33
2019/02/01 18:47:34.940 <Debug> C> @1893465: #5 LLMAC Response ACK @21445: 53 C5
2019/02/01 18:47:34.940 <Info> Timer=21445
2019/02/01 18:47:38.176 <Debug> C> @1896700: #25 LLMAC RX @24677ms -58dBm 07 86 53 24 85 46 00 00 00 00 41 00 29 42 FF 21 43 01 08 44 FE F8
2019/02/01 18:47:38.176 <Debug> Bidcos RX: #07[BC|Ren|WMup] 248546->000000 MeasurementCyclic: 00 41 00 29 42 FF 21 43 01 08 44 FE F8
2019/02/01 18:47:38.176 <Debug> GetAckActionForIncomingTelegram(): Unknown peer, AckAction_NotForUs
^CSignal 2 caught
2019/02/01 18:47:38.654 <Debug> SubsystemManager::ThreadFunction() ended
2019/02/01 18:47:38.655 <Debug> Subsystem 1 ThreadFunction() ended
2019/02/01 18:47:38.655 <Debug> Subsystem 2 ThreadFunction() ended
Signal 10 caught
2019/02/01 18:47:38.655 <Warning> FastMacResponder read error: Interrupted system call
2019/02/01 18:47:38.655 <Debug> FastMacResponder::ThreadFunction() ended
2019/02/01 18:47:38.655 <Debug> MacController::ThreadFunction() ended
Es lebt also schon, aber das...

Code: Alles auswählen

UpstreamCharConnection could not create slave device ttyS0: Inappropriate ioctl for device
Schaut nach einem Problem aus.


Ausserdem zeigt die /etc/config/rfd.conf per default auf...

Code: Alles auswählen

ComPortFile = /dev/mmd_bidcos

Code: Alles auswählen

/dev/ccu2-ic200
Das gibts bei mir nicht. Ich glaube da stimmt auch noch was nicht.


Irgendwelche Tips?

deimos
Beiträge: 2510
Registriert: 20.06.2017, 10:38
Wohnort: Leimersheim
Kontaktdaten:

Re: HB-RF-USB - USB Funkmodul für piVCCU

Beitrag von deimos » 01.02.2019, 19:16

Hi,

du brauchst nicht alle Module manuell laden. Die ganzen raw_uarts und das hb_rf_usb werden über udev geladen (entweder beim Einstecken des USB Geräts oder über entsprechende Einträge im Device Tree bei den ARM Devices.
fake_hmrf ist für die Software Emulation des Funkmoduls, das braucht es nur, wenn man die CCU komplett emulieren will und kein physikalisches Funkmodul hat. Bei Verwendung von OCCU sollte man da eher die Finger von lassen.
plat_eq3ccu2 ist für die Emulation der CCU2, auch hier lieber Finger von lassen.
Die restlichen sind für die LEDs bzw. RTC vom RPI-RF-MOD. Brauchst du für den multimacd jetzt erstmal nicht.

In den ganzen Configs solltest du kein ttyS0 nehmen, sondern überall mmd_hmip. Ist mittlerweile der Standard und macht die Sache einfacher, weil sich dass dann nicht mit einen ggf. vorhandenen physikalischen ttyS0 in die Quere kommt.
Insgesamt solltest du dir auch nicht die Default Configs in OCCU anschauen, die funktionieren nicht richtig, schau dir da lieber die Configs in einer CCU3 an.

Viele Grüße
Alex

quickmic
Beiträge: 446
Registriert: 20.01.2011, 14:39

Re: HB-RF-USB - USB Funkmodul für piVCCU

Beitrag von quickmic » 01.02.2019, 19:35

Code: Alles auswählen

du brauchst nicht alle Module manuell laden.
Ist nur zum Debuggen, ist klar dass da viel Geruempel dabei ist. Ich mach aber plat_eq3ccu2, fake_hmrf raus bevor sich was quer legt.
Danke fuer den Tip.

Code: Alles auswählen

In den ganzen Configs solltest du kein ttyS0 nehmen, sondern überall mmd_hmip.
Werde ich versuchen, ich hatte schon diverse (auch nicht existierende) serial devices reinkonfiguriert zum Test.

Zum Verständnis... Multimacd sollte beim Start die definierte Geraete erstellen? z.b.

Code: Alles auswählen

Loop Slave Device Bidcos = mmd_bidcos
Loop Slave Device HmIP = mmd_hmip
...sollte /dev/mmd_hmip und /dev/mmd_bidcos generieren/durchloopen?

vegetto
Beiträge: 4
Registriert: 23.12.2018, 15:42

Re: HB-RF-USB - USB Funkmodul für piVCCU

Beitrag von vegetto » 02.02.2019, 20:13

Die Platine läuft ohne weiteres mit Docker und Kubernetes. Ich bin beindruckt, dass das Signal so gut ist, in Vergleich zum HM-MOD-RPI-PCB direkt zu plugen und keine Störungen auftreten. Ich addiere gerade zu dem CCU2 Dokumentation, dass es official das Adapter ünterstutz.

Mein Plan ist (später) zwei HB-RF-USB Adaptern in meinem Kubernetes Cluster einzubauen, damit ein fail over des CCU bei HW Fehlern transparent stattfinden kann.

Vielen Dank Daimos für deine Idee und mir einer von deine Platinen zu senden!

quickmic
Beiträge: 446
Registriert: 20.01.2011, 14:39

Re: HB-RF-USB - USB Funkmodul für piVCCU

Beitrag von quickmic » 08.02.2019, 09:05

Hallo

Ich versuche nach wie vor das Ding unter Debian X86 ans Laufen zu bekommen.
Eigentlich sollte alles passen, klappt aber aus irgendwelchen Gründen nicht. Im Moment habe ich am ehesten ein Hardwareproblem im Verdacht.
Folgende logs schauen nicht normal aus:

Code: Alles auswählen

root@CCUx86:~# /bin/eq3configcmd update-coprocessor -p /dev/raw-uart -t RPI-RF-MOD -c -v
2019/02/08 08:58:58.958 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2019/02/08 08:58:58.958 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2019/02/08 08:58:59.566 <Info> Version: 4.0.16

Code: Alles auswählen

java -Dgnu.io.rxtx.SerialPorts=/dev/raw-uart -jar /opt/HmIP/hmip-copro-update.jar -p /dev/raw-uart -v
[DEBUG] Start bootloader ...
[ERROR] Last frame was not complete. Aborting decoding of that frame.
[DEBUG] Bootloader running
[DEBUG] Request bootloader version ...
[INFO] SGTIN = 3014F711A0001F58A9A716AF
[INFO] Checking coprocessor firmware version ...
[INFO] Bootloader version = 1.0.1
[DEBUG] Start application ...
[ERROR] Last frame was not complete. Aborting decoding of that frame.
[DEBUG] Application 'DualCoPro_App' running
[DEBUG] Request application version ...
[DEBUG] Request application version ...
[INFO] Application version = 4.0.16
Resets hab ich schon mehrfach durchgeführt, auch alles mehrfach neu geflascht.
CoPro FW, und App FW.

Hat alles nichts geholfen, und fühlte sich auch wacklig an.
Vor allem CoPro FW update lief manchmal sauber durch, dann wieder nicht usw.

Irgendwelche Tips?

deimos
Beiträge: 2510
Registriert: 20.06.2017, 10:38
Wohnort: Leimersheim
Kontaktdaten:

Re: HB-RF-USB - USB Funkmodul für piVCCU

Beitrag von deimos » 08.02.2019, 09:23

Hi,

eq3configcmd ist nicht für die Zusammenarbeit mit dem RPI-RF-MOD gedacht, daher ist es klar, dass es nicht läuft.

Die beiden Error Zeilen beim hmip-copro-update.jar sind auch "normal". Beim Wechsel zwischen Bootloader und App sendet das Funkmodul einen Break und erzeugt dadurch unvollständige Frames.

Was du mit dem Update von App FW und Copro FW meinst, ist mir aber nicht klar. Es gibt für das RPI-RF-MOD doch nur eine Firmware? (In verschiedenen Versionen, die 3.4.8 für die offiziellen CCU3 Firmwares und die 4.0.16 für die Sunrise CCU3 Firmware und die kommende CCU3 Firmware 3.43.x).

Viele Grüße
Alex

Antworten

Zurück zu „piVCCU“