In älteren elektronischen Geräten, die aus dem Gebrauch gezogen wurden, findet man interessante Bauteile, darunter verschiedene Arten von Mikrocontrollern.
Obwohl heutzutage 32-Bit-Mikrocontroller mit hoher Rechenleistung und Netzwerkschnittstellen für kleines Geld leicht erhältlich sind, reicht manchmal ein älterer 8-Bit-Chip, beispielsweise aus einem zur Entsorgung vorgesehenen Gerät, aus, um das Projekt umzusetzen.
Besonders interessant sind die 89S5x-Chips von Atmel. Dies sind Schaltungen der 8051-Familie, ausgestattet mit einer ISP-Schnittstelle (der Buchstabe S in der Bezeichnung), was heute nichts Ungewöhnliches und sogar eine Norm ist, wobei jedoch zu bedenken ist, dass andere Schaltungen dieser Familie nur parallel einprogrammiert werden konnten (z. B. AT89C51, ganz zu schweigen von Versionen ohne Flash-Speicher).
Ich fing an, eine DCF77-Uhr mit programmierbarer Steuerungsfunktion zu entwerfen, und suchte nach einem geeigneten Prozessor.
Da ich mehrere 89S52-Schaltungen aus der Demontage in meiner Sammlung habe, habe ich mich entschieden, diese für diesen Zweck zu verwenden. Damit der Entwicklungsprozess nach aktuellen Standards abläuft, wollte ich natürlich ISP für die Programmierung nutzen. Es stellte sich jedoch heraus, dass alle AVR-Programmierer, die ich habe, nicht in der Lage sind, seriell mit dem 89S52 zu kommunizieren.
Eine kurze Websuche führte mich zum USBasp-Projekt: https://www.fischl.de/usbasp. Innerhalb weniger Stunden entstand ein Prototyp mit ATmega8, montiert auf einer universellen Platine. Der Start verlief problemlos, das Programm avrdude erkannte den Programmierer.
Leider bekam ich beim Versuch, den Inhalt von 89S52 abzulesen, folgende Meldung:
Code: bash
Melde dich an, um den Code zu sehen
Irgendetwas stimmte nicht mit der Kommunikation auf der Leitung USBasp - AT89S52.
Debugging mit einem Oszilloskop und Suchen im Internet brachten die Antwort. Das Problem war, dass USBasp eine fest codierte Prozedur zum Setzen des RESET-Pins auf der ISP-Schnittstelle hatte. Die AVR-Chips haben einen negierten RESET-Eingang, während die 89S5x-Chips einen nicht negierten Eingang haben. Mit anderen Worten, der RESET-Aktivzustand für AVR ist niedrig, für 89S5x ist er hoch.
Der Autor von USBasp hat auf seiner Website Quellen hinterlegt, wo man den Grund für diesen Sachverhalt finden kann:
Code: c
Melde dich an, um den Code zu sehen
In der obigen Funktion, sowie an einigen anderen Stellen ist es klar, dass der aktive Zustand der RESET-Leitung low ist, was dem AVR-Standard entspricht.
In dieser Situation hat der Programmierer keine Möglichkeit, den aktiven Zustand auf low zu ändern, selbst wenn die USB-Steuerbefehle Informationen darüber enthalten würden, welchen Standard der USBasp bei der Kommunikation mit dem programmierten Chip verwenden sollte.
Also habe ich beschlossen, einen Hardware-"Griff" in Form eines Goldpins und eines Jumpers hinzuzufügen, mit dem ich bestimmen kann, welchen aktiven Zustand der Programmierer während der Programmierung verwenden soll.
Ich habe den Jumper an Pin 26 angeschlossen, den das Programmiergerät während der Programmierung ausliest. Unten sieht man einen schaltplan aus dem Internet mit meinem Jumper hinzugefügt.
Im Programm habe ich alle Stellen, die den RESET-Pin setzen, durch Aufrufe der setReset(uchar)-Funktion ersetzt, die die RESET-Leitung an der ISP-Schnittstelle je nach Position des Griffes entsprechend setzt.
Code: c
Melde dich an, um den Code zu sehen
Nach dieser Änderung kann der Programmierer sowohl den AVR als auch den AT89S52 programmieren.
Code: bash
Melde dich an, um den Code zu sehen
Diejenigen, die die vollständigen Quellen mit der Änderung sehen möchten, füge ich im Archiv, das ist die FW-Version von usbasp von 2011.
Cool? DIY-Rangliste
