Guten Abend allerseits, ich habe mir eine kleine Testschaltung mit einem AT89S52 (die 40Pin-Version, falls das einen Unterschied macht) aufgebaut, die ich jetzt per ISP (Der von http://rumil.de/hardware/avrisp.html) programmieren will. Der Programmieradapter funktioniert mit einem Atmega8 wunderbar (gerade eben nochmal getestet), scheidet also als Fehlerquelle höchstwahrscheinlich aus. Die ISP-Anschlüsse habe ich auch schon sehr, sehr oft kontrolliert. Ich habe nun das Problem, das uisp den Controller nur bei jedem fünten bis zehnten Versuch überhaupt erkennt, oft auch nur teilweise, d.h. "Vendor Code", "Part Family" und "Part Number" werden nur teilweise richtig oder überhaupt erkannt. Das sieht dann etwa so aus wie im Anhang. Nach der Fehlermeldung von uisp "Probably the AVR MCU is not in the RESET state." hatte ich natürlich die Reset-Schaltung in Verdacht, wobei ich nicht sicher bin, ob diese bei der ISP-Programmierung überhaupt eine Rolle spielt, weil der Controller während der Programmierung doch durch den Programmer im Reset gehalten wird. Nur zur Sicherheit: Ich verwende einen 10uF Elko und einen 10KOhm Widerstand. Habe auch schon einen 100KOhm Widerstand getestet oder beide Teile entfernt, das hatte keine sichtbaren Auswirkungen auf die "Erkennungsrate". Noch etwas habe ich durch puren Zufall herausgefunden und es grenzt schon ein wenig an Zauberei: Wenn ich die Stromversorgung mit dem Schalter einer Mehrfachsteckdose trenne, dann ist die Erkennungsrate ganz enorm hoch (etwa 8-9 von 10 Versuchen) in genau dem Moment, in dem die Schaltung also nur noch durch die Pufferkondensatoren versorgt wird. Kann sich da jemand einen Reim draufmachen und erkennt evtl. sogar anhand der Symptome ein ganz banales Problem? Ich fürchte, ich seh irgendwo den Wald vor Bäumen nicht. Ach ja, ich hatte erst einen 12MHz Quarz mit 2x33pF Kondensatoren als Taktgeber, um den als Fehlerquelle auszuschließen habe ich jetzt auf einen 4MHz Quarzoszillator an XTAL1 umgestellt. Wäre für Hilfe echt dankbar Mit freundlichen Grüßen Martin
Für mich hört sich das nach einer zu wenig stabilisierten und grenzwertigen Versorgungsspannung an. Hast du den AT89S52 und Atmega8 in dem gleichen Aufbau der Testschaltung ausprobiert? Kannst du zwischen GND und Vcc bzw. /RESET (alle Messpunkte direkt am µC) oszilloskopieren? Bild von der Testschaltung wäre angebracht.
@Stefan Ich habe leider kein Oszilloskop. :-( Habe aber jetzt ein paar Versuche mit dem Multimeter gemacht, siehe drei Absätze weiter unten. Das mit der Versorgungsspannung ist gut möglich. Ich verwende für die ganze Schaltung ein Steckbrett und die Spannungsstabilisierung ist die aus dem AVR-Tutorial, also mit 7805. Versorgt mit unstabilisiertem 9V Steckernetzteil von irgendeinem Gerät. schäm Ich gestehe hiermit auch gleich, dass der Programmierer ebenfalls auf einem Steckbrett aufgebaut ist und beide Bretter mit Drahtbrücken verbunden sind. Ich würde ja auch Kabellängen, übersprechen etc. in Betracht ziehen, wenn nicht die Atmega-Schaltung nach demselben Prinzip aufgebaut wäre, also Steckbrett, per Drahtbrücke verbunden, baugleiche Spannungsversorgung auf dem Steckbrett mit demselben Netzteil. Die beiden Controller stecken also nicht in der exakt gleichen Schaltung, aber einer baugleichen. Mal gucken, inwiefern ich da was testweise vertauschen kann, der S52 zumindest sitzt jetzt ganz schön fest im Board. :-} Ich messe zwischen VCC und GND des Controllers 4,94V, während eines Resets durch die ISP-Schaltung sind es 4,93V. Zwischen GND und Reset sind es im Normalfall 0V, während eines Resets (durch ISP) 4,76V ohne Resetbeschaltung, 4,72V mit 10uF Elko und 10KOhm Widerstand. Ich habe meinem armen kleinen Multimeter mit uisp -dprog=stk200 -d89 -v=3 -dt_reset=4000000 etwas Zeit zum Einpendeln verschafft. Laut Datenblatt (S. 29) wird alles über 0,7VCC am Reset-Eingang noch als High gewertet. Kann natürlich auch sein, dass die Spannung ständig zusammenbricht und mir das Multimeter nur einen Mittelwert ausgibt. :-/ Bin ich vielleicht mit dem Steckbrettansatz soiweso zum Scheitern verurteilt, weil der AT89S52 "anspruchsvoller" ist als der Atmega? VCC und GND liegen beim AT89S52 ja leider nicht so hübsch nebeneinander wie beim Atmega, ich bin nicht ganz sicher, wie ich da am Besten 100nF Abblockkondensatoren anbringen soll. Besser ein langes Kabel an VCC oder GND und nur ein Kondensator oder mit kurzen Drähten GND unten und VCC oben auf dem Brett anbringen und die Kondensatoren dann direkt in die Spannungsschienen stecken? Foto kann ich evtl. morgen nachreichen, wenn es nötig ist, aber es handelt sich wirklich um absolute Minimalbeschaltung mit Spannungsversorgung, Oszillator, EA auf VCC gelegt, der Resetschaltung, einer LED mit Vorwiderstand (mittlerweile auch wieder rausgenommen) und den Abblockkondensatoren. @Lars: Welches Kabel genau? Das Programmierkabel? Das ist wie oben beschrieben nur eine Ansammlung kurzer Drahtbrücken von jeweils ca. 10cm vom einen Steckbrett zum anderen, fast nur von den Pins des 74HCT244 zu denen des Controllers. @Beide: Vielen Dank schonmal, das ist wenigstens ein neuer Ansatz zur Fehlersuche. :-)
Hallo, ich meinte das Kabel was normalerweise zwischen dem Programmieradapter und dem Controllerboard hat. Das scheidet bei dir wohl aus. Gruß Lars
ad eins) AT89S52 ist kein AVR sondern ein Intel8052 Clon ad zwei) desahlb hat er auch einen high aktiven Reset um in den Progarammiermodus zu gelangen. Daraus ergibt sich die Frage: ist deine Programmiersoftware überhaupt in der Lage eine AT89S52 zu programmieren. Wenn sie einen nämlich nach einem AVR sucht und dazu Rset auf low zu ziehen trachtet wird sich der AT89S52 freilich nicht melden, weil low am Resetpin für den 8052 der Normalzustand ist. Wenn deine Software mit diesem Adapter einen 52er proggen kann(da habe ich Zweifel) wirst du Der Software zuvor mitteilen müssen das sie nach einen 52er auschauhalten muß.
1) Weiß ich doch. :-) 2) Ebenso. Und meine Messungen zeigen ja auch, dass der RST vom Programmer auf High gezogen wird. Trotzdem danke, das du mich dran erinnert hast. Habe mal versucht, Reset mit einem 10KOhm Widerstand fest auf High zu ziehen, hat aber auch nichts gebracht. uisp soll laut Homepage mit allen unterstützten ISP-Adaptern auch die 89Sxx unterstützen, man muss nur zusätzlich die -d89 Option verwenden, was ich ja auch mache. Siehe http://www.nongnu.org/uisp/ ganz unten. Besteht natürlich die Möglichkeit, dass die Dokumentation von uisp falsch ist und gerade dieser Adapter nicht für die 89Sxx-Programmierung geeignet ist, aber gerade die STK200-kompatiblen Adapter sind doch sicher so weit verbreitet, dass das schon jemandem aufgefallen wäre. Hoffe ich. Kennst du sonst vielleicht ein anderes Programm für diesen Adapter?
Ich habe das Phänomen der Erkennung bei abfallender Versorgungsspannung nochmal etwas weiterverfolgt und zwei (=>3,72V) bzw. drei (=>3,26V) Dioden vor VCC des Controllers geschaltet und mit beiden Aufbauten ist die Erkennungsrate bei 80-90%. Programmieren kann man ihn so natürlich nicht, es wird nur Müll in den Flash geschrieben. Ich fürchte, ich kann wohl davon ausgehen, dass ich beim Aufbau mal irgendein Beinchen falsch angeschlossen habe und der Controller einfach kaputt ist, oder?
Wie schnell taktest du den S52 beim Programmieren bzw. mit welcher Clock-Rate läuft dort die SPI-Schnittstelle? Du darfst glaub ich nur 1/16 (oder wars 1/40 ?) der Frequenz von XTAL1 als SPI-Geschwindigkeit haben, guck mal im Datenblatt nach... Ralf
Ich habe im Moment einen 4MHz Quarzoszillator dranhängen. Die SPI-Geschwindigkeit sollte laut Datenblatt 1/16 XTAL1 nicht überschreiten, also je 2 Mikrosekunden für SCK High und Low. Die Standardeinstellung von uisp ist 5 Mikrosekunden je Zustand, müsste also eigentlich klappen. Ich habe auch schon höhere Werte (auch Extremwerte wie 100us) ausprobiert, kein Unterschied. 12Mhz Quarz oder 16MHz Quarzoszillator bringen keine Verbesserung, eher das Gegenteil, weswegen ich immer mehr davon überzeugt bin, dass ich den Controller zerschossen habe. :-/ Vielen Dank an euch alle und wer noch Ideen hat, immer her damit. :-) Martin
Vielleicht hilft es weiter den Programmer und die Testschaltung getrennt mit Spannung zu versorgen, so wie es Kai Klaas hier testweise vorschlägt: http://www.8052.com/forum/printable.phtml?id=103574&thread=103301 Zum Thema korrumpierten Flash hat Kai Klaas ebenfalls was Bemerkenswertes geschrieben: http://www.8052.com/forum/read.phtml?id=108737
Ich fürchte, ich habe mich falsch ausgedrückt, ich habe es nur geschafft, zu "programmieren", indem ich uisp mit -dno-poll angewiesen habe, die Fehler beim Programmiervorgang zu ignorieren. Ich glaube gar nicht, dass überhaupt irgendetwas geschrieben wurde. Aber danke für den Tipp, dass der Flash durch falsche oder fehlende Reset-Beschaltung korrumpiert werden kann, dann werde ich die jetzt mal dranlassen, wieder eine Fehlerquelle weniger. Meintest du, dass ich die komplette vorgeschlagene Treiberschaltung aufbauen soll oder nur eine extra Versorgungsspannung für den Programmer (GND natürlich verbunden)? Leider fehlen mir für die genanne Schaltung gerade die meisten Teile. So auf Anhieb verstehe ich diese Schaltung nicht, der Link zum Dokument von Atmel funktioniert mittlerweile leider auch nicht mehr, so dass ich nicht nachgucken kann, wofür die ganzen zusätzlichen Anschlüsse gedacht sind und womit man dann programmieren soll. Den 74HCT244 habe ich ja bereits, um die evtl. 3,3V Level des Parallelports auf 5V umzusetzen. Dient der zweite Treiber dann nur noch dazu, beide Schaltungen spannungsmäßig komplett zu isolieren? Und nur mal aus Neugier, was ist eigentlich der Grund dafür, dass man die Versorgungsspannungen beim S52 trennen sollte? Sorry, ich will das alles natürlich nicht vorgekaut bekommen, bräuchte nur mal einen Ansatzpunkt und der Link (http://www.atmel.com/dyn/resources/prod_documents/isp_C_v5.PDF) funktioniert wie gesagt nicht. Werde jetzt erstmal schauen, dass ich eine zweite Versorgungsspannung zustande kriege, notfalls klau ich die irgendwo vom PC. :-) dankbaren Gruß Martin
Das selbe Problem hatte ich vor kurzem auch (allerdings mit avrdude) mit meinem ATMega32L. Ersten eigenen Programmer gebastelt (mit den 3,3V aus dem Parallelport versorgt), drangesteckt, ging nur so halb, Device ID meistens nach ein paar bits abgeschnitten. Nach ner Woche der Verzweiflung hab ich's dann einfach mal unter Windows versucht und das lief auf Anhieb. Scheint irgend ein Bug im Paralellporttreiber gewesen zu sein. :/ Allerdings sagt das Datenblatt, dass der AT89C52 5V braucht, aber vielleicht klappts ja.
Okay, habe zwar noch keine getrennte Versorgungsspannung, aber dafür bin ich etwas weitergekommen. Hab mich durch die Threads bei 8052.com gelesen und es scheint so, dass die 8052-Derivate extrem empfindlich auf unsaubere Taktflanken reagieren (deshalb wohl der zweite Treiber direkt am Controller) und außerdem Probleme mit kapazitiven Lasten (lange Kabel) haben. Dort wurde auch noch eine weiterer Ansatz genannt, nämlich 100-150Ohm Serienwiderstände an MISO, MOSI und SCK auf der Controllerseite. Ob die als Abschlusswiderstände dienen sollen? Hab leider keine solchen Widerstände hier, aber ein erster Test mit 2*220Ohm und 1*470Ohm zeigte zumindest eine Verbesserung, die Erkennungsrate ist vergleichsweise okay und beim Auslesen des Flash sehe ich jetzt auch viel öfter als vorher die erwarteten FFs. Ich seh schon, da wird wohl eine Bestellung bei Reichelt und ein ganz, ganz sauberer Aufbau nötig sein, bevor diese Diva von Controller und ich uns anfreunden. ;-) @Björn: Ich probier's gleich mal.
ISP_C_V5.PDF (Plan vom AT89-ISP von Atmel) findet man auch anderswo: http://www.atmel.ru/Software/files/isp_c_v5.pdf Nützliche Infos zur Reset-Beschaltung finden sich auch in dem Brownout-Dokument zur C51 Serie und im dokument zur Berechnung von Crst http://www.atmel.com/dyn/products/product_card.asp?part_id=1918 Aus den Antworten im zitierten Thread schliesse ich, dass mit dem 2. 74... ausgeschlossen werden soll, dass bei Target-Vcc = OFF die Targetschaltung über die Parallelschnittstelle und Schutzdioden am 1. 74... eine parasitäre Spannung bekommt und sich den Speicher korrumpiert. Stelle vielleicht mal einen Plan rein, wie deine Testschaltung aussieht.
Na da bin ich ja froh, dass du mir die Arbeit abnimmst grins Ich bin nämlich dabei so eine Luxus-Datenschaufel (mit nem 128er atmega Inside) für die 52er derivate zu bauen und muß mich eventuel noch öfter damit auseinandersetzen. Bitte schreibe weiter wie du vorrankommst. Nächste Woche stehe ich dann vor dem gleichen Problem und muss dann hoffentlich nicht bei Null anfangen.
Hier in diesem Forum haben die 51er/52er Spezeln ihren Stammtisch, da bin ich der AVR-Exot, aber das Klima istr prima. ;-) http://www.progforum.com/index.php?
Angehängte Dateien:
-
s52board.png
5,2 KB
@Stefan: Danke, werde mir das alles mal durchlesen und schauen, ob mir noch ein Fehler auffällt. Zumindest die Berechnung des Resetwiderstands meine ich auch schonmal durchgelesen zu haben und es war alles in Ordnung. Sobald ich etwas Zeit und die Teile habe, werde ich dann mal versuchen, einen zweiten 74er so nah wie möglich an den Controller zu bringen, die Drähte so kurz wie möglich zu halten usw. Im Anhang ist jetzt auch endlich meine Testschaltung. @Winfried: Danke für den Tipp mit dem Progforum, jetzt habe ich schon drei Foren, um nach Antworten zu suchen. :-) Werde meine Fortschritte weiter hier reinstellen, fürchte aber, ich werde diesem Hobby... äääh, persönlichen Fortbildungsprojekt schon bald nicht mehr so viel Zeit widmen können, wie ich gerne würde.... Aber aufgegeben wird nicht! :-)
100K an 10µ das gibt nen tau von ewig(0,7s) klar das die isp solange nicht wartet nimm maximal 1µ besser 100nF und maximal 10K sonst ist die ISP schon im timout bevor sich der 52er in den Progmodus begibt
> 2) Ebenso. Und meine Messungen zeigen ja auch, dass der RST vom
Programmer auf High gezogen wird.
nur leider zu spät vermute ich mal
Ups, da hätte ich wohl doch mal nachrechnen sollen. Hab das aus irgendeiner Schaltung hier im Forum und hatte dann nur kurz mit der Appnote zur Berechnung des Kondensators verglichen, ob es halbwegs passt. Tut es ja auch, aber fast 200ms ist natürlich ein bisschen extrem. Aber hat das wirklich Auswirkungen auf die ISP-Programmierung? Ich hatte das bisher immer so verstanden, dass Reset während der gesamten Programmierung auf High gezogen wird und erst nach abgeschlossener Programmierung wieder auf Low. Wo kann denn da ein Timeout kommen? Hab jetzt auch den 10K und einen 100nF Kerko angebracht, leider keine Verbesserung. Auch mit 100nF und nur 1K nichts. Hab mal spaßeshalber Reset über 1KOhm direkt mit VCC verbunden, auch kein Erfolg. Am meisten haben bisher die Serienwiderstände für SCK, MOSI und MISO gebracht, wobei ich ja die empfohlenen Werte von je 100-150Ohm leider nicht ausprobieren kann. Deshalb würde ich den Fehler eher in diesen Leitungen vermuten. Wie gesagt, mir ist noch nicht klar, wie die Reset-Beschaltung überhaupt Einfluss auf den durch ISP ausgelösten Reset haben kann. Ich meine sogar, einen Programmer gesehen zu haben, der ganz ohne Kondensator und Widerstand auskam und den Reset-Pin einfach nur mit dem Reset-Ausgang der ISP verbunden hat. Kann ihn aber nicht mehr finden. :-/
Der Kondernsator hat den Zweck Spikes auf der der Reset Leitung abzufangen. Jedoch kann er auch den Reset so verzögern, das die Software nicht solange auf eine Reaktion des 52ers warten mag und bereits den Progmodus angeht bevor der 52er soweit ist, dann kommt natürlich auf Miso nichts zurück, vielleicht solltest du ihn erstmal ganz rausnehmen. Interessieren würe mich auch auf jeden fall was auf Deiner 5V Leitung los ist, die Sache mit der Steckdosenabschaltung lässt ahnen das da irgend was drauf rumtobt. Am ende hast du da ne Brummschleife im Ground kannste das Bord nicht mal aus ner Batterie (9vBlock oder 4*AAA) speisen? So schließe ich sowas für gewöhnlich aus. Mfg Winne
Es funktioniert! :-) :-) :-) Ihr hattet Recht, den Controller mit Batterien zu versorgen hat's gebracht. Hätte ich das mit der getrennten Spannung nur früher ausprobiert. Wenn ich Controller und Programmer per Batterie versorge, funktioniert alles. Wenn ich den Controller per Batterie versorge und den Programmer mit Netzteil und der 7805-Schaltung, geht nix. Also ist wohl doch diese Schaltung bz.w das Netzeil verantwortlich. Werde die nochmal gründlich austesten müssen. Was Interessantes passiert, wenn ich nur den Controller per Batterie versorge und den Programmer gar nicht (GND der beiden natürlich verbunden). Dann funktioniert es nämlich auch. Der rumil.de-Adapter hat einen Pullup an MISO, ich vermute, die Spannung aus dem Parallelport reicht aus, um über den Pullup auch den 74HCT244 zu betreiben. Hat mich ganz schön verwirrt. Naja, jedenfalls habe ich jetzt eine kleine, blinkende LED auf dem Schreibtisch und freu mich wie ein Schneekönig. Morgen werde ich dann mal austesten, inwiefern die Serienwiderstände und die Resetbeschaltung einen Einfluss haben. Jetzt brauch ich erstmal dringend Schlaf. %-) Ein riesengroßes Dankeschön an alle, die Ideen und Ratschläge beigesteuert haben. @Stefan: Du hattest von Anfang an Recht. :-) @Winfried: Danke für die Diskussion der Reset-Beschaltung und die Idee mit den Batterien. @Alle: Auch wenn nicht alles direkt zur Lösung beigetragen hat, so habe ich doch auch durch die "Irrwege" schon eine Menge über diesen Controller gelernt, was ja das Ziel der ganzen Sache war. Gute Nacht Martin
Glückwunsch ! Ich habe auch davon gelernt, das ich mich beruhigt an mein Projekt begeben kann und der 52er sensibel ist wass seine Spannungsverorgung angeht. und galvanische Trennung hat noch immer Brummschleifen aufgelöst ;-)))
So, noch ein paar Nachträge: Der 10uF Elko war für die Resetbeschaltung absolut ungeeignet, damit springt der Controller tatsächlich NIE an. 100nF mit 10KOhm geht super. Bei Netzteilbetrieb mit den Serienwiderständen vor MISO, MOSI und SCK wird der Flash-Speicher augenblicklich korrumpiert, sogar beim simplen Auslesen. Nehme an, es liegt am unsauberen Reset-Signal, hab leider keinen Widerstand in dieser Größenordnung mehr, den ich noch an Reset hängen könnte, vielleicht teste ich das dann später nochmal. Pass also gut auf deine Resetbeschaltung auf, nicht dass da auf einmal ein prellender Resettaster den Speicher überschreibt. ;-) Für den Batteriebetrieb machen die Widerstände keinen Unterschied mehr und können weggelassen werden. Ich bin nicht sicher, woher die Brummschleife kommen könnte, das Netzteil hängt zwar letztlich an der selben Steckdose wie der PC, hat aber gar keinen Schutzkontakt, ist nur ein Euro-Stecker. Aber die Hausinstallation hier ist auch nicht ganz sauber, "Nullung der schlechten Art" oder sowas hat der freundliche Elektriker gesagt, als die Spülmaschine letztens mal Schläge verpasst hat. ;-)
Schaltnetzteil? Habe auf meinem, von nem toten Palm, gehörig Ribble gefunden. Der Oszi läuft bei mir immer wenn ich Impulse sehen will mit. Das macht das Leben leichter ;-) wenn z.B. die Uart mal wieder nicht so will wie ich. Ich denke der Hauptfehler liegt jetzt in deiner Stromversorgung und der Verbindung zum PC. Versuch mal die 5V aus nem USB Kabel zu nehmen, dann solltest du Ruhe haben. Oder zieh die Sache mit Optokopllern durch.
Ja, so ein Oszilloskop wäre was Feines. ;-) Ist irgendein Klotz, ich denke ursprünglich mal für ein ISDN- oder DSL-Gerät gedacht. Siemens RZ 6414, hab aber nichts drüber gefunden. Werde die Woche mal was zusammenlöten, um den Strom von USB zu nehmen. Wollte mir eh irgendwann einen dieser schicken USB-Programmer nachbauen, schon alleine um den Kabelsalat in Grenzen zu halten. Solange tut es die Akkulösung aber allemal. :-) Martin
@ Winfried Jaeckel > Ich denke der Hauptfehler liegt jetzt in deiner Stromversorgung und der > Verbindung zum PC. Versuch mal die 5V aus nem USB Kabel zu nehmen, dann > solltest du Ruhe haben. Genau. Ne Solide Stromversogung ist lebensnotwendig. > Oder zieh die Sache mit Optokopllern durch. AUA! Wer wird denn gleich mit Kanonen auf Spatzen schiessen. Anstatt Geiz ist Geil Schrottnetzteile zu verwenden sollte man mal lieber 10 Euro in ein GESCHEITES Steckernetzteil investieren. Spart tonnenweise Zeit und Nerven. Naja, lernen durch Schmerz. MfG Falk
Leider besitze ich immer noch kein besseres Netzteil und bin jetzt auch etwas unsicher, ob ich mir nicht noch mehr Schrott zulege. Geht alles, was Reichelt so als "Tisch-Netzgerät, stabilisiert" anbietet, so wie das hier? http://www.reichelt.de/?ARTICLE=13291 Hab mittlerweile den USB angezapft und es zeigt sich leider keine Besserung. Ich habe alle möglichen Kombinationen ausprobiert aus - Controllerschaltung versorgt Programmer bzw. Controllerschaltung und Programmer haben verschiedene Versorgungen (Masse zusammengeschaltet) - als Stromversorgung Akkus, Netzteil, USB aber Programmieren geht nur dann, wenn der Controller per Batterie versorgt wird, der Rest macht keinen Unterschied. Als reine Betriebsspannung für den bereits programmierten Controller geht allerdings alles. Augenscheinlich jedenfalls, ich habe leider noch kein komplizierteres Programm als diesen LED-Blinker geschrieben. Ich habe nach all dem Ärger auch mein PC-Netzteil in Verdacht, obwohl das ein nicht so ganz billiges Enermax ist.
@Martin Gernhard > http://www.reichelt.de/?ARTICLE=13291 Schwer zu sagen. Die Aussage "geringe Brummspannng" beunrigigt mich ein wenig. Ein geregeltes Netzteil hat quasi keine Brummspannung. > Hab mittlerweile den USB angezapft und es zeigt sich leider keine > Besserung. Ich habe alle möglichen Kombinationen ausprobiert aus - Controllerschaltung versorgt Programmer bzw. Controllerschaltung und Programmer haben verschiedene Versorgungen (Masse zusammengeschaltet) - als Stromversorgung Akkus, Netzteil, USB > Ich habe nach all dem Ärger auch mein PC-Netzteil in Verdacht, obwohl > das ein nicht so ganz billiges Enermax ist. Glaub ich kaum. Aber wenn ich sowas lese > ganze Schaltung ein Steckbrett und die Spannungsstabilisierung ist die > aus dem AVR-Tutorial, also mit 7805. Versorgt mit unstabilisiertem 9V > Ich gestehe hiermit auch gleich, dass der Programmierer ebenfalls auf > einem Steckbrett aufgebaut ist und beide Bretter mit Drahtbrücken > verbunden sind. Ich würde ja auch Kabellängen, übersprechen etc. in Das schreit nach Wacklelkontakten und schlechten Übergangswiderständen plus andere Murphy-Fallen. > vertauschen kann, der S52 zumindest sitzt jetzt ganz schön fest im > Board. :-} Mechanisch fest heisst nicht unbedingt elektrisch gute Verbindung. > Bin ich vielleicht mit dem Steckbrettansatz soiweso zum Scheitern > verurteilt, weil der AT89S52 "anspruchsvoller" ist als der Atmega? Mein Vorschlag, bau dir die Minimalschaltung mit DIL40 Sockel, Quarz, 7805 etc. auf Lochraster mit ordentlichen Lötverbindungen auf. Das geht schnell un kostet nicht die Welt. Steck den Controller dann dort rein und schau. MFG Falk
@Falk: >Mein Vorschlag, bau dir die Minimalschaltung mit DIL40 Sockel, Quarz, >7805 etc. auf Lochraster mit ordentlichen Lötverbindungen auf. Das geht >schnell un kostet nicht die Welt. Steck den Controller dann dort rein >und schau. Das klingt nach einer sehr vernünftigen Idee. Hab's langsam auch satt mit den vielen möglichen Fehlerquellen. Das werde ich machen. Und nach einem besseren Netzteil suchen. :-) Mit freundlichen Grüßen Martin
Ich bin's nochmal. :-) Das wird jetzt mein hoffentlich letzter Eintrag zu diesem Thema sein. Ich habe die Bestellung noch etwas verschoben, da sich das sonst mit den Versandkosten nicht rechnet, aber ich habe auch so eine Loesung fuer einen stabilen Betrieb gefunden: Ich habe einen Atmega8 benutzt, um (vorerst auf einem Steckbrett, mir sind die Lochrasterplatinen ausgegangen) einen AVR910-Programmer aufzubauen. Ich habe dann Klaus Leidingers Firmware und uisp soweit angepasst, dass Identifikation, Upload und Download (und somit auch Verify) funktionieren. Jetzt geht es sogar mit dem Billignetzteil. Das ganze ist nicht unbedingt schnell (habe keinen Blockmodus implementiert) und die Lockbits lassen sich auch weder lesen noch schreiben, aber es funktioniert. Ich schreibe das hier rein, fuer den Fall, dass mal jemand im Archiv auf diesen Thread stoesst und eine Loesung sucht, die nicht mit Parallelportadaptern oder nur unter Windows funktioniert. Klaus will die angepasste Version demnaechst auch von seiner Seite aus verlinken bzw. dort zur Verfuegung stellen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.