CUL am Raspberry Pi flashen - Versionsgeschichte

Octo: Wikilinks eingefügt (war verwaiste Seite).

2016-01-21T08:59:56Z

Wikilinks eingefügt (war verwaiste Seite).

← Nächstältere Version		Version vom 21. Januar 2016, 10:59 Uhr
Zeile 1:		Zeile 1:
	~~'''Raspberry Pi &~~ CUL~~'''~~		{{Hinweis\|Dieser Artikel geht von einem CUL in der Version 3.4 aus.}}

	~~'''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.

	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==		==Hardwareerkennung unter Linux==

	'''Anmerkung:''' Hier nicht nur für den ~~RPi~~.		'''Anmerkung:''' Hier nicht nur für den [[Raspberry Pi]].

	===Standard-PC mit kubuntu 10.04-LTS===		===Standard-PC mit kubuntu 10.04-LTS===

Soulman: Soulman verschob Seite Cul am Raspberry flashen nach CUL am Raspberry Pi flashen

2013-11-26T22:02:57Z

Soulman verschob Seite Cul am Raspberry flashen nach CUL am Raspberry Pi flashen

← Nächstältere Version	Version vom 27. November 2013, 00:02 Uhr
(kein Unterschied)

Soulman: Soulman verschob Seite Raspberry Pi & CUL nach Cul am Raspberry flashen: Besser Namensähnlichkeit mit thematisch ähnlichen Artikeln

2013-11-26T22:02:13Z

Soulman verschob Seite Raspberry Pi & CUL nach Cul am Raspberry flashen: Besser Namensähnlichkeit mit thematisch ähnlichen Artikeln

← Nächstältere Version	Version vom 27. November 2013, 00:02 Uhr
(kein Unterschied)

Rohan: Kleine Ergänzungen

2013-11-26T14:37:20Z

Kleine Ergänzungen

← Nächstältere Version		Version vom 26. November 2013, 16:37 Uhr
Zeile 6:		Zeile 6:

	==Hardwareerkennung unter Linux==		==Hardwareerkennung unter Linux==

			'''Anmerkung:''' Hier nicht nur für den RPi.

	===Standard-PC mit kubuntu 10.04-LTS===		===Standard-PC mit kubuntu 10.04-LTS===
Zeile 12:		Zeile 14:

	$ sudo tail -f /var/log/messages		$ 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:		nach dem Einstecken zeigt sich das CUL (hier noch ohne gedrückte Taste) wie folgt:
Zeile 41:		Zeile 47:
	hub 1-2:1.0: state 7 ports 5 chg 0000 evt 0010		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===		===Raspberry Pi mit Raspbian===
Zeile 57:		Zeile 71:

	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...		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 ==		==CUL unter Linux flashen ==
Zeile 143:		Zeile 156:
	YYYY.MM.DD HH:MM:SS 3: CUL1: Possible commands: BCFiAGMRTVWXefmltux		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.		Wichtig ist, dass das CUL auf dem Device ttyA'''CM'''X und nicht auf ttyA'''MA'''X erkannt wird.

	'''Einschub (COC):'''		'''Einschub (COC):'''

Rohan: Kategorien vervollständigt

2013-11-26T12:59:34Z

Kategorien vervollständigt

← Nächstältere Version		Version vom 26. November 2013, 14:59 Uhr
Zeile 125:		Zeile 125:

	===CUL unter Windows flashen===		===CUL unter Windows flashen===

	~~Hierzu zunächst einige Links:~~

	~~1 mit Verweis auf 2~~
	3

	Es gibt den ''DFU-Programmer'' auch für Windows, aber darauf wird hier nicht eingegangen.		Es gibt den ''DFU-Programmer'' auch für Windows, aber darauf wird hier nicht eingegangen.
Zeile 137:		Zeile 132:
	===CUL richtig geflasht===		===CUL richtig geflasht===

	Wenn das Flashen der Firmware funktioniert hat und in der fhem.cfg die richtigen Einstellungen wie z.B.		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		define CUL1 CUL /dev/ttyACM0@9600 1234
Zeile 197:		Zeile 192:

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

			[[Kategorie:CUL]]
			[[Kategorie:Raspberry Pi]]
			[[Kategorie:HOWTOS]]

Rohan: Diesen Artikel habe ich nach dem Crash noch vermisst und aus meinen Cache-Daten wiederhergestellt. Es werden noch einige Korrekturen erforderlich sein

2013-11-26T12:53:54Z

Diesen Artikel habe ich nach dem Crash noch vermisst und aus meinen Cache-Daten wiederhergestellt. Es werden noch einige Korrekturen erforderlich sein

Neue Seite

'''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==

===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

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

===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===

Hierzu zunächst einige Links:

1 mit Verweis auf 2
3

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 ttyA'''MA'''0 statt ttyA'''CM'''0

===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.