Plötzlicher AVR - Tod

Hi, Peter!

Danke für Deinen Tip!
Allerdings arbeitet mein Programmer seriell. Er hat noch einen 74HC14N - 
Chip drauf, der das ganze wohl irgendwie puffern soll. Außerdem benutze 
ich extra einen alten 386er Computer zum Flashen...
Vielleicht hast Du trotzdem recht.
Der Programmer, den Du benutzt, kann man anscheinend nicht fertig oder 
als kompletten Bausatz erwerben, oder? Sieht ja sehr interessant aus, 
das Teil!

Danke nochmal

Johannes

Dein HC14 tut leider nur as an der Signalqualität, leider nicht an deren 
Timing. Hilft in der Situation also nicht recht.

Auch ein 386 sollte problemlos in der Lage sein, dass entsprechende 
Schnittstellen-Timing für den Programmer auf die Reihe zu bekommen. 
Scheint mir eher ein Problem der nicht ganz ausgereiften 
Elektor-Software zu sein.

Das STK 500 ist das Standard-Atmel-Entwicklungsboard, dass es 
mittlerweile an so ziemlich jeder Ecke zu kaufen gibt. Sogar bei Conrad 
(da ist es allerdings zu teuer).
---
Holger

Kann es nicht sein das das fuse und lock Bit gesetzt wurde? Ich kann mir 
zwar nicht erklären warum aber das könnte doch sein oder? Ich würde mal 
den Programmer aus dem Tutorial nachbauen und damit testen ob man das 
fuse und lock Bit wieder löschen kann. Wie das geht steht hier im Forum 
einige mal man musste die Spannung unter einen wert senken und dann 
einen erase machen.

Mein beileid

Hi!

Kilian, so wie es aussieht hast Du Recht gehabt - die Such - Funktion im 
Forum hatte ich erst gar nicht gesehen. Ich habe die Versorgungsspannung 
mal auf 4 Volt gesenkt, und nach dem zweiten Versuch meldete sich der 
AVR wieder. Löschen ging auch, Programmieren dann erst nach mehreren 
Versuchen mit etwas höherer Spannung. Das Teil scheint ja ganz schön 
empfindlich zu sein, was das angeht!
Seltsamerweise macht das Programm trotzdem noch nicht das, was es 
sollte, obwohl es vor ein paar Veränderungen noch lief. Der Port B 
bleibt dauerhaft auf high...
Na ja, wenn ich den Fehler finde und das Programm fertig ist, werde ich 
es hier mal posten...

Vielen Dank an alle, die sich Gedanken gemacht haben!

Johannes

Ich bin´s nochmal,

Die Chips laufen tatsächlich wieder und das Programm in seiner 
Grundfunktion auch. Seltsamerweise hat er sich während der Fehlersuche 
nie mehr "totgestellt"...
Habe jetzt fast vier Stunden dafür gebraucht um festzustellen, daß ich 
vergessen hatte, ZH zu initialisieren. Der Simulator verhält sich da 
offenbar anders als der echte AVR...

Hat jemand Interesse an dem Programm zur Schrittmotorsteuerung? Ist 
eigendlich nix wildes, man kann bis jetzt zwei Motoren mit seriell 
übertragenen Buchstaben links/rechts bewegen. Dazu kommen sollen noch 
Features wie direkte Koordinatenangabe mit automatischer Fahrt auf dem 
kürzesten Weg, Koordinatenspeicher, variable Geschwindigkeit etc. 
Vielleicht mal automatisch abfahrbare Wege...
Ich hatte mal dran gedacht, mit zwei Motoren und Spiegeln nen Laser 
abzulenken und Muster an die Wand zu projezieren, aber so wie es 
aussieht, sind die Motoren bei 300 (Voll-)Schritten pro Sekunde schon so 
ziemlich am Ende... Na, mal sehen, ob das reicht...

versuche mal, die Schrittmotoren zu "beschleunigen", d.h. also nicht 
sofort mit Full-Speed zu fahren. Die Trägheit der Mechanik läßt sich so 
ein wenig austricksen. Außerdem sollte der Motor-Treiber die Spannung 
nachführen, so daß der Strom konstant bleibt - Je schneller ein 
Schrittmotor dreht, umso kleiner wird der Strom durch die Spulen. Wird 
die Spannung nachgeführt, kann man wesentlich höhere Taktraten erzielen.

Ist zwar richtig, aber ein bißchen verwirrend. Diese Betriebsart nennt 
sich Konstantstrombetrieb und ist auf jeden Fall zu empfehlen. 
Stromabsenkung bei Stillstand nicht vergessen, sonst werden die 
Motörchen zu warm.

Hi Johannes,
ich bin grad an nem sehr ähnlichen Projekt. Ich hab mir ne Platine mit 3 
TCA3727, einen 2313 und einem MAX232 für die UART-Kommunikation gebaut. 
Allerdings hab ich noch ein Paar seltsame Probleme, z.B. funktioniert 
die ISP-Programmierung auf der Platine nur so halb, der AVR verhält sich 
ziemlich seltsam usw. Hab aber grad auch nicht so viel Zeit, mich damit 
zu beschäftigen...
Aber schick mir mal bitte dein Programm!
Danke
Phil

Hi Johannes,
ich wundere mich immer wieder über solche Probleme. Ich habe hier schon 
bestimmt 50 Controller (2313, Mega8 und andere) Programmiert und 
getestet. Das beschriebene Problem ist aber noch nie aufgetreten. Ich 
vermute eher, das es mit der Schaltung und/oder dem Programmer und 
dessen Software zusammenhängt.

Gruß
Markus

'n Abend...

@thkaiser
Soweit ich weiß, tun die TCAs genau das, die kanen ne Stromüberwachung. 
Das mit der Stromabsenkung könnte ich machen, aber das würde pro Motor 
zwei weitere Pins erfordern. Dann könnte ich auch Halbschritte fahren, 
aber dann kann ich nur noch zwei Motoren über einen Port betreiben statt 
vier...

@phil:
Ich hab das Programm mal angehängt. Die TCAs hängen dabei an PortB, Pins 
1/2 bzw. 3/4. Mit der Eingabe von "B" und "P" über den UART kann man den 
ersten Motor dann links bzw. rechtsdrehen, zu Testzwecken. Viel Erfolg 
für Dein Projekt!

@Markus:
Ja, das wird wohl irgendwie mit der Software zusammenhängen. Die ist in 
Turbo Pascal geschrieben und kalibriert sich noch nichtmal den Timer für 
die Wartezeiten... Und den fremden Code zu verbessern währe wohl etwas 
viel Aufwand...
Leider funktionieren PonyProg etc. nicht mit der Schaltung und ich hatte 
noch keine Lust und Zeit, mir das mal genauer anzusehen...