Hallo Nachbar,
tolles Rezept, super erklärt und beschrieben.
Werde ich gleich nachbacken - natürlich nur, wenn du es erlaubst.
Gute Zeit und schönen Tag!
Edit am 15. Jan. 2010. Die einfachste Lösung die mir eingefallen ist, mit einem Widerstand und einer Standard-RS232 (z.B. am PC), steht weiter unten, hier (einfach klicken).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Einen Controller beim Einstellen der Fuses auf externen Takt umzustellen ist ein vielgeübter Vorgang in der Anfängerzeit. Und nun? Woher den externen Takt bekommen, der erforderlich ist, um den Controller wieder das richtige Laufen beizubringen? Diese Übung kenne ich aus eigener, leidvoller Erfahrung.
Mögliche Taktquellen sind: eine andere Platine, bei der vom Controller ein entsprechender Takt bereitgestellt werden kann – notfalls durch ein kleines, schnell geschriebenes und geflashtes Programm. Ein Oszilloskop mit einem Kalibrator. Ein USB-Programmer, den man als Taktgeber benutzen kann; aber mit welchem Programmer setzt man dann die Fuses um? Es gibt also viele Möglichkeiten, meist aber eher solche, die gerade dem Anfänger eher unzugänglich sind.
Die Aufgabe lautet also: Baue einen Taktgeber mit einfachsten Mitteln, die den meisten Anfängern verfügbar sind. Der muss einen Takt erzeugen, mit dem ein Controller, der auf externen Takt umgestellt ist, versorgt werden kann.
Die Lösung ist einfach. Lösungskonzept ist die Ausgabe einer langen Reihe von ASCII-U über die RS232-Schnittstelle. Den Spannungspegel der RS232 ist dazu auf ein controllergerechtes Niveau zu bringen. (Nicht zum Lesen gedacht: Wie alle einfachen Lösungen habe ich ne Weile gesucht. Wie geht man das an? Man schreibt alle Möglichkeiten auf, mit denen man einen >>gleichmäßigen<< Takt erzeugen kann. Dann werden die Möglichkeiten ausgesondert, die eher nicht anfängergerecht sind. Danach testen, freuen und Bericht schreiben. Den Bericht am Besten noch mal von einem Fachmann zur Kontrolle durchlesen lassen - Danke Hubert.G - danke auch für die Kontroll-Tests.)
Hintergrund: ASCII-U ist, als 7-Bit-ASCII die Bitfolge 1010101, als 8-Bit-ASCII entsteht daraus 0101 0101. Dies ist eine gleichmäßige, schnelle Folge von Nullen und Einsen. Wenn dies über die serielle Schnittstelle gesendet wird, so erhält man unter Vernachlässigung der Start- und Stopbits einen regelmäßigen Takt. Dies wird hier benutzt. Statt eines U kann natürlich noch ein anderes ASCII-Zeichen verwendet werden - das U hat den Vorteil, dass es im 7-bit-ASCII mit einer "1" beginnt.
Das Rezept
Man benötigt:
o) Einen Controller, eingestellt auf EXTCLK – externe Taktquelle
o) Eine RS232, dazu ein geeignetes Kabel mit den Ausgängen TX und GND
o) Zwei Widerstände, jeweils etwa 1 MΩ (bis 100 kΩ).
Ersatzweise ein Poti entsprechender Größe und Einstellung als Spannungsteiler
o) Eine LED (LED_CON) mit Vorwiderstand 1kΩ
o) Evtl. eine zweite LED (LED_CLK) mit Vorwiderstand 1kΩ
o) Steckbrett oder für einen festen Aufbau eine Lochrasterplatine
o) Eine Datei mit lauter „U“. Erstellt z.B. mit Notepad ohne Zeilenumbruch,
mit 200 Zeilen zu je 1024 Zeichen – alles grosse „U“ – ohne Zwischenräume etc.
>>> Und ohne jeglichen Zeilenvorschub – Absatz und ähnliches.
o) Ein Terminalprogramm, z.B. HyperTerminal
Mit diesen Zutaten wird dieser Kuchen gebacken - ähhh -wird diese Schaltung aufgebaut :
................Bild hier
................Schaltungsbeispiel mit einem ATtiny85
................andere Controller sinngemäß
Aus Gründen der besseren Übersichtlichkeit wurde hier sowohl die Versorgung des Controllers als auch die Verschaltung mit dem Programmer weggelassen. Anmerkung: es gibt nur eine Leitung zwischen Fuseretter und Controller, GND ist nicht gesondert verbunden.
Der Spannungsteiler wird aufgebaut wie dargestellt. Er hat im Wesentlichen die Funktion sowohl den Controller als auch den PC – bzw. dessen Schnittstellen-Schaltkreis zu schützen.
................Bild hier
................Der Fuseretter.
................Rechts ist der zweipolige Anschluss eingeblendet, rechts oben ist die Leitung zum Controller.
Arbeitsweise
Die serielle Schnittstelle des Rechners wird an den Stecker der Schaltung gelegt. Der Controller wird mit dem Fuseretter nach Schaltbild verbunden und mit Spannung versorgt. Die vorbereitete Datei mit den vielen „U“ wird gesendet, Einstellung 8n1 – also 8 DataBit, no parity und 1 Stopbit, alles mit z.B. 28,8 kBaud – so hat es bei mir funktioniert. Die Schnittstelle sendet bei der oben genannten Einstellung über ca. 30 sek ein Rechtecksignal. Diese Zeit wird genutzt, um den Controller zurückzustellen. Dabei soll der Programmer auf möglichst langsamen Takt eingestellt werden. Wer ein Oszilloskop besitzt, kann sich das saubere Rechtecksignal ansehen. Evtl. muss die Datenübertragung mehrmals gestartet werden. Ein langsamerer Takt beim Senden der Datei als 28k8 ist nicht zu empfehlen. Bei 19k6 gab es bei mir bereits gelegentlich Probleme. Einen Test an einem USB-RS232-Adapter habe ich nicht durchgeführt.
Wenn TX korrekt angeschlossen ist, leuchtet die LED_CON. Dies ist nicht bei der Leitung RX der Fall – damit ist die Sendeleitung eindeutig identifizierbar. Beim Senden von Daten über die Schnittstelle leuchtet die LED_CLK entsprechend dem Signalpegel – das ist wegen der schnellen Datenfolge mit dem Auge nicht sichtbar; allenfalls leuchtet die LED_CLK etwas weniger hell.
Minimalisten können beide LEDs mit ihren Vorwiderständen weglassen – dann hat man mit zwei Widerständen und wenig Draht einen Fuseretter. Dann hat man aber keine Anzeige für die korrekte Leitung TX und auch nicht für die laufende oder nicht mehr laufende Datenübertragung. Ich sehe es sehr vorteilhaft an, dass beim Anstehen des Taktes (besser gesagt: beim Senden von „irgendetwas“) die LED_CLK leuchtet. Sehenswert ist die äußerst sparsame Schaltung.
................Bild hier
Eine kommerzielle Anwendung ist ausgeschlossen – dafür fordere ich eine gesonderte Zusage von mir. Nachbau und Anwendung dieses Fuseretters für den Hobbybereich ist frei, sie unterliegt der eigenen Verantwortung des jeweiligen Anwenders. Für die Anwendung und den Einsatz des Fuseretters übernehme ich keinerlei Garantie für die hier beschriebene Funktion. Für eventuelle Schäden an Rechnern, Hardware etc., die eventuell bei der Anwendung des Fuseretters entstehen, kann ich ebenfalls keinerlei Garantie übernehmen. Wer seinen Editor nicht überstrapazieren will, kann sich 200 000 "U"s (ASCII) hier holen (dann speichern z.B. als irgendwas.txt).
Geändert von oberallgeier (05.11.2016 um 16:47 Uhr) Grund: Bildserver angepasst
Ciao sagt der JoeamBerg
Hallo Nachbar,
tolles Rezept, super erklärt und beschrieben.
Werde ich gleich nachbacken - natürlich nur, wenn du es erlaubst.
Gute Zeit und schönen Tag!
Danke Nachbar. Es geht weiter.
Positiv verliefen Tests mit einem betagten UsB-Serial-Adapter unbekannter Herkunft. Der Adapter war beim Test am gleichen Rechner wie der Flash-Programmer angeschlossen und alternativ an einem davon getrennten Notebook - das auf Akku lief. Damit fehlte der gemeinsame (Netz-)Ground der Rechner (siehe unten). Die sichere Funktion des UsB-Serial-Adapters ist verständlich - es werden ja nur Textzeichen übertragen.
Senden der Textdatei erfolgt, wie im ersten Beitrag erwähnt, über ein Terminalprogramm. Zuerst wird die Schnittstelle passend parameterisiert: 28k8 mindestens, Einstellung 8n1 – 8 DataBit, no parity und 1 Stopbit. Bei HyperTerminal wird danach in der Befehlsleiste das Menu Übertragung geöffnet und der Befehl [Datei senden] ausgewählt. Der zu sendende File wird angewählt und die Übertragung gestartet. Unmittelbar nach Start der Übertragung (ist an der LED_CLK zu erkennen) sollte in das Flashprogramm geschaltet werden um die Fuses wie gewünscht zu ändern.
Ein Problem. Wenn zum Flashen ein anderer Rechner benutzt wird als zum Takten, können Probleme mit der fehlenden GND-Verbindung eintreten. Dann sollte doch eine separate GND-Verbindung gelegt werden. Danke Hubert.G für den Hinweis und den Test mit dieser Konfiguration. Dieser Test mit zwei getrennten Rechnern wurde von mir nachgefahren mit dem gleichen Ergebnis: auch bei mir war eine zusätzliche GND-Verbindung erforderlich - obwohl die LED_CLK lustig leuchtete.
................Bild hier
Auch in diesem Schaltbild ist wieder der Übersichtlichkeit wegen die Versorgung des Controllers nicht eingetragen.
Viel Erfolg und bitte um Rückmeldungen, insbesondere bei Problemen.
Geändert von oberallgeier (05.11.2016 um 16:51 Uhr) Grund: Bildserver aktualisiert
Ciao sagt der JoeamBerg
Sowas hab ich noch nicht gesehen. Tolle Idee!!!
Gut, daß ich noch nicht mit müCs angefangen hab. Dies wird sicher eines der Dinge die ich ausprobieren werden muß.
Gruß
Searcher
Hoffentlich liegt das Ziel auch am Weg
..................................................................Der Weg zu einigen meiner Konstruktionen
Hallo alle,
nun weiß ich nicht, ob sich die Minimalisten an der Nase rumgeführt fühlen. Der kleine Fuseretter geht nämlich NOCH einfacher als bisher vorgestellt. Erwähnt wurde ja schon die Sachlage, dass der GND spätestens dann am Controller anliegt, wenn das Flashwerkzeug - der Programmer - am gleichen Rechner angeschlossen ist, von dem der RS-232Takt kommt. Damit ist der Minimal-Fuseretter mit nur einem Widerstand möglich. Einfach den nackten Widerstand in die RS232-Buchse des PCs oder Verlängerungskabels auf TX stecken und das andere Ende an XTAL1 oder wie immer der externe Taktanschluss des Controllers heißt.
Getestet und gute Funktion bestätigt.
Ich hätte gern ein Foto beigestellt - aber wen interessiert schon ein Controller in einer Fassung mit einem dazugesteckten Widerstand.
................Bild hier
................In der Schaltung ist diesmal ein tiny2313 - damit es nicht allzu dünn aussieht.
Nochmal deutlich der Hinweis von oben: Zusätzlich zum Widerstand muss GND zum Controller geleitet werden. Das geschieht z.B. durch die GND-Leitung eines Flashwerkzeugs (sprich: Programmer).
Geändert von oberallgeier (05.11.2016 um 16:54 Uhr) Grund: Neuer Bildserver
Ciao sagt der JoeamBerg
Hallo oberallgeier,
also ich würde mir doch schon ein Foto wünschen. Aber laß bitte den tiny2313 weg. Dann kann ich mir die Schaltung besser für einen ATmega vorstellen .
Ansonsten: Klasse Idee.
Dir kann man eben kein X für ein U vormachen.
Gruß Sternthaler
Lieber Asuro programieren als arbeiten gehen.
Aber gerne.Zitat von Sternthaler
Der oben zitierte File wird mit 57600 Baud auf die RS232 ausgegeben mit Widerstand 82k. Target ist XTAL1 auf einem m32 (RNControl) ohne Quarz. Während der Übertragung konnte die Signatur korrekt ausgelesen werden : 0x1E 0x95 0x02 mit ISP-Frequenz 4 kHz.
................Bild hier
................Bild mit 5V/Div, 0,1 ms/Div.
................Tastkopf auf Controller-GND und XTAL1.
Geändert von oberallgeier (05.11.2016 um 16:56 Uhr) Grund: Neuer Bildserver
Ciao sagt der JoeamBerg
Hey Geier, ich glaube, er meinte spaßeshalber nicht das Oszi, sondern den Versuchsaufbau
Hallo thewulf00,
welchen Versuchsaufbau meinst du?
Ich dachte, dass oberallgeier hier nicht mehr versucht, sondern geschafft hat.
Oh man, was für ein OT in diesem schönen Thread .
T'schuldigung
Immerhin sieht man am Oska schön, dass bei den 3 Takten pro 1/10 ms eine Frequenz von 30000 kHz entsteht.
Also bei den 4 gesetzten Bits im U plus Start- und Stopbit, also 6 Bits pro gesendeten U, hätten wir somit einmal U alle 2/10 ms.
Rechne, rechne, ...: 1 / ( (2/10) / 1000) = 5000 Byte pro Sekunde.
Und siehe da: Das sind ja ungefähr die von oberallgeier angegeben 57600 Baud.
Womit das Bild doch wieder sehr, sehr wichtig wurde.
Gruß Sternthaler
Lieber Asuro programieren als arbeiten gehen.
Hallo!
Mir ist eine (blöde ?) Idee eingefallen, die ich leider als PIC-Benutzer nicht ausprobieren kann, da ich gar kein AVR habe...
Was passiert, wenn man beim Programmieren den Clock vom Programmer gleichzeitig an externen Clock des AVR anschliesst ?
MfG
Lesezeichen