Posts by Alex Thiel

    Hallo,

    wenn der Controller beschrieben wurde und danach die Meldung "missing device" aufkommt, wurden garantiert die Fusebits umgestellt (je nach Ausstattung des Adaters auf Quarz oder Oszillator). Ansonsten das Übliche: Kaltlötstellen, Leiterbruch u.ä.
    Was ich mal beobachtet habe: Bei langsamer Taktung des Atmegas (4MHz) wollte das Ding ab und zu nicht so richtig, manchmal kam "missing device". Mit aktiviertem CKOPT oder externem Oszillator ging es dann aber.

    Eure Adapter sind alle scheiße, das habe ich dem Themenersteller damals auch geschrieben. Warum diese Minimalbeschaltung, die nur Ärger verursacht? Baut Euch einen anständigen Adapter, auf dem alle Widerstände und Kondensatoren drauf sind, die erforderlich sind. Wer über LPT flashen will am besten gleich mit Bustreiber (SN74HC244 oder SN74HCT244) und Oszillator statt Quarz, oder beides.

    Die Fuses: Siehe das Bild von sven11, so muss es bei PonyProg und nur bei PonyProg gemacht werden! Wer einen Oszillator auf seinem Programmieradapter hat, kann alle CKSEL-Kästchen aktivieren, dann reagiert der ATmega nur noch auf externen Takt. Dann muss der DMX-Empfang und Versand sowohl über den Mode 6 als auch an einem echten DMX-Gerät klappen, wenn der Rest auch geht. Wenn man das BODEN vergessen hat, kein Problem, kann man nachholen und außerdem funktionierts auch so. Es kann nur vorkommen, dass das Interface die Timing-Einstellungen beim Neustart vergisst.

    Da gibt es Möglichkeiten:
    -Schreib' einen der beiden DE-Menschen an
    -Interface öffnen und nachsehen, man sollte mit kleinen Elektronikkenntnissen sofort +- und --Pol ausfindig machen können. Achtung, die Garantie könnte flöten gehen!
    -Für Ungeduldige: Ausprobieren. Wenn DE nicht am Verpolungsschutz gespart hat (davon gehe ich mal zu 99% aus), wird eine falsche Polung keinen Defekt verursachen, das Gerät geht lediglich nicht an.

    Wenn es noch nichtmal erkannt wird und nichts leuchtet, gute Nacht! :P
    Wenn der USB-Kram Probleme macht ("Unbekanntes Gerät"), liegts meistens an schlechten Lötstellen. Oder Gerät deinstallieren und neu einstecken, hat bei manchen ebenfalls Probleme gemacht bzw. zur Lösung geführt.

    Ansonsten kann es alles sein, z.B. falsch programmierter μ-Controller. Daher würde eine möglichst präzise Fehlerbeschreibung weiterhelfen.

    Das gleiche Problem hatten wir auch: Es lag an einer Kaltlötstelle des USB-Controllers, und zwar an der Verbindung zum ATmega. Welche genau, das lässt sich im Nachhinein leider nicht mehr festellen, jedenfalls hat mehrfaches Nachlöten der USB-Verbindung (Buchse, Widerstände usw.) nichts gebracht. Der Fehlerzustand "unbekanntes Gerät" wird in dem Debug-PDF zwar beschrieben, aber es lag eben nicht an der Verbindung USB zum USB-Controller.

    Dann hat Alex mal die anderen Verbindungen nachgelötet und schon gings! ;)

    Sein Kumpel - wir hatten ja so eine Aktion hier laufen und weil er ständig weg war, hab ich mich um die Sachen gekümmert (verschicken usw.). Und weil ich das Geschreibe manchmal nicht unkommentiert stehenlassen konnte, hab ich manchmal hier rumgespammt!

    Hier hat zwar nie Alex geschrieben, aber ist ja egal :P

    Dann hats ja doch funktioniert, wie es sein soll. Hast Du die BODEN-Fuse denn beim schreiben der Fusebits mit aktiviert? Das sollte man ggf. nochmal machen bzw. prüfen, denn sonst vergisst das IF ev. die Timingparameter beim Neustart.

    Olaf, entschuldige bitte meine Unverschämtheit, aber für mich klingt die Antwort nach "Ich werfe mal mein Halbwissen in den Raum".

    Wenn man den Grund für den Kondensator erörtert, wird man feststellen, dass die Anforderungen (Spannungsfestigkeit, ESR, Induktivität, Leckstrom usw. usf.) an das Bauteil sehr geringe sind. Man kann da ohne weiteres 1kV-Kondensatoren reinknödeln, wenn man sie irgendwie unterbringen kann.

    Und ich werde bei Gelegenheit eine Art Anleitung verfassen, wie das Flashen funktioniert. Gerade das ist der Stolperstein schlechthin, denn der Rest ist im Grunde malen nach Zahlen, also "nur" löten.

    Achja, einen gewünschten Programmieradapter findet man z.B. hier. Ich würde folgende Änderungen vorsehen: Statt Quarz lieber einen Oszillator nehmen, das ist sicherer. Den Aufbau kann man auf einer Streifenrasterplatine machen; wenn man eine stabilisierte Spannung (5VDC, z.B. vom USB-Port) hat, bleiben nur noch drei Bauteile übrig - dafür lohnt sich das Ätzen einer Platine nicht. Oder man macht einen fliegenden Aufbau mit Steckbrett.

    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.

    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" :P
    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.

    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.

    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.

    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?

    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)?

    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.

    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.