CUL am Raspberry Pi flashen

Dieser Artikel geht von einem CUL in der Version 3.4 aus.

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 Raspberry Pi.

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.