Hallo zusammen,
leider wird mein CUL-Stick (brandneu V3.4) nicht automatisch geflasht, wenn ich ihn in den USB-Port des raspberry pi B einstecke (mit gedrückter Taste). Kann das ohne DFU-programmer eigentlich überhaupt funktionieren?!
Dann wollte ich den CUL-Stick selbst flashen.
Vorbereitung:
pi@raspberrypi1 ~ $ sudo apt-get install dfu-programmer
war erforlgreich.
pi@raspberrypi1 ~ $ sudo -i
root@raspberrypi1:~# wget http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUL/CUL_V3.hex
root@raspberrypi1:~# ls -lh
total 8.6M
-rw-r--r-- 1 root root 69K Jan 17 22:23 CUL_V3.hex
drwxr-xr-x 2 root root 4.0K Dec 25 23:19 Desktop
-rw-r--r-- 1 root root 8.5M Oct 6 14:01 fhem-5.5.deb
drwxr-xr-x 8 root root 4.0K Jan 11 08:56 wiringPi
schaut doch auch gut aus.
Flash Vorgang:
root@raspberrypi1:~# dfu-programmer atmega32u4 erase
root@raspberrypi1:~# lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 007: ID 03eb:2ff4 Atmel Corp.
Bis hierhin schaut es für mich ok aus. Aber nun der Fehler:
root@raspberrypi1:~# dfu-programmer atmega32u4 flash --debug 1 CUL_V3.hex
Error parsing the line.
Something went wrong with creating the memory image.
Für eine Hilfestellung wäre ich dankbar. Ich weiß, dass es für die Pros ätzend ist solche Anfängerfragen zu beantworten. Ich habe mir aber wirklich Mühe gegeben die vorhandene Quellen (Wiki ,... ) durchzulesen.
Danke + lg blu
ps
root@raspberrypi1:/dev# ls | grep ttyA
ttyAMA0
root@raspberrypi1:~# dpkg -l | grep fhem
ii fhem 5.5
pps
pi@raspberrypi1 /dev $ tail -f /var/log/syslog
Jan 17 22:25:56 raspberrypi1 kernel: [ 2662.771245] usb 1-1.3: new full-speed USB device number 7 using dwc_otg
Jan 17 22:25:56 raspberrypi1 kernel: [ 2662.886954] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=2ff4
Jan 17 22:25:56 raspberrypi1 kernel: [ 2662.886993] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 17 22:25:56 raspberrypi1 kernel: [ 2662.887013] usb 1-1.3: Product: ATm32U4DFU
Jan 17 22:25:56 raspberrypi1 kernel: [ 2662.887030] usb 1-1.3: Manufacturer: ATMEL
Jan 17 22:25:56 raspberrypi1 kernel: [ 2662.887047] usb 1-1.3: SerialNumber: 1.0.0
Zitatwget http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUL/CUL_V3.hex
Das liefert Muell (== komprimierte HTML Seite) zurueck.
Mit einem installierten dfu-programmer sollte FHEM mit dem CULflash Befehl
auch in der Lage sein das Geraet zu flashen
Hallo,
und vielen Dank für die prompte Hilfe! So hat es geklappt:
root@raspberrypi1:~# wget http://culfw.de/culfw-1.55.tar.gz
root@raspberrypi1:~# tar xfz culfw-1.55.tar.gz
root@raspberrypi1:~# cd culfw-1.55/Devices/CUL
root@raspberrypi1:~/culfw-1.55/Devices/CUL# make usbprogram_v3
dfu-programmer atmega32u4 erase || true
dfu-programmer atmega32u4 flash CUL_V3.hex
Validating...
18582 bytes used (64.81%)
dfu-programmer atmega32u4 start
Nun schaut es besser aus:
root@raspberrypi1:/dev# ls | grep ttyA
ttyACM0
ttyAMA0
Aus der FHEM-Weboberfläche heraus hatte ich es mittels CUL flash versucht, jedoch fehlten mir wohl die root-Rechte, zumindest war die Fehlermeldung
dfu-programmer: no device present.
lg blu
Hallo blu,
danke für die coole Anleitung , hat bestens funktioniert !
Habe gerade 1.58 geflasht.
Zitatroot@raspberrypi1:~/culfw-1.55/Devices/CUL# make usbprogram_v3
was nicht notwendig !
klaus
Hallo zusammen,
--->erledigt, siehe zwei Beiträge weiter <---
nachdem ich permanent mit Missing ACKS kämpfe möchte ich meinen CUL (aktuell 1.55) neu auf 1.61 flashen. Leider misslingt das.
Folgende Devices werden gefunden, das letzte ist wohl der CUL:
root@raspyFHEM:~/CUL_VER_161/Devices/CUL# lsusb
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Die aktuelle Firmware ist herungergeladen und entpackt. Allerdings liefert make usbprogram_v3 einen Fehler.
root@raspyFHEM:~/CUL_VER_161/Devices/CUL# ls
board.h CUL.c CUL_V2.hex CUL_V2_HM.hex CUL_V2_MAX.hex CUL_V3.hex CUL_V4.hex makefile makefile.myusb
root@raspyFHEM:~/CUL_VER_161/Devices/CUL# make usbprogram_v3
dfu-programmer atmega32u4 erase || true
dfu-programmer: no device present.
dfu-programmer atmega32u4 flash CUL_V3.hex
dfu-programmer: no device present.
makefile:148: recipe for target 'do_usbprogram' failed
make: *** [do_usbprogram] Error 1
Ist nicht verwunderlich, dass der atmega32u4 nicht als device auftaucht. Könnt ihr mir helfen, wie ich das korrigiere? Wahrscheinlich muss ich einfach ein anderes Target setzen, nur welches?
Inzwischen habe ich nach einigem Stöbern im Forum herausgefunden, dass diese Fehlermeldung ihre Ursache wohl in fehlenden root-Rechten hat. Eine Lösung habe ich leider noch nicht gefunden :-(
Danke + LG
blu
Hi,
nochmal mein Vorgehen
1) FHEM beenden
2) Button am CUL V3 drücken und gleichzeitig:
edit: WICHTIG Der CUL-Stick muss dazu mit gedrücktem Button in den USB Anschluss eingeführt werden!
3) als root ausführen
root@raspyFHEM:~/CUL_VER_161/Devices/CUL# make usbprogram_v3
dfu-programmer atmega32u4 erase || true
dfu-programmer: no device present.
dfu-programmer atmega32u4 flash CUL_V3.hex
dfu-programmer: no device present.
makefile:148: recipe for target 'do_usbprogram' failed
make: *** [do_usbprogram] Error 1
LG blu
Hi,
beim 10. Versuch und dem Verzweifeln nahe hat es geklappt:
root@raspyFHEM:~/CUL_VER_161/Devices/CUL# make usbprogram_v3
dfu-programmer atmega32u4 erase || true
dfu-programmer atmega32u4 flash CUL_V3.hex
Validating...
23220 bytes used (80.98%)
dfu-programmer atmega32u4 start
Der einzige Unterschied zu den vorherigen Versuchen: Ich habe den CUL komplett abgezogen und mit gedrücktem Button eingesetzt.
In den meisten Anleitungen hatte ich lediglich gelesen, dass der Button gedrückt werden muss, um ein FW-Update durchzuführen...
lg blu
Hallo blue,
ich habe seit damals V 1.58 .. ohne Probleme !
Wohier hast Du die 1.61 und was bringt diese noch an Verbesserungen?
Ich ging damals auf die 1.58 weil ich die Firmware der Thermostate über OTA updaten wollten !
kvo1
Zitat von: kvo1 am 29 Dezember 2014, 00:35:20
... Wohier hast Du die 1.61 ... ?
Von hier (http://culfw.de/culfw.html)?
Zitat von: kvo1 am 29 Dezember 2014, 00:35:20... und was bringt diese noch an Verbesserungen?
Siehe hier (http://culfw.de/CHANGED)?
Gruß
Thomas
ZitatIn den meisten Anleitungen hatte ich lediglich gelesen, dass der Button gedrückt werden muss, um ein FW-Update durchzuführen...
Bevor hier der falsche Eindruck entsteht: Wenn man die richtige Doku liest, dann sollte eigentlich klar sein, was man machen muss.
http://culfw.de/commandref.html#flashing (http://culfw.de/commandref.html#flashing) : "CUL/CUN: Insert the USB-Stick
while pressing the micro-switch on the back"
Weil ich mich grade letzte Woche auch mit dem Flachen eines CUL an einem Raspi rumgeärgert habe, hier nochmals der ausdrückliche Hinweis:
- Um die Taste zu drücken, während man das Teil einsteckt und man womöglich noch die Variante IN DER PLASTIKUMMANTELUNG vor sich hat - das geht nicht, dafür braucht man mindestens drei Hände. Ich habe das Plastikgehäuse demontiert, dann hat man wenigstens ein haptisches Feedback, ob man den Schalter grade wirklich drückt oder nicht.
Desweiteren: Lt. Anleitung soll man folgende Anweisungen eingeben:
dfu-programmer atmega32u4 erase
dfu-programmer atmega32u4 flash CUL_V3.hex
dfu-programmer atmega32u4 reset
dfu-programmer atmega32u4 erase teilte mir mit, dass Stick bereits leer wäre. Okay. soweit in Ordnung.
dfu-programmer atmega32u4 flash CUL_V3.hex sagte dann, der Stick sei schreibgeschützt, weswegen ich meinen Fehler über Stunden beim Drücken der Taste vermutete. Ich hab das dann auf einem Win-Rechner probiert, mit gleichem Ergebnis.
Zurück im Raspi kam ich auf die Idee, den ersten Befehl zu "erzwingen":
dfu-programmer atmega32u4 erase --force
und schwups, das war's! Danach konnte ich mit dem zweiten Befehl den Stick flashen und er werkelt wie er soll. Vielleicht hilft's ja dem einen oder andern!
Zitat von: marc-willmann am 21 Januar 2015, 10:01:33
- Um die Taste zu drücken, während man das Teil einsteckt und man womöglich noch die Variante IN DER PLASTIKUMMANTELUNG vor sich hat - das geht nicht, dafür braucht man mindestens drei Hände. Ich habe das Plastikgehäuse demontiert, dann hat man wenigstens ein haptisches Feedback, ob man den Schalter grade wirklich drückt oder nicht.
Mhhh ich hatte da bisher keine Probleme mit. Mit ner Büroklammer drücke ich den ein und steck ihn dann in den USB Port. Vielleicht brauchts 2 Versuche, aber ne dritte Hand hab ich bisher nie gebraucht.
Hallo,
wenn man den CUL mit
B (http://culfw.de/commandref#cmd_B) und dem richtigen Parameter neu startet, sollte das Knöpfe Drücken eigentlich erledigt sein, oder? Setzt aber halt eine schon installierte culfw voraus ...
Gruß PeMue
Bei mir ging's um den initialen Flash; der klappte eben erst, als ich den "erase"-Befehl mit --force erzwungen habe. Ich war schon drauf und dran, den Stick zurückzuschicken, weil es partout nicht klappen wollte.
Und die Meldung, der Stick sei leer, hat mich auch nicht beunruhigt; das wusste ich ja schon vorher. :-)
Zitatwenn man den CUL mit
B und dem richtigen Parameter neu startet, sollte das Knöpfe Drücken eigentlich erledigt sein, oder? Setzt aber halt eine schon installierte culfw voraus ...
Hierzu sollte man eigentlich irgendwo mal ein How-To finden.
Bin schon einige Tage am suchen, aber nirgends findet man etwas.
Wie kann man einen CUL am PI oder Cubie updaten?
Zitat von: hyper2910 am 07 April 2015, 12:12:04
Hierzu sollte man eigentlich irgendwo mal ein How-To finden.
Bin schon einige Tage am suchen, aber nirgends findet man etwas.
Wie kann man einen CUL am PI oder Cubie updaten?
Das Flashen des CUL wird doch genau hier beschrieben, oder was meinst Du ?
Wie wird ein cul, am Pi upgedatet? D.h. Eine step-by-step Anleitung für Anfänger!
Zitat von: hyper2910 am 07 April 2015, 18:40:13
Wie wird ein cul, am Pi upgedatet? D.h. Eine step-by-step Anleitung für Anfänger!
ich habe das damals so gemacht !
FHEM beenden!
sudo apt-get install dfu-programmer
wget http://culfw.de/culfw-1.58.tar.gz
tar xfz culfw-1.58.tar.gz
cd CUL_VER_158/culfw/Devices/CUL
dfu-programmer atmega32u4 erase || true
dfu-programmer atmega32u4 flash CUL_V3.hex
dfu-programmer atmega32u4 start
FHEM starte!
Achtung ist für V1.58 .... aktuell ist wohl 1.61 siehe http://culfw.de/culfw.html (http://culfw.de/culfw.html)
(ggf die Pfade anpassen)
ich mußte auch den Taster drücken !
... gerade ist v1.63 aktuell.
Gruß PeMue
Zitat von: PeMue am 07 April 2015, 22:26:35
... gerade ist v1.63 aktuell.
Gruß PeMue
Hi Peter ;)
wo steht die ?
gruss
Klaus
Geht das ganze nicht direkt aus fhem? Es gibt ja den CULflash
Befehl und B<hex>Reboot device.
If <hex> is not 00 enter bootloader mode (for flashing the device see the flashing section above)
Aber wie das ganze zusammen gesetzt wird?
Hallo Klaus,
direkt im SVN, siehe http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUL/
Ich habe es noch nie gemacht, aber mit CULflash sollte es auch funktionieren (hat zumindest bei der FritzBox problemlos funktioniert), siehe auch hier
http://www.fhemwiki.de/wiki/CUL_an_einer_Fritzbox_7390_flashen
letztes Kapitel. Alles was unter Telnet geht, geht auch in der fhem Kommandozeile. CULflash holt sich immer die neueste Firmware aus dem SVN.
Gruß PeMue
@hyper2910 habe das bisher noch nicht mit CULflash gemacht , wenn Du´s hast poste das todo dann bitte hier
@Peter danke ! fritte habe ich nicht mit fhem , nur RPI und Cubi ;)
gruss
kvo1
Zitat von: kvo1 am 07 April 2015, 23:02:25
fritte habe ich nicht mit fhem , nur RPI und Cubi ;)
Das, was auf der FritzBox läuft, sollte doch zweimal auf vernünftigen Rechnern laufen ;D
Gruß und gute Nacht.
PeMue
Zitat von: hyper2910 am 07 April 2015, 12:12:04
Hierzu sollte man eigentlich irgendwo mal ein How-To finden.
Bin schon einige Tage am suchen, aber nirgends findet man etwas.
Wie kann man einen CUL am PI oder Cubie updaten?
Hi,
ging mir auch so. Letztendlich funktionierte es wie beim Hersteller beschrieben (ok, da hätten wir früher draufkommen können):
http://busware.de/tiki-index.php?page=CUL
unter Firmware. Insbesondere war bei mir entgegen anderslautender Infos im Netz das Drücken des Buttons notwendig.
Viel Erfolg + lg blu
. Insbesondere war bei mir entgegen anderslautender Infos im Netz das Drücken des Buttons notwendig.
Bei mir auch !
Steht ja auch so auf busware - Seite
kvo1
komisch, bei mir auf der FritzBox ging das bei mir mit CULflash vom Wohnzimmer aus (ohne Aus- und Einstecken bzw. drücken), einfach per Terminal ;) Vielleicht einfach mal auf dem Raspberry Pi probieren.
Gruß PeMue
So habe ich heute 2. März 2016 die Firmaware auf dem CUL aktualisiert bzw. geflasht.
Per SSH auf dem FHEM-Server angemeldet. (Das geht zum Beispiel mit PUTTY). Dann habe ich mir diese zwei Tools geholt:
sudo apt-get install dfu-programmer
sudo apt-get install build-essential
Danach besorgt man sich die aktuelle Firmware und packt sie aus. In meinem Fall ist das die Version 1.61:
wget http://culfw.de/culfw-1.61.tar.gz
gunzip culfw-1.61.tar.gz
tar xfv culfw-1.61.tar
dann in das gerade ausgepackte Verzeichnis navigiert mit:
cd CUL_VER_161/
cd Devices/
cd CUL
In der FHEM-Konsole (also im Browser-Fenster) habe ich den CUL wie folgt aktiviert:
set CUL_0 raw B01
[Alternativ muss man irgendwas drücken, während der CUL neu in die RaspBerry PI eingesteckt wird. War mir zu blöd]
CUL_0 heißt mein CUL in FHEM. Dort ist natürlich der jeweilge Name zu verwenden.
und zu guter letzt der eigentliche Flashbefehl:
sudo make usbprogram_v3
Fertig.
Zur Sicherheit gibt man wieder in FHEM folgendes ein um zu sehen, dass der Update erfolgt ist:
get CUL_0 raw V
Hier wieder den jeweiligen Namen des CUL in FHEM eingeben und nicht unbedingt CUL_0
Zitat von: PeMue am 09 April 2015, 21:35:50
komisch, bei mir auf der FritzBox ging das bei mir mit CULflash vom Wohnzimmer aus (ohne Aus- und Einstecken bzw. drücken), einfach per Terminal ;) Vielleicht einfach mal auf dem Raspberry Pi probieren.
Gruß PeMue
Wenn der CUL schon geflasht war, sollte ein "Update" direkt mit CULflash gehen. Habe ich noch nicht selbst probiert.
Ansonsten ziemlich einfach direkt in FHEM (http://heinz-otto.blogspot.de/2016/02/cul-stick-flashen.html) mit ein bisschen Vorbereitung im Terminal.
Gruß Otto
bin immer noch mit "V 1.58" unterwegs , vielleicht mach ich mal ein Update auf die letzte Version .... wobei "ohne Not" ??? ;)
@Otto... cooler Blog , viele nützliche Dinge !
klaus
Hallo,
auch hier ein alter Thread aber ich hänge mich dran.
Ich habe von eBay gem. der Anleitungen einen Arduino erworben (FTDI RS232 Arduino Nano V3.0 kompatibles Board Atmel ATmega328 16MHz). Da dran gem. Anleitung ein 868 MHz RF1101SE-V3.1 Modul gelötet.
Ich muss dazusagen, dass ich augenscheinlich ein weiteren Selbstbau JeeLink mit gleicher Arduino-Serien-Nr. am Raspberry angeschlossen habe. der o. g. CUL ist an ttyUSB2 angeschlossen. Er wird erkannt.
Leider erhalte ich immer diese Meldung:
pi@rasp16GB:/opt/fhem/FHEM/firmware/culfw-1.66/Devices/CUL $ make usbprogram_v3
dfu-programmer atmega32u4 erase || true
dfu-programmer: no device present.
dfu-programmer atmega32u4 flash CUL_V3.hex
dfu-programmer: no device present.
makefile:154: recipe for target 'do_usbprogram' failed
make: *** [do_usbprogram] Error 1
Wie bekomme ich das erste Mal dort etwas draufgeflasht?
Danke!
Hallo,
mal im makefile schauen wie der CUL bzgl. "program_usb" angesprochen wird.
Evtl./wahrsch. /dev/ttyUSB0!?
Wenn dem so ist, dann entsprechend ändern...
(oder alle anderen USB abstecken, booten und flashen, sollte dann auf USB0 hängen)
Beim Einbinden in fhem halt besser mittels /dev/serial/by-id bzw. /dev/serial/by-path
Gruß, Joachim
Das Problem wird die Seriennummer sein.
Aber flashen geht meines Wissens komplett mit FHEM (http://heinz-otto.blogspot.de/2016/02/cul-stick-flashen.html)
Gruß Otto
Stimmt, ganz übersehen
ZitatAtmel ATmega328
passt wohl nicht zu
Zitatatmega32u4
Dass die Probleme so weit vorne liegen können hatte ich gar nicht bedacht ;-)
Dann wurde aber bereits falsch "gebaut", daher wird das flashen wohl auch mit fhem nicht tun...
Zitat/opt/fhem/FHEM/firmware/culfw-1.66/Devices/CUL
besser mal nach
/opt/fhem/FHEM/firmware/culfw-1.66/Devices/nanoCULund dort noch mal probieren bzw. wird dann zumindest richtig gebaut...
Nicht vergessen "board.h" anzupassen: 16MHz ATMEL (nehme ich mal an) und 868MHz (Funkmodul wie von dir angegeben).
Da auch sichergestellt, dass es ein "echtes" 868MHz Modul ist!?
Gruß, Joachim
Hallo,
danke für die Hilfe. Ich habe soviele Anleitungen im Internet gesucht... Das habe ich dabei übersehen..
Also ich habe im Ordner nanoCUL "board.h" angepasst und "makefile" bzgl. des Pfades (by-id).
Ich erhalte leider nur:
pi@rasp16GB:/opt/fhem/FHEM/firmware/culfw-1.66/Devices/nanoCUL $ ls
board.h makefile nanoCUL.c nanoCUL.hex README
pi@rasp16GB:/opt/fhem/FHEM/firmware/culfw-1.66/Devices/nanoCUL $ make
Compiling C: nanoCUL.c
sh: 1: avr-gcc: not found
makefile:326: recipe for target 'nanoCUL.o' failed
make: *** [nanoCUL.o] Error 127
Ich hatte es hiernach probiert:
http://blog.gummibaer-tech.de/tag/cul-nachbau/
Das Modul auf dem Foto ganz unten des Blogs.
Das wird mir weiterhin ausgeworfen:
pi@rasp16GB:/opt/fhem/FHEM/firmware/culfw-1.66/Devices/nanoCUL $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Jun 28 22:46 usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Jun 27 06:35 usb-FTDI_FT232R_USB_UART_AI03DA01-if00-port0 -> ../../ttyUSB0
Dabei hängt bzw. ist an ttyUSB0 definitv ein Original Jeelink, an ttyUSB1 ein Jeelink-Nachbau und an ttyUSB2 der in Rede stehende nanoCUL
ttyUSB0 und ttyUSB1 funktionieren, da ich jeweils Kommunikation im Bereich LaCrosse und PCA301 habe.
Danke. Einen Hardwarefehler beim nanoCUL schliesse ich aus. Allerdings hat der die gleiche Seriennummer wie der Jeelink-Nachbau.
Hallo,
dir fehlt entweder die Entwicklungsumgebung:
avrgcc (Compiler) not found...
...oder er steht nicht im 'PATH'...
D.h. der build geht schon schief bzw. gar nicht erst los...
Gruß, Joachim
Habe mir den verlinkten Beitrag angesehen und es ist (auf den ersten schnellen Blick) alles beschrieben was notwendig ist...
Hast du auch folgendes durchgeführt:
ZitatCompiler und Tools installieren ,,sudo apt-get install make gcc-avr avrdude avr-libc"
Scheint bei dir nicht so geklappt zu haben...
...da der Compiler (avrgcc) nicht gefunden wird...
Ansonsten würde ich evtl. statt /dev/serial/by-id auf /dev/serial/by-path gehen (wie bereits beschrieben).
Halt mal immer nur einen USB-Stick stecken (wichtig immer den einen in die später vorgesehene USB-Buchse stecken, da ja diese "referenziert" wird) und 'ls /dev/serial/by-path/' und dann das eintragen (falls du das nicht schon selber so gemacht hast).
/dev/serial/by-id klappt nur, wenn die USB-Umsetzer deiner USB-Geräte alle eine eindeutige ID haben.
Ist bei den (meisten) billigen Arduino Nano aus China nicht so, meine zumindest haben alle die selbe ID, daher 'by-path'...
Aber das ist bei dir (noch) kein Thema, denn deine haben ja (wenn das alle USB-Geräte sind, die du von fhem etc. aus ansprechen willst) eindeutige IDs:
Zitat
pi@rasp16GB:/opt/fhem/FHEM/firmware/culfw-1.66/Devices/nanoCUL $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Jun 28 22:46 usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Jun 27 06:35 usb-FTDI_FT232R_USB_UART_AI03DA01-if00-port0 -> ../../ttyUSB0
Ach ja und es steht auch:
ZitatIm entpackten Ordner in den Unterordner /Devices/nanoCUL wechseln.
Bist du wirklich exakt nach der Anleitung vorgegangen??
Habe diese auch als Basis genommen (und bei weiteren mal gespickt, z.B. diesen im von dir genannten Beitrag verlinkten http://www.fhemwiki.de/wiki/Selbstbau_CUL (http://www.fhemwiki.de/wiki/Selbstbau_CUL)) und bei mir läuft es inkl. Bauen und Flashen ohne Probleme...
Gruß, Joachim
Hallo,
vielen Danke für die Hilfe.
Also... ,,sudo apt-get install make gcc-avr avrdude avr-libc" fehlte. Da ich aber beim Original JeeLink AVRDUDE nachinstalliert ahtte dachte ich es würde klappen.
Habe dann nacheinander den Original Jeelink, den Nachbau Jeelink, und den Nachbau nanoCUL eingesteckt, dazu neben dem PATH auch die IDs notiert:
Jeelink Original LaCrosse:
platform-20980000.usb-usb-0:1.2.4:1.0-port0
ttyUSB1
Jeelink Clone PCA301:
platform-20980000.usb-usb-0:1.3:1.0-port0
ttyUSB0
nanoCUL Selbstbau:
platform-20980000.usb-usb-0:1.5:1.0-port0
ttyUSB2
Hatte dann in Fhem unter DEF bei den Internals folgendes eingetragen:
"/dev/serial/by-path/platform-20980000.usb-usb-0:1.2.4:1.0-port0"
für den Original JeeLink. Aber dadurch waren dann LaCrosse und PCA301 Jeelink vertauscht. Es funktionierte noch irgendwie aber unter "model" wurde werder ...PCA301... noch ...LaCrosse... angezeigt.
Also hatte ich bei den beiden in FHEM eingebunden Adaptern (Jeelink Original und Nachbau) wieder das ganze über DEF:
/dev/ttyUSB1@57600
konfiguriert. Da hatte ich dann unter "model" auch den jeweiligen Modus wieder.
Das dazu.
Ich bin nochmals nach der Anleitung vorgegangen und habe im Ordner NanoCUL das makefile angepasst (1x mit path und 1x mit id) probiert...
Leider kommt das hier raus:
pi@rasp16GB:/opt/fhem/FHEM/firmware/culfw-1.66/Devices/nanoCUL $ make program
#@if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
#@if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
#echo out > /sys/class/gpio/gpio17/direction
#echo out > /sys/class/gpio/gpio18/direction
#echo 0 > /sys/class/gpio/gpio17/value
#echo 0 > /sys/class/gpio/gpio18/value
#sleep 1
#echo 1 > /sys/class/gpio/gpio17/value
#sleep 1
#echo 1 > /sys/class/gpio/gpio18/value
avrdude -D -p atmega328p -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -b 57600 -c arduino -U flash:w:nanoCUL.hex
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
avrdude done. Thank you.
makefile:216: recipe for target 'program' failed
make: *** [program] Error 1
Im makefile sind oben 8 MHz eingetragen... Es sind bei mir eigentlich 16 MHz...
Oder es liegt wirklich daran, dass ich zwei Arduinos mit gleicher Serien-Nr dran habe:
pi@rasp16GB:/opt/fhem/FHEM/firmware/culfw-1.66/Devices/nanoCUL $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Jun 30 21:36 usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Jun 30 21:36 usb-FTDI_FT232R_USB_UART_AI03DA01-if00-port0 -> ../../ttyUSB1
pi@rasp16GB:/opt/fhem/FHEM/firmware/culfw-1.66/Devices/nanoCUL $ ls -l /dev/serial/by-path
total 0
lrwxrwxrwx 1 root root 13 Jun 30 21:36 platform-20980000.usb-usb-0:1.2.4:1.0-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jun 30 21:36 platform-20980000.usb-usb-0:1.3:1.0-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jun 30 21:36 platform-20980000.usb-usb-0:1.5:1.0-port0 -> ../../ttyUSB2
[ 9.603469] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[ 9.603717] usb 1-1.3: Detected FT232RL
[ 9.638055] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
[ 9.643103] ftdi_sio 1-1.2.4:1.0: FTDI USB Serial Device converter detected
[ 9.643390] usb 1-1.2.4: Detected FT232RL
[ 9.655358] usb 1-1.2.4: FTDI USB Serial Device converter now attached to ttyUSB1
[ 9.655604] ftdi_sio 1-1.5:1.0: FTDI USB Serial Device converter detected
[ 9.655865] usb 1-1.5: Detected FT232RL
[ 9.672228] usb 1-1.5: FTDI USB Serial Device converter now attached to ttyUSB2
pi@rasp16GB:/opt/fhem/FHEM/firmware/culfw-1.66/Devices/nanoCUL $ lsusb
Bus 001 Device 007: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bei "by-id" fehlt einer...
Ich weiss nicht weiter... Kann jmd. herausfinden was ich falsch mache... Danke!
Hi,
also meine Definition des nanoCUL sieht wie folgt aus:
/dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400 1111
und funktioniert.
Habe by-path weil (wie bereits geschrieben!?) ich als Basis 2 "Billig-Nanos" habe die die selbe ID haben.
D.h. unter "by-id" steht immer nur der zuletzt eingesteckte drin.
Einer ist ein mySensors-Gateway und der andere ein nanoCUL wie es bei wohl dir einer werden soll.
In board.h folgendes tun (wenn du einen 16MHz Arduino hast):
/* if you have an Arduino with only 8MHz disable the next line */
#define HAS_16MHZ_CLOCK
und das, wenn du ein 868MHz Funkmodul hast:
//#define HAS_CC1100_433
Beim flashen würde ich mal nur das eine USB-Device stecken, welches du auch flashen willst (hatte auch schon mal aus Versehen meinen mySensors-Gateway als nanoCUL geflasht ;-) ).
Dann booten und sehen als was der dann erkannt/eingetragen wird.
also beispielsweise /dev/ttyUSB0 (vermutlich)
Das dann in das makefile eintragen und noch mal 'make' und 'make program'...
Da du auch mind. 2 mit selber ID hast musst du eigentlich (zumindest die beiden) per 'by-path' einbinden.
Die mit eindeutiger ID (aber nicht täuschen lassen von denen mit der selben ID, da steht immer nur der zuletzt gesteckte drin, funktioniert also nicht) dann per 'by-id' einbinden, wenn du das besser findest...
...oder alle by-path.
Dann halt nicht mehr umstecken natürlich.
Booten usw. ist kein Problem...
Ansonsten ist es (evtl.) Glücksspiel, ob die Zuordnung /dev/ttyUSB0, /dev/ttyUSB1, ... nach einem Boot noch stimmt....
...bzw. wie gedacht/definiert/eingerichtet ist.
Ansonsten natürlich aufpassen, dass fhem nicht läuft während des Flash-Vorgangs bzw. das was du flashen willst mindestens noch nicht dort definiert ist!
Da sonst der Port bereits belegt ist und avrdude nicht drauf kommt...
Evtl. auch usb-check in fhem mal deaktivieren...
Gruß, Joachim
Hallo Joachim,
danke für deine Anleitung! Ich probiere es heute abend mal...
Gleiche Fehlermeldung von avrdude...
Ich denke mit dem Arduino Nano stimmt was nicht...
Unter Windows/direkt am PC das gleiche:
C:\WinAVR-20100110\bin>c:\WinAVR-20100110\bin\avrdude.exe -C "c:\WinAVR-20100110\bin\avrdude.conf" -v -v -v -v -p atmega328p -c arduino -P COM6 -b 57600 -D -Uflash:w:nanocul.hex:i
avrdude.exe: Version 5.10, compiled on Jan 19 2010 at 10:45:23
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "c:\WinAVR-20100110\bin\avrdude.conf"
Using Port : COM6
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude.exe: Send: 0 [30] [20]
avrdude.exe: Send: 0 [30] [20]
avrdude.exe: Send: 0 [30] [20]
avrdude.exe: Recv:
avrdude.exe: stk500_getsync(): not in sync: resp=0x00
avrdude.exe done. Thank you.
Hallo,
hat der Arduino Nano überhaupt einen Bootloader drauf? Wenn nein, brauchst Du einen Programmer, z.B. USBASP.
Gruß PeMue
Hallo,
wahrscheinlich ist das das Problem. Ich dachte, dass wenn man nen Arduino kauft, dass dann einer drauf ist. Wegen des o. g. FTDI-Fehlers habe ich aber das Geld zurückbekommen. Insofern gehts..
Hmmm, hatte ich noch nie und ich hab mir ja schon so einige bestellt...
Also außer ich habe bewusst "nur" einen ATMEGA bestellt...
Gut, einen ATtiny/Digistump habe ich mal "verfused"... ;-)
Danach ging auch nix mehr...
...aber war ja nicht wirklich teuer...
Da viel rumtun lohnt nicht...
D.h. du versuchst es mit einem andern noch mal!?
Viel Erfolg!!
Gruß, Joachim
Ich habe vor ein paar Jahren alles selber gelötet. Aber davon bin ich weg. Also geflasht habe ich auch schon so einiges...