@ogni42 – danke für Deinen Zuspruch – ja, er fährt tatsächlich noch...
@Rakke
also für mich war auch ISP der Hauptgrund. ATmega8 hat sicher den Vorteil, dass die Programmierung gleich bleiben kann (der ATmega168 hat zwar die gleiche Pinbelegung, aber trotzdem kleinere Unterschiede, z.B. geht die original Sleep()-Funktion nur mit Anpassung - aber dafür 16KB). Nur den originalen ATmega8 sollte man vielleicht nicht nehmen, der Bootloader könnte beim ISP verloren gehen(?)
Wie hast Du denn die Verbindung mit dem Asuro geplant? Willst Du direkt am Asuro ansetzen, oder auch ein Stockwerk drauf?
Überlegen solltest Du, was Du mit dem Quartz machst. Bei mir ist der Abstand zum Originalquartz ja doch etwas groß, deswegen benutze ich den nicht mehr. Im Moment habe ich noch den internen Takt, weil ich den Chip manchmal auf dem Steckbrett habe. Ist bei mir auch noch original mit 1MHz getaktet. Fuse-Bits können wohl ein Problem sein, wenn man damit spielt – wenn man sich vorher überlegt, was man macht sollte es aber kein Problem sein (spreche da aber nicht aus Erfahrung - siehe https://www.roboternetz.de/wissen/in...leicht_gemacht ).
RS232 habe ich mittels MAX232ACPE beim Programmer mit draufgepackt – hat bisher klaglos funktioniert. Ob es gemeinsam mit IR-Transmitter geht, weiss ich nicht. Kann es aber auch nicht testen, weil ich nur eine serielle Schnittstelle habe. Werde IR auf dem Asuro zur Hinderniserkennung umbauen (https://www.roboternetz.de/phpBB2/viewtopic.php?t=11114 ) – hoffe einfach mal, das geht gleichzeitig (notfalls muss ich umstecken).
so, hoffe das beantwortet Deine Fragen – viel Erfolg beim Basteln! Poste mal Dein Ergebnis, wenn Du fertig bist – bin gespannt, was Du für einen Ansatz wählst.
Ich hatte mir den Umbau des Asuro ähnlich wie bei dir vorgestellt: ein paar Pfostenverbinder, zweite Etage mit dem modifizierten Prozessor, so dass ein Wechsel zur Originalkonfiguration einfach möglich ist. Auf die zweite Etage wollte ich dann den MAX232 und die Verbindung zum ISP setzen, Rest lassen wie er ist. An Probleme mit den Quarz-Leitungen hatte ich natürlich nicht gedacht - guter Hinweis.
Wie sind deine Erfahrungen zum ISP-Anschluss des Asuro, wie hast du den umgesetzt? MISO, MOSI und SCK sind ja zugleich noch für die Ansteuerung des rechten Motors verwendet. Bislang hatte ich da einen Umschalter Flash-Run vorgesehen, den ich mir aber auch gerne spare.
Den Schaltplan vom ISP-Prg habe ich gejückt bei http://elm-chan.org/works/avrx/report_e.html und versuche mich an einer Umsetzung für Streifenplatine.
Für den MAX232 wollte ich mich an dessen Spec langhangeln, habe dazu aber noch keinen Schlag getan. Aber bald kommt ja der Winter mit seinen langen, dunklen Abenden
erstmal noch ein Nachtrag: ATmega168 Pin1 und Asuro Pin1 sind bei mir mit einem Widerstand (wohl 100k) verbunden - RESET vom Programmer liegt direkt am Pin. Beim Asuro ist dieser Widerstand gegen VCC nicht drin. Ohne ging es bei mir aber nicht.
Also, ich habe den Programmer unmittelbar an den AVR angeschlossen. Das funktioniert bei mir problemlos. Allerdings sollte man den Asuro aufbocken, weil der Motor mit angesteuert wird. An MOSI hängt ja D10 - hoffe die übersteht das auch ohne Probleme - habe die aber seitdem nicht getestet!
die beiden Diskussionen habe ich mir angeguckt (die erste kannte ich sogar, fand sie aber nicht sehr erhellend). Langsam blicke ich durch. Das der Widerstand zwischen VCC und #Reset muss, sehe ich ein. Dreht sich der rechte Motor beim programmieren tatsächlich mit? Na gut, dann wird nur auf der Hebebühne geflasht.
habe mich eben in den Schaltplan vom Asur vertieft und verstehe nun doch nicht, warum man den Asuro beim ISP-Flashen aufbocken muss. Zwar sind mit MISO und SCK zwei Leitungen zum rechten Motor doppelt verwendet, aber die steuern doch "bloß" die Drehrichtung? Dreht sich der Motor tatsächlich oder fiept der nur?
Als Maschinenbauer würde ich jetzt mutmaßen, dass als Abhilfe doch eigentlich reichen würde, die Leitung vom PB2 (Motortakt) beim Flashen über einen Widerstand gegen Masse zu schalten, z. B. über einen zusätzlichen Kontakt, der beim Aufstecken des Flash-Steckers die Verbindung herstellt.
Kennt sich hier jemand mit sowas aus? Zum scheitern verurteilt?
also das mit dem Aufbocken stört Dich wirklich, oder? Habe es gerade nochmal probiert. Tatsächlich: beim programmieren steht er ganz brav und still (hast Recht, beim Blick auf den Schaltplan ist das doch nicht so überraschend...). Allerdings, ruckt er kurz (ca. 1cm) am Anfang, wenn der Programmer anfängt (reset?). Soweit also kein Problem, die Antwort lautet: Ja, man kann auch ohne Aufbocken programmieren.
Soviel zur Theorie: Praktisch sieht es aber bei mir so aus, dass der Asuro nach dem programmieren sofort startet (kann man wohl im avrdude abschalten). Das heißt, wenn das Programm die Motoren benutzt, ist er nach dem Programmieren ganz schnell runter vom Tisch. Kann natürlich auch passieren, dass man versehentlich die Motoren anschaltet...
Außerdem: Ich finde es aufgebockt ganz praktisch - so kann ich das Programm gleich testen, wenn er noch am Programmer hängt und muss nicht ständig den Stecker rein und raus... Und über avrdude habe ich auch noch einen Reset vom PC aus.
Nachtrag zur Messung der Batteriespannung: Habe mir nochmal den c't-bot angeschaut und siehe da, es geht noch einfacher: Habe jetzt den Enable Pin des LCD mit RCK/strobe vom Schieberegister zusammengelegt. Damit wird ein Pin am ATmega frei und die Messung der Batteriespannung wieder verfügbar. Dem LCD scheint das egal zu sein - man muss nur aufpassen, dass man das Display bei Ansteuerung der weiteren Leitungen am Schieberegister nicht verwirrt. Damit bleiben jetzt alle Funktionen des Asuro erhalten!
Wenn man will, kann man sogar die beiden anderen Leitungen des Schieberegisters wieder mit der StatusLED belegen - dann hat man am Schieberegister noch zwei zusätzliche Kanäle gewonnen.
also der Programmer ist ein STK200 kompatibler Eigenbau nach Vorbild von https://www.roboternetz.de/wissen/in...ogrammierkabel. Ein Problem mit dem ATmega168 gibt es bei der Hardware meines Wissens nicht. Allerdings unterstützt PonyProg den 168 noch nicht (gab hier mal eine Diskussion wonach er möglicherweise als ATmega16 programmiert werden kann). Ich benutze avrdude - das funktioniert.
Zitieren
.
Lesezeichen