CUL am Raspberry Pi flashen
Raspberry Pi & CUL
Vorbemerkung: Hier geht es um ein CUL in der Version 3.4
FHEM bietet die Möglichkeit, ein fabrikneues CUL beim ersten Anschließen (mit gedrückter Taste) mit der notwendigen Firmware zu flashen. Dies gelingt aber nicht immer, so dass man dann die Firmware selbst brennen muss.
Hardwareerkennung unter Linux
Anmerkung: Hier nicht nur für den RPi.
Standard-PC mit kubuntu 10.04-LTS
Man öffnet eine Konsole bzw. ein Terminal und gibt folgenden Befehl ein:
$ sudo tail -f /var/log/messages
bzw. (auf neueren Linuxoiden):
$ sudo tail -f /var/log/syslog
nach dem Einstecken zeigt sich das CUL (hier noch ohne gedrückte Taste) wie folgt:
mct_u232 2-4:1.0: MCT U232 converter detected usb 2-4: MCT U232 converter now attached to ttyUSB0 usb 2-6: new full speed USB device using ohci_hcd and address 4 usb 2-6: configuration #1 chosen from 1 choice
BeagleBoard-xM mit OpenSuse 12.2 für ARM
Hier werden bei gleicher Vorgehensweise folgende Systemmeldungen ausgegeben:
usb 1-2.4: new full-speed USB device number 5 using ehci-omap usb 1-2.4: ep0 maxpacket = 32 usb 1-2.4: default language 0x0409 usb 1-2.4: udev 5, busnum 1, minor = 4 usb 1-2.4: New USB device found, idVendor=03eb, idProduct=2ff4 usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2.4: Product: ATm32U4DFU usb 1-2.4: Manufacturer: ATMEL usb 1-2.4: SerialNumber: 1.0.0 usb 1-2.4: usb_probe_device usb 1-2.4: configuration #1 chosen from 1 choice usb 1-2.4: adding 1-2.4:1.0 (config #1, interface 0) usbtest 1-2.4:1.0: usb_probe_interface usbtest 1-2.4:1.0: usb_probe_interface - got id /home/abuild/rpmbuild/BUILD/kernel-omap2plus-3.4.6/linux-3.4/drivers/usb/core/inode.c: creating file '005' hub 1-2:1.0: state 7 ports 5 chg 0000 evt 0010
Beaglebone
<Datum> <Zeit> kernel: [...] usb 1-1.1: new full-speed USB device number 5 using musb-hdrc <Datum> <Zeit> kernel: [...] usb 1-1.1: New USB device found, idVendor=03eb, idProduct=204b <Datum> <Zeit> kernel: [...] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 <Datum> <Zeit> kernel: [...] usb 1-1.1: Product: CUL868 <Datum> <Zeit> kernel: [...] usb 1-1.1: Manufacturer: busware.de <Datum> <Zeit> kernel: [...] cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device
Raspberry Pi mit Raspbian
usb 1-1.3.3: new full-speed USB device number 8 using dwc_otg usb 1-1.3.3: New USB device found, idVendor=03eb, idProduct=2ff4 usb 1-1.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.3.3: Product: ATm32U4DFU usb 1-1.3.3: Manufacturer: ATMEL usb 1-1.3.3: SerialNumber: 1.0.0
Normalerweise sollte auf dem RPi jetzt ein neuer /dev/ttyACMX-Eintrag (X steht für eine beliebige Zahl, meist "0") erzeugt werden. Dies ist aber nicht der Fall, was 2 Ursachen haben kann:
1. nicht (richtig) geflasht 2. das Kernel-Modul fehlt
Letzteres kann aber ausgeschlossen werden, da dieses Modul definitiv im Raspbian (hier: 2012-12-16-wheezy-raspbian.img) enthalten ist. Somit bleibt nur das Flashen der Firmware per separaten Tools...
CUL unter Linux flashen
Um die Firmware auf dem BBxM (oder einem anderen Linux-PC) in das CUL zu "brennen" braucht man den dfu-programmer, dieser brachte aber nach dem Entpacken mit anschließendem
./configure
im entpackten Verzeichnis die Meldung, dass er keinen Compiler gefunden hat:
checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... no checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/opt/install/dfu-programmer-0.5.4': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details
Also sind einige Pakete (über die Paketverwaltung ihrer Distribution: yast, zypper, synaptics, apt usw.) nachzuinstallieren. Da auch noch einige andere Pakete für das anschließende make usw. fehlen, hier die Aufstellung der Pakete, die noch zu installieren waren:
gcc bison build make kernel-source libusb-1_0-devel libusb-compat-devel usbutils
Das nimmt einige Zeit in Anspruch, aber danach läuft der "Dreisatz" zum installieren des DFU-Programmers
./configure make make install
erfolgreich durch.
Jetzt besorgt man sich die CUL-Firmware und kopiert diese z.B. nach /opt/install. Dort entpackt man sie, wechselt in das Verzeichnis /opt/install/CUL_VER_146/culfw/Devices/CUL/ und ruft dort
$ sudo make usbprogram
auf (vorher das CUL mit gedrückter Taste in den PC einstecken). Hier muss man aber angeben, welche CUL-Version man hat (specify one of: usbprogram_v2 usbprogram_v2_hm usbprogram_v3 usbprogram_v4). Da es um die Version 3.4 geht, heißt es also
$ sudo make usbprogram_v3
Meldungen / Ausgaben:
dfu-programmer atmega32u4 erase || true dfu-programmer atmega32u4 flash CUL_V3.hex Validating... 16392 bytes used (57.17%) dfu-programmer atmega32u4 start
und das CUL begrüßt einen mit einer grün blinkenden LED.
Auch die Ausgabe von tail -f /var/log/messages (auf neueren Linux-Derivaten müssen Sie nun tail -f /var/log/syslog eingeben) sieht jetzt gut aus:
usb 1-1.2: new full-speed USB device number 5 using dwc_otg usb 1-1.2: new full-speed USB device number 7 using dwc_otg usb 1-1.2: New USB device found, idVendor=03eb, idProduct=204b usb 1-1.2: New USB device strings: Mfr=1, Product=2, serialNumber=0 usb 1-1.2: Product: CUL868 usb 1-1.2: Manufacturer: busware.de cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device usbcore: registered new interface driver cdc_acm cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Es wird das Device /dev/ttyACM0 erstellt (auf das FHEM dann konfiguriert werden muss, aber das ist Bestandteil eines anderen HowTos), nachdem automatisch der "Treiber", im Linux-Jargon das Kernel-Modul cdc_acm geladen wurde.
CUL unter Windows flashen
Es gibt den DFU-Programmer auch für Windows, aber darauf wird hier nicht eingegangen.
CUL mit FHEM nutzen
CUL richtig geflasht
Wenn das Flashen der Firmware funktioniert hat und in der fhem.cfg die richtigen Einstellungen wie z.B.
define CUL1 CUL /dev/ttyACM0@9600 1234
vorgenommen wurden, sollte in fhem.log folgendes erscheinen:
YYYY.MM.DD HH:MM:SS 3: Opening CUL1 device /dev/ttyACM0 YYYY.MM.DD HH:MM:SS 3: Setting CUL1 baudrate to 9600 YYYY.MM.DD HH:MM:SS 3: CUL1 device opened YYYY.MM.DD HH:MM:SS 3: CUL1: Possible commands: BCFiAGMRTVWXefmltux
Wichtig ist, dass das CUL auf dem Device ttyACMX und nicht auf ttyAMAX erkannt wird.
Einschub (COC):
Ein COC zeigt sich übrigens so:
YYYY.MM.DD HH:MM:SS 3: Opening COC device /dev/ttyAMA0 YYYY.MM.DD HH:MM:SS 3: Setting COC baudrate to 38400 YYYY.MM.DD HH:MM:SS 3: COC device opened YYYY.MM.DD HH:MM:SS 3: COC: Possible commands: mCFiAZOGMRTVWXefltux
Das Device ist also ein anderes ttyAMA0 statt ttyACM0
CUL wird nicht (richtig) erkannt
Beim Start von FHEM kann es evtl. zu Fehlermeldungen kommen:
YYYY.MM.DD HH:MM:SS 1: usb create starting YYYY.MM.DD HH:MM:SS 3: Opening CUL device /dev/ttyACM0 YYYY.MM.DD HH:MM:SS 3: Can't open /dev/ttyACM0: Permission denied YYYY.MM.DD HH:MM:SS 1: usb create end
Hier fehlen die Rechte auf das Device /dev/ttyACM0 für den Benutzer, unter dem FHEM läuft. Mittels
$ ls -l /dev/ttyACM0
sieht man
crw-rw---- 1 root tty 204, 64 Feb 1 07:43 /dev/ttyACM0
dass der Benutzer root sowie die Gruppe tty Lese- und Schreibrechte auf das CUL haben. Man muss jetzt also dem FHEM-Benutzer ebenfalls solche Rechte zuweisen und das geschieht durch Zuordnung zur Gruppe tty mittels:
$ sudo usermod -A -G tty pi $ sudo usermod -A -G tty fhem
Kommt es dabei zur Fehlermeldung
usermod: invalid option -- 'A'
dann hat ihr System eine andere Version von usermod, so dass Sie folgende Befehle absetzen müssen:
$ sudo usermod -a -G tty pi $ sudo usermod -a -G tty fhem
also mit kleinem a statt großem A.
Ursache kann aber auch ein nicht korrekt durchgeführtes Flashen der Firmware (oder falsche Firmware-Version) sein. Blinkt das CUL nach dem Flashen und anschließendem Anstecken an eine beliebige USB-Schnittstelle nicht im Sekundentakt, so liegt eher hier das Problem.