Hallo zusammen,
Hat jemand von euch noch zufällig oben genannte Firmware als hex Datei?
Bräuchte die für Testzwecke, finde sie aber nirgends.
Gruß Dirk
Hallo Dirk,
für einen CUL ? Oder meinst Du für den S'duino ?
Grüße Markus
Hallo Markus
Sorry, für den Signalduino.
Gruß Dirk
Ich weiß nicht, was b12 bedeuten soll aber vielleicht kommst Du hier (https://github.com/Ralf9/RFFHEM/tree/dev-r32) weiter..
Erstmal Danke für die Antwort.
Die Seite hab ich gestern auch schon gefunden, allerdings finde ich da nirgends den CC1101.
Außerdem hab ich keinen blassen Schimmer, wie ich von da die Firmware bekomme.
In FHEM den Befehl set sduino flash und dann den Link?
ZitatDie Seite hab ich gestern auch schon gefunden, allerdings finde ich da nirgends den CC1101.
Klar ;D denn dann sind wir wieder bei der Bezeichnung CUL(ist aber nur der Hardware-Ursprung Arduino Nano mit CC1101). Wenn es bei Dir ein nano ist, müsste set sduino flash https://github.com/Ralf9/RFFHEM/blob/dev-r32/FHEM/firmware/SIGNALduino_nano328.hex funktionieren.
Ich bin aber kein S'duino-Spezialist !!!
Nu isser hin :(
bekomme keine Firmware mehr aufgespielt...
Zitat von: Feinfinger am 15 März 2018, 13:18:59
Hat jemand von euch noch zufällig oben genannte Firmware als hex Datei?
Zu was benötigst Du so eine alte Firmware von Anfang 2016?
Die Firmware 3.2.0 gab es noch nicht für den cc1101.
Die erste Firmware für den cc1101 gab es Mitte Dezember 2016.
Gruß Ralf
ZitatNu isser hin
Na, das kann (eigentlich) nicht, auch wenn es eine falsche(bin ich jetzt fast sicher) hex war.
Was hast Du denn konkret gemacht ? Welche Meldungen ? Ab-/angestöpselt ?
Was passiert bei set sduino flash https://github.com/Ralf9/RFFHEM/blob/master/FHEM/firmware/SIGNALduino_nanoCC1101.hex ?
Hallo.
Zum einen wird diese Firmware immer im Zusammenhang mit dem Modul Dooya gebracht, sie soll die FB am zuverlässigsten erkennen.
Das wollte ich zu Testzwecken ausprobieren.
Hier der log zum Flashvorgang.
Opening sduino device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CUWN-if00-port0
2018.03.16 07:18:56 3: Setting sduino serial parameters to 57600,8,N,1
2018.03.16 07:18:56 1: sduino/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CUWN-if00-port0@57600
2018.03.16 07:18:56 1: sduino/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CUWN-if00-port0@57600
2018.03.16 07:18:56 3: sduino device opened
2018.03.16 07:18:57 3: sduino/init: disable receiver (XQ)
2018.03.16 07:18:58 3: sduino/init: get version, retry = 0
2018.03.16 07:19:08 3: sduino/init: get version, retry = 1
2018.03.16 07:19:18 3: sduino/init: get version, retry = 2
2018.03.16 07:19:28 3: sduino/init: get version, retry = 3
2018.03.16 07:19:28 2: sduino/init retry count reached. Closed
2018.03.16 07:19:28 2: sduino closedWenn ich über Linux direkt versuche kommt immer:
Zitatavrdude stk500_recv() programmer is not responding
Änderung der Baudrate sowie komplett weglassen der Angabe -b 57600 brachten keine Erfolg.
Der Nano war auch als device bei FHEM gelöscht und FHEM selber gestoppt.
Gibts noch etwas, das ich probieren könnte?
ZitatZum einen wird diese Firmware immer im Zusammenhang mit dem Modul Dooya gebracht, sie soll die FB am zuverlässigsten erkennen.
Aber dann vermutlich nicht mit einem CC1101 :'( Da wäre es wohl besser sich mit dem Problem in Ralf's development version und Thread reinzuhängen.
Aber dafür muss er ja erst mal wieder laufen. Guck doch mal auf Linux-Ebene, ob
- mit dmesg Auffälligkeiten zum nano erkennbar sind
- mit ls -l /dev/serial/by-id ob der nano angelegt ist (als ttyUSB0 ?)
- mit welcher konkreten Befehlszeile hast Du das Flashen auf der Linux-Ebene probiert
avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CUWN-if00-port0 -p atmega328p -vv -U flash:w:./FHEM/firmware/SIGNALduino_nanoCC1101.hex
Angelegt ist der Nano.
Wenn avrdude diese timeouts bringt, kann es auch an zwei anderen Dingen liegen:
- Initialisierung nach reboot des ATMega32 klappt nicht -> Test-PIN-Problem (FHEM-Wiki zu Arduino)? Bitte als erstes prüfen...
- Bootloader kaputt (dann Wiederbelebung über einen anderen Arduino als ISP-Programmer oder mit entsprechender Hardware).
Evtl. klappt es auch, wenn du manuell den REstart mit dem Reset-Knopf auslöst, unmittelbar vor Start des Flash-Vorgangs.
Die Testpin Problematik kenn ich, ist es nicht. Da gibts ne Lötbrücke. Er lief ja auch bis zum Flash mit der vermeintlich falschen Firmware.
Denke es ist der Bootloader.
Wäre jetzt allerdings Quatsch, nen Programmer für 20 Euro zu kaufen, um ein 6 Euro Teil zu reparieren:-)
Das mit dem Resetknopf habe ich auch schon probiert, allerdings vielleicht nicht richtig. Muss mich da nochmal einlesen.
Nur für mich zum Verständnis: Kann man denn mit der ,,falschen" hex den bootloader himmeln?
"Himmeln" geht nach meiner Erfahrung nicht; allerdings kann man uU. auch nicht flashen, wenn bootloader und hex nicht aufeinander abgestimmt sind (ist evtl. hier auch das Problem).
Und wie gesagt: man braucht keinen Programmer für 20 Euro (gibts auch für 2 Euro beim Chinesen), es reicht ein weiterer Nano, geflasht als ISP (ist ein Standardsketch, der in der Arduino-IDE mit ausgeliefert wird). Den Nano kann man dann hinterher auch wieder anderweitig verwenden...
Und das mit dem Reset-Knopf sollte hinfällig sein, wenn der FTDI richtig funktioniert.
sehe ich auch so, zumal die hex ja nur "falsch" für die Funktion mit dem cc1101 ist, also nur nicht funktechnisch funktioniert.
Hast Du beim Flashversuch aus Linux heraus sichergestellt, dass FHEM den nano nicht im Zugriff hat ? shutdown oder kein device für den serial Port ?
ZitatUnd das mit dem Reset-Knopf sollte hinfällig sein, wenn der FTDI richtig funktioniert.
Sicher :-\ ? Ich hab den Reset-Knopf so verstanden, dass der nano dann den Bootloader durchläuft(Aufleuchten von L-LED), was dann evtl. das Flashen wieder ermöglicht. Wenn es etwas mit dem FTDI zu tun hätte, müsste man doch eine Reaktion mit dmesg erkennen können, oder ?
Also das mit falsch: Jedenfalls mit der Arduino IDE geht es nicht, einen Sketch, der comiliert wird für einen Nano mit dem MySensors-OTA-Bootloader auf einen Arduino zu flashen, der einen anderen Boorloader nutzt (z.B. den Standard). Ob so eine Konstellation vorliegt, wäre also auszutesten...
Was die "falsche" hex für den CC1101 angeht: m.E. ist es für das flashen erst mal gleichgültig, ob der Arduino mit daran angeschlossener Hardware dann umgehen kann oder nicht, das zeigt sich erst im 2. Schritt (wenn dann z.B. ccconf nichts zurückliefert).
Versuch' doch erst mal, auf den Arduino irgendwas anderes (mit der IDE, also aus dem Quellcode ) zu beamen, es reicht ein "Blink". Wenn das klappt, sehen wir weiter. Die normale Einstellung für "Nano" sollte gehen. Achtung: Es gab neulich einen update der Board-Definitionen; mit denen konnte ich dann auch diverse Arduinos nicht flashen, von denen ich wußte, dass sie ok sind (sieht man, wenn man die Boards auswählt. Wenn da was von "alter Bootloader steht: Downgrade mit dem Boardmanager machen auf die Vorversion).
Hallo zusammen,
ich geb auf.
Hab den Nachmittag damit verbracht um mit einem UNO den NANO bootloader zu retten.
Klappt nicht, ist wohl ein China Clone und den will die Arduino ISP nicht flashen.
Hab mir nen Neuen bestellt.