Flashen Atmega 8515

Tach,

vergiss' die Firmware, die kannst Du ignorieren. Der Code-Generator erzeugt nach Eingabe der gewünschten Seriennummer eine Datei mit der Endung .hex, die man mit PonyProg öffnet. Normalerweise ist bereits der richtige Controller eingestellt (AVR micro, ATmega 8515). Zum beschreiben gehst Du auf "Command" und "Write all".

Versuch' mal, die Fusebits auszulesen. Wenn das beim fabrikneuen(!) Atmega schon nicht funktioniert, ist irgendwas faul mit dem Adapter.

Wenn "Write All" gewählt wurde, wird beides gemacht - das ist der Sinn dahinter.

Den Schreibvorgang erkennts Du an der Fortschrittsanzeige (mit dem Ladebalken), wenn der noch nichtmal kommt, wurde nichts geschrieben - das kann verschiedenste Ursachen haben, weil es nicht sein kann, dass der ATmega beim schreiben erkannt wird und danach nicht mehr die FBs auszulesen sind. Falls doch, wird es wohl ein Wackelkontakt, instabile Versorgung oder was-weiß-ich sein.

Bist Du sicher, dass die Fusebits nicht geändert und geschrieben worden sind? Weil das wäre so der Standardfehler, gerade wenn man bei PP alle Haken für CKSEL macht und der Adapter keinen Quarzoszillator hat.
Der beschriebene Fehler geht eigentlich garnicht, ist das reproduzierbar?

Du kannst den ATmega bei erfolgreichem Schreiben trotzdem ins Interface einsetzen - das IF muss vom PC erkannt werden! Der Loopback-Test (Test.exe, Modus Nr. 6, Scan) muss bei verbundenen DMX-In und -Out-Buchsen funktionieren. Nur wird die Kommunikation mit DMX-Geräten nicht gehen, weil die Taktung des Controllers falsch bzw. unterschiedlich ggü. den DMX-Geräten ist.

Achja, da oben habe ich Blödsinn geschrieben: Das EEPROM wird trotzdem beschrieben, dazu öffnest Du die Datei mit der Endung .eep. Darin stecken die Werkseinstellungen für die Timingparameter usw. Später kann man das EEPROM über die Test.exe via USB beschreiben und die Parameter ändern.

Dazu schweigt sich die Anleitung aus, und ich muss leider zugeben: Ich habe keine Ahnung. Sehr wahrscheinlich ist es das aus dem Generic-Ordner, jedenfalls sieht das plausibel aus und sollte gehen - ausprobieren.
Dass der Codegenerator keine .eep erzeugt ist kein Problem, da die Konfiguration unabhängig von der Seriennummer ist. Man kann das EEPROM auch komplett unbeschrieben lassen, man muss dann aber später über die Test.exe die Timings nochmal manuell einstellen und mittels "Store" im Controller speichern.

Deine Fehlerbeschreibung ist mir zu dürftig - lassen sich die Atmegas jetzt garnicht mehr ansprechen (auslesen von Flash- und EEPROM)?

Also wenn das Gerät vom PC fehlerfrei erkannt wird und:
-Über die Test.exe (dieses grüne Ding mit gelbem Blitz in dem Projektordner) erkannt wird (man sieht die Seriennummer)
-und angesprochen werden kann ("Open Link", dann einen Modi wählen, außer bei "0: Standby" MUSS die DMX-LED leuchten, weil dann der DC/DC-Wandler eingeschaltet wurde und somit der Datenaustausch erfolgen kann)
ist das schon viel wert.

Bitte etwas präzisieren, was jetzt genau funktioniert und was nicht.

So wie ich das bisher sehe, hat die Programmierung funktioniert, wenn das o.g. geklappt hat. Dann ist irgendwas mit dem Adapter nicht in Ordnung, die Fusebits müssen auf jeden Fall geändert werden, sonst wirds nix mit DMX. Welcher ISP-Adapter wird denn benutzt?

Ich garantiere Dir sogar, dass der DMX-Empfang nicht arbeiten wird, denn: Die Fusebits sind bei einem fabrikneuen ATmega auf einen internen 1MHz-Taktgeber eingestellt. Das ist viel zu langsam und außerdem ungenauer als z.B. ein Quarz oder Oszillator. Die Anmeldung am PC klappt trotzdem, aber vom Takt hängt der Datenverkehr für DMX-Signale ab.

Ich meinte nicht den Adapter von RS232 auf ISP, das war schon klar, sondern den Adapter ISP zu ATmega. Also wo steckst Du den ATmega zum flashen rein? Die Anleitung von Hölscher bezieht sich auf seine Bauten und diese haben eine ISP-Schnittstelle, das DE-IF aber nicht.

Wo? Auf der DE-Platine?

Lass' Dir doch nicht alles aus der Nase ziehen...........was nach welchem Schaltplan (Link dazu)?

Man kann die Fuses nicht unabsichtlich verstellen oder Du verschweigst das - klingt für mich bisher aber danach, weil: Schreibt man die Fuses auf externen Taktgeber (CKSEL0 bis 3 haben alle Haken bekommen, Achtung: NUR unter PonyProg!!) um, dann geht das und wird gemacht, danach kommt aber die Fehlermeldung -24 missing device, wenn auf der Programmierplatine KEIN externer Taktgeber an XTAL1 (Pin 19) angeschlossen ist, sondern ein Quarz oder garnichts. Der Controller kann nicht mehr erkannt werden, weil der Takt fehlt. Die Fusebits sind trotzdem korrekt geschrieben worden und für externen Taktgeber wäre das ein Traum, weil im DE-IF ein externer Taktgeber selbigen vorgibt - er kommt vom USB-Controller. Der Quarz auf der Platine ist nämlich nicht für den ATmega vorgesehen (s. Schaltbild), sondern für den USB-Controller.

Das ist der Standardfehler, nämlich a) die Haken-Geschichte bei PonyProg und b) dass fast jede Programmierplatine den blöden Quarz anstelle eines Oszillators haben, das würde dieses elende Anfängerproblem nämlich zur Bedeutungslosigkeit verdammen.

Quote

Es hat alles einwandfrei geklappt bis ich auf Read Fuses geklickt habe. Dann habe ich die Häkchen anders gesetzt und sobal ich auf Write Fuses klicken wollte kam die Meldung Missing Device.

Aja, soviel zum Thema "Ich habe nichts gemacht"
Dann ist ja alles in Ordnung, wenn Du die Haken so gesetzt hast, wie vorgesehen wurden die Fusebits geschrieben. Wenn nicht: Pech gehabt, Lösung kommt gleich.

Der ISP-Adapter ist mir schon klar, das PDF habe ich längst durch. Es reicht aber nicht aus, einfach Masse, MISO, MOSI, SCK, Reset und die Betriebsspannung an den Atmega zu hängen. Das heißt, es reicht eigentlich schon, das ist die absolute Minimalbeschaltung, die aber unsauber ist. Man sollte für eine sichere Funktion nämlich Stützkondensatoren sowie Pullup-Widerstand für den Reset-Anschluss vorsehen.
Das Wichtigste ist aber ein Taktgeber, der fehlt in Deiner Beschaltung völlig! Dass man trotzdem ein Programm aufspielen konnte, lag an dem voreingestellten internen Taktgeber des ATmegas, der den Takt diktiert. Sobald man aber irgendwas an der Konfiguration der Taktquelle über die Fusebits (CKSEL0 bis 3) ändert, ist Essig mit der Kommunikation.

Viele Schaltungen sehen ISP vor (In-System-Programmierung), und dafür ist der Adapter auch gedacht. Der Gag bei der ISP ist, dass der Controller aus der Zielschaltung zur Programmierung nicht entfernt werden muss - das wäre bei bereits verlöteten oder SMD-Bauteilen sehr umständlich. Das geht deswegen, weil ein Teil der Beschaltung sowohl zur Programmierung als auch im späteren Betrieb ohnehin nötig ist, z.B. bei Hölschers Schaltungen der Quarz mit den Kondensatoren. Mehr dazu hier: http://www.mikrocontroller.net/articles/AVR_Checkliste

Es gibt natürlich besondere Fälle, in denen der Controller zuerst außerhalb der Zielschaltung geflasht werden soll - das DE-IF hat ja keine ISP-Schnittstelle, deswegen muss der ATmega zuerst in einen Adapter gesetzt werden. Diese Adapter haben die benötigten Teile (Pull-Up-R, Kondensatoren, Quarz) und wiederum eine ISP-Schnittstelle, die man über einen ISP-Adapter mit dem PC verbinden muss. Würde man nämlich seinen ISP-Adapter tauschen müssen (z.B. weil der neue PC keine RS232-Schnittstelle mehr hat), kann man den Adapter für den Controller weiterhin benutzen.

Du kannst die Fusebits trotzdem auslesen und schreiben, dazu muss lediglich eine externe Taktquelle vorliegen. Zufälligerweise hat der USB-Controller im Interface einen Taktausgang mit 4MHz (CLKOUT), der sollte auch arbeiten, wenn das IF an USB hängt und kein ATmega drinsteckt.
Den Taktausgang (Du kannst den Takt einfach an Pin 19 am Sockel des Atmegas mit einem Draht abgreifen, dann muss man da nicht extra rumlöten) schließt Du an den Pin 19 des "verfusten" ATmegas an, der wiederum an den ISP-Adapter angeschlossen/gesteckt ist (und der wiederum am PC hängt). Beide Massen (GND) müssen natürlich ebenfalls verbunden werden, also Masse IF mit Masse Programmieradapter!

Jetzt sollte der ATmega wieder über PP angesprochen werden können.