Handhabung & Technik El Fueradoro - Funkzündanlage mit Interface

Nach dem Raspeasyfire Neustart, kann ich den „alten“ wieder beschreiben.
Nur nach dem ich es beim neuen probiert habe, geht es nicht mehr.
RX TX blinkt am Rasp während der Übertragung

 

Einen CH340 hatte ich noch nie an den Raspberry Pi angeschlossen, ist denn sicher, dass er sich dort entweder wie ein FTDI-Chip (als /dev/ttyUSB0) oder ein MCP2221 (als /dev/ttyACM) anmeldet? Nach anderen Devices wird bisher nicht gesucht.

Was die Antwort des Programmiertools angeht, sind mir die Hände gebunden. Das stammt nicht von mir und ich kann nur den Rückgabewert interpretieren. Wenn der im Timeoutfall identisch zum Erfolgsfall ist, stehen die Chancen leider schlecht, das Ergebnis korrekt zu erfassen.

 

Muss ich ehrlich zugeben, hab ich noch gar nicht geschaut. Dadurch, dass der Programmiervorgang startet wenn er eingesteckt ist und nicht gleich fehlschlägt, wie z.B. ohne was eingesteckt ist, hab ich angenommen, dass er erkannt wird.
Ist denn die Baudrate fix eingestellt? Oder wird die ermittelt? Nicht dass es einfach nur ewig dauert und ich zu ungeduldig bin.

Aber jetzt hab ich einen Ausgangspunkt für meine Suche, vielen Dank !

 

Ich habe mit dem CH340 bereits über den PC die Firmware mehrfach geschrieben.
Der Chip als solches ist also brauchbar.

Am RPi müsste er sich eigentlich als ttyUSBx anmelden.

 

Die raspEasyFire-Oberfläche ist zum Finden des Fehlers sicher nicht geeignet, man braucht da mehr Transparenz, was während des beabsichtigten Updatevorgangs wirklich passiert. Daher würde ich mal in die Konsole gehen und dort zum El-Fueradoro-Unterordner wechseln:

cd ~/raspEasyFire3/el-fueradoro

Von dort dann das Update-Skript mit dem entsprechenden Firmware-Image starten:

sudo ./flash_firmware.sh IMAGE

IMAGE muss aus folgender Liste kommen, abhängig davon, was man auf der Gegenseite programmieren will:
V1-V2-RFM69CW13DBM
V1-V2-RFM69HCW20DBM
V3_16-RFM69CW13DBM
V3_32-RFM69CW13DBM
V3_16-RFM69HCW20DBM
V3_32-RFM69HCW20DBM
MINIMODUL_4-RFM69CW13DBM

Das Skript sollte ziemlich am Anfang die Info "Target: /dev/..." ausgeben, dann sieht man schon einmal, welches Device (in der Windows-Welt: welcher COM-Port) verwendet wird. Ansonsten einfach mal schauen, was so an Output kommt.

 

Also der Chip wird als ttyUSB0 erkannt.
Beim Übertragen kommt „ warte auf Device“
Das gleiche von Windows.
Hier mal mein Schaltplan, beim CH340C kann man doch net viel falsch machen ..

 

Kann man den vielleicht konfigurieren, dass er Handshakes verwendet?
Evtl. muss bei nicht Nutzung einer der Handshakes hardwaremäßig auf HIGH/LOW gezogen werden...

Edit: Versuche vielleicht mal CTS auf LOW zu ziehen...

 

CTS auf GND ziehen wäre auch meine erste Idee gewesen, generell sollten Inputs ohne Pullup/Pulldown nie offen gelassen werden.

 

Werd ich definitiv mal versuchen, hatte mir u.a. den Schaltplan als Basis rausgesucht.



wie aufwändig wär es, die Firmware über den AVR MK2 hochzuladen?
Dann könnte ich den Atmel ausschließen

 

Der Aufwand ist sehr gering, man kann anstelle des Bootloaders auch einfach die Firmware schreiben (hat dann aber natürlich nicht mehr die Möglichkeit, die Software per serieller Schnittstelle zu aktualisieren). Mit der avrdude.exe (liegt im El-Fueradoro-Repository unter Hexfiles/Bootloader/tools/, dorthin am besten auch das korrekte Firmware-Hexfile kopieren) geht es so:

avrdude.exe -p m328p -c avrispmkii -P usb -u -U flash:w:FIRMWAREDATEI:a -U lfuse:w:0xf7:m -U hfuse:w:0xd1:m -U efuse:w:0xfd:m -v​

Die HFUSE muss bei Betrieb ohne Bootloader mit 0xD1 beschrieben werden, mit Bootloader ist es die 0xD6.

 

Für AVRDUDE gibt es unter Windows auch eine graphische Oberfläche namens AVRDUDESS, falls man nicht mit der Kommandozeile arbeiten will.

 

Hab die Firmware jetzt direkt aufgespielt, läuft dennoch nicht.
D.h. Ich muss den Fehler an anderer Stelle suchen.
Allerdings in dem unveränderten Teil der Schaltung.

 

AVRDUDE sagt, die Firmware sei erfolgreich aufgespielt und die Fuses korrekt gesetzt worden, aber du siehst den üblichen Startvorgang der Platine mit der LED-Sequenz nicht? Hast du die Firmware mit Spannungseinspeisung über den Programmer geschrieben oder mit der normalen Energieversorgung? Kannst du die 3,3 V an den Versorgungspins des Controllers messen?

 

Ich hab den alten orginalen 6pin MK2
der liefert keine Spannung,
Das Atmel Studio zeigt die 3,3v an.
Mit dem Studio hab ich auch geflashed, da avrdude die usb-lib Treiber für den echten MK2 bräuchte

Ich hab grad den Quarz im Verdacht, Bau heut Abend ne neue Platine auf.

 

Wenn du die Fuses für die Taktquelle beim ersten Schreiben des Bootloaders von "Interner Oszillator" auf "Quarz" umgebrannt hast, was passiert, wenn man den raspEasyFire zum Schreiben des Bootloaders verwendet, und die nachfolgdenden Schreibvorgänge auf den Controller wirklich geklappt haben, dann scheint der Quarz auch zu funktionieren. Ansonsten wäre der Controller jetzt nicht mehr ansprechbar.

 

Kann ich mit diesem Programmer die Zündboxen und Raspeasyfire programmieren?
https://www.reichelt.de/at/de/progr...controller-diamex-all-avr-p110345.html?&nbc=1

 

Du kannst damit die Zündboxen über einen PC oder über den raspEasyFire programmieren. Den raspEasyFire kannst du damit nicht programmieren, ist auch nicht notwendig.

 

ok, verstehe vielen Dank

 

So, kleines aber umso peinlicheres Update von meiner Seite.

die 4 LEDs aus meiner Bastelkiste waren Schrott, somit konnte die aufgespielte Firmware kein Blinken beim Start signalisieren.

Aktueller Stand:
Firmware ist drauf, ohne Bootloader
LEDs blinken beim Start
Funk geht
Scharf schalten geht.
Ausgänge (1-16) gehen (N-MOSFETS)

USB geht nicht
3,3V (Designfehler, war vorher schon bekannt)

P-MOSFET noch ungetest.

 

Ich habe für mich die Platine noch ein wenig angepasst. Vor allem das RFM Modul sitzt nun direkt auf der Platine. Dazu habe Ich von von SMA auf RP SMA gewechselt. Mit der Reichweite und Funktion bin Ich sehr zufrieden, hier mal ein erstes Bild der Platine. Bilder von der fertigen Anlage kommen demnächst.

 

Und warum das?

 

Ich finde die Antennen um einiges robuster. Kosten zwar ein wenig mehr bringen aber laut Datenblatt 9dB

 

Was soll "machen 9 dB" heißen? Reden wir von 9 dBi oder 9 dBd? Mit 9 dBi wärst du mit dem HCW gerade noch im Bereich der zulässigen Sendeleistung von 500 mW ERP, 9 dBd würden den zulässigen Wert um 2 dB überschreiten. Macht euch mit den Limits vertraut, sonst kann es sehr teuer werden.

 

So, mein USB geht jetzt auch.

nachdem ich die Firmware direkt mit dem AVR MK2 aufgespielt hatte, hab ich mich nochmal weiter an der USB Kommunikation auf Fehlersuche begeben.
Ich konnte per USB den AES-Schlüssel auslesen.

in einem Elektronik Forum, wurde mir der Tipp gegeben, DTR vom CH340C über 100nF auf den Reset des Atmega zulegen.
Und siehe da, es funktioniert wie gewünscht.
Keine Ahnung wie der MCP2221 das macht, oder ob ich das irgendwo übersehen habe.

 

Die Antenne bringt 9dBi und liegt daher noch im Rahmen. Ich finde diese Antennen eben etwas robuster verbaut. Klar kann man darüber streiten ob der Aufpreis pro Antenne von knapp 3 Euro etwas bringt. Daher sagte ich ja auch das ich es für mich so gemacht habe. Der Test gestern auf dem Acker war sehr gut, und von daher hat es sich für mich die kleine Anpassung gelohnt.