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

[quickmic]

Vielleicht war upgrade der falsche Ausdruck. Ich meinte Druberflaschen:

Code: Alles auswählen

/bin/eq3configcmd update-coprocessor -p /dev/raw-uart -t RPI-RF-MOD -u -f -c -l 0 -d /opt/occu/firmware/RPI-RF-MOD
java -Dgnu.io.rxtx.SerialPorts=/dev/raw-uart -jar /opt/HmIP/hmip-copro-update.jar -p /dev/raw-uart -o -f /opt/occu/firmware/RPI-RF-MOD/dualcopro_update_blhmip-4.0.16.eq3

Im Moment ist also die 4.0.16 drauf.

Und das /bin/eq3configcmd update-coprocessor hatte ich deswegen versucht:
viewtopic.php?f=65&t=46141&start=20#p462964

Code: Alles auswählen

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.

Dann muss ich weitersuchen, wo das Problem liegt.

Hauptproblem ist nachwievor, dass ich kein mmd_bidcos oder mmd_hmip Geraete bekomme. Ich dachte, koennte vielleicht ein Hardwareproblem sein.

Auch folgendes Kommando spuckt immer einen Fehler aus:

Code: Alles auswählen

/bin/setserial /dev/raw-uart low_latency
Cannot get serial info: Inappropriate ioctl for device

Code: Alles auswählen

lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0403:6f70 Future Technology Devices International, Ltd HB-RF-USB
Bus 001 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Code: Alles auswählen

root@CCUx86:~# lsmod
Module                  Size  Used by
binfmt_misc            20480  1
eq3_char_loop          20480  0
hb_rf_usb              16384  0
generic_raw_uart       20480  1 hb_rf_usb
coretemp               16384  0
crct10dif_pclmul       16384  0
crc32_pclmul           16384  0
ghash_clmulni_intel    16384  0
vmw_balloon            24576  0
intel_rapl_perf        16384  0
pcspkr                 16384  0
joydev                 24576  0
serio_raw              16384  0
vmwgfx                327680  1
sg                     36864  0
ttm                   126976  1 vmwgfx
drm_kms_helper        204800  1 vmwgfx
drm                   491520  4 vmwgfx,drm_kms_helper,ttm
evdev                  28672  2
ac                     16384  0
vmw_vmci               81920  1 vmw_balloon
button                 16384  0
ip_tables              28672  0
x_tables               45056  1 ip_tables
autofs4                49152  2
ext4                  733184  1
crc16                  16384  1 ext4
mbcache                16384  1 ext4
jbd2                  118784  1 ext4
crc32c_generic         16384  0
fscrypto               32768  1 ext4
ecb                    16384  0
hid_generic            16384  0
usbhid                 57344  0
hid                   139264  2 usbhid,hid_generic
sr_mod                 28672  0
cdrom                  69632  1 sr_mod
sd_mod                 53248  3
ata_generic            16384  0
crc32c_intel           24576  2
ahci                   40960  2
libahci                40960  1 ahci
ata_piix               36864  0
aesni_intel           200704  0
aes_x86_64             20480  1 aesni_intel
crypto_simd            16384  1 aesni_intel
cryptd                 28672  3 crypto_simd,ghash_clmulni_intel,aesni_intel
glue_helper            16384  1 aesni_intel
libata                274432  4 ata_piix,libahci,ahci,ata_generic
ehci_pci               16384  0
psmouse               172032  0
vmw_pvscsi             28672  0
vmxnet3                65536  0
uhci_hcd               49152  0
ehci_hcd               94208  1 ehci_pci
usbcore               290816  6 ehci_pci,usbhid,ehci_hcd,uhci_hcd,hb_rf_usb
scsi_mod              249856  5 vmw_pvscsi,sd_mod,libata,sg,sr_mod
usb_common             16384  1 usbcore
i2c_piix4              24576  0

[jmaus]

Hauptproblem ist nachwievor, dass ich kein mmd_bidcos oder mmd_hmip Geraete bekomme. Ich dachte, koennte vielleicht ein Hardwareproblem sein.

Na die beiden devices werden ja auch vom "multimacd" erzeugt.

Auch folgendes Kommando spuckt immer einen Fehler aus:

Code: Alles auswählen

/bin/setserial /dev/raw-uart low_latency
Cannot get serial info: Inappropriate ioctl for device

Warum denkst du denn das du das setserial auf dem /dev/raw-uart brauchst? Das ist nämlich nicht der Fall.

[deimos]

Hi,

Vielleicht war upgrade der falsche Ausdruck. Ich meinte Druberflaschen:

Code: Alles auswählen

/bin/eq3configcmd update-coprocessor -p /dev/raw-uart -t RPI-RF-MOD -u -f -c -l 0 -d /opt/occu/firmware/RPI-RF-MOD
java -Dgnu.io.rxtx.SerialPorts=/dev/raw-uart -jar /opt/HmIP/hmip-copro-update.jar -p /dev/raw-uart -o -f /opt/occu/firmware/RPI-RF-MOD/dualcopro_update_blhmip-4.0.16.eq3

Im Moment ist also die 4.0.16 drauf.

Und das /bin/eq3configcmd update-coprocessor hatte ich deswegen versucht:
viewtopic.php?f=65&t=46141&start=20#p462964

Ganz dumme Idee. Bevor du eine Firmware aufspielst, musst du sicher wissen, was für ein Modul angeschlossen ist, auf der Platine können beide Module aufgesetzt werden (wenn auch nicht gleichzeitig). Wenn das Teil kaputt geflasht ist, dann muss im Zweifel der Nutzer manuell dieses Wissen einbringen. Und es bleibt dabei: Beim RPI-RF-MOD nicht eq3configcmd verwenden, das klappt einfach nicht.

Hauptproblem ist nachwievor, dass ich kein mmd_bidcos oder mmd_hmip Geraete bekomme. Ich dachte, koennte vielleicht ein Hardwareproblem sein.

Das ist ein reines Thema vom multimacd und/oder dem eq3_char_loop Kernel Modul. Starte den im Zweifel doch einfach mal mit LogLevel Debug. Wobei ich da sagen kann, das der bei mir auch unter X86 die beide Nodes einwandfrei anlegt, sofern er den mit korrekten Konfigs gestartet wird.

Auch folgendes Kommando spuckt immer einen Fehler aus:

Code: Alles auswählen

/bin/setserial /dev/raw-uart low_latency
Cannot get serial info: Inappropriate ioctl for device

Korrekt. Das raw-uart Device ist ja auch kein tty Device. Und das Modul sorgt dafür, dass die Latenzen gering sind, es kann nämlich gar nicht anders. Die Latenzen sind an der Stelle sogar noch geringer, als sie beim Standard FTDI Kernel Modul mit gesetztem low_latency wären.

Ich würde im übrigen vorschlagen, dass wir das Thema in einem eigenen Thread weiterführen. Das ganze hat nur indirekt mit der Platine zu tun, sondern primär mit deiner Implementierung.

Viele Grüße
Alex

[quickmic]

Neuer Thread, Gute Idee
viewtopic.php?f=78&t=48983#p490847

[deimos]

Hi,

damit es nicht untergeht: Der eigentliche Grund für die Platine ist fertig: viewtopic.php?f=18&t=49029

Viele Grüße
Alex

[fubo08]

Hi,

damit es nicht untergeht: Der eigentliche Grund für die Platine ist fertig: viewtopic.php?f=18&t=49029

Viele Grüße
Alex

Bist du vielleicht auch schon weiter, die Platine anbieten zu können, für Leute wie mich, die sich nicht zu trauen SMB zu löten?!

[deimos]

Hi,

Bist du vielleicht auch schon weiter, die Platine anbieten zu können, für Leute wie mich, die sich nicht zu trauen SMB zu löten?!

Weiter ja, aber leider noch nicht am Ziel. Aber es geht eigentlich nur noch um ein paar formale Dinge und die eigentliche Produktion.

Viele Grüße
Alex

[MathiasZ]

Hi Alex,
ich möcchte einen Zwischenstand abgeben:
so, die erste Platine ist kaputtgelötet,
Dein Gehäuse befindet sich im Druck.

Gruß,
Mathias
P.S. ich glaube ich hätte doch warten sollen

[fanavity]

Wo finde ich denn die STL Datei? Habe ich das hier übersehen?

[jmaus]

Was mir bzgl. Gehäuse für HB-RF-USB noch eingefallen ist:
Wäre es nicht möglich gewesen (bzw. ist das vielleicht eine gute Idee für eine zukünftige Version?) die Platine des HB-RF-USB nicht einfach so zu designen das es den Formfaktor eine RaspberryPi3 hat? Dann könnte man kurzerhand einfach ein ELV Charly Gehäuse nehmen (von denen es ja genug auf dem Markt gibt), dort statt eines RaspberryPi3 das HB-RF-USB reinschrauben das RPI-RF-MOD aufstecken, an den microUSB Anschluss die CCU seiner Wahl anschliessen und fertig. Oder übersehe ich etwas?