Fuse Bits ATMega168

Erst einmal den Part, den ich gleich beantworten kann:

Stimmt, der ATMega8 ist der original Asuro und stimmt, ich hab gelesen, dass bei dem ISP deaktiviert war. Daran hat ich gestern abend nicht mehr gedacht.

Den Asuro 16K hab ich von (http://www.e-robotix.de/epages/61660...ducts/Asuro16K). Da hab ich aber nicht gefunden, dass ISP deaktiviert ist - oder doch?

Den ATMega168 hab ich von e-robotix (http://www.e-robotix.de/epages/61660.../Products/AVR2). Ich muss mal auf der Rechnung nachsehen, was da steht. Erkennt man den Unterschied sonst einfach am Gehäuse/ an der Beschriftung?

Zu den Versuchen: muss ich mal probieren.

Was heisst dann aber : funktionieren? Ich hatte vorher schon einmal Programmcode geflashed. Der müsste dann nach wie vor ausgeführt werden?
Der Asuro mit dem originalen Prozessor läuft - also sollte Prinzipiell der Quarz funktionieren. Das Ansteuern der LEDs und der Motoren hatte auch schon funktioniert (mit aufgestecktem Adapter und ATMega168). Diese Leitungen sind also erst mal nicht gestört.

Ein Osszi hab ich nicht, aber ich muss mal schauen, ob mein Multimeter auch Frequenzen messen konnte. Was gilt es denn zu beachten, wenn man mit einem Multimeter am Prozessor messen will? Hier kommen doch bestimmt Innenwiderstände des Messgerätes ins Spiel? Sprich: macht das überhaupt Sinn?

Der Asuro 16K scheint ein vorkonfektionierter Prozessor mit Bootloader zu sein. Da sind auch die fuses schon eingestellt. Den sollte man mit ISP nicht programmieren, sonst besteht die Gefahr, dass danach der Bootloader weg ist. Könnte aber auch sein, dass ISP wie beim Original Asuro Prozessor deaktiviert ist.

Der ATmega168 wird ein Fabrik frischer Prozessor sein, der mit internem Takt und 1MHz läuft. Den hast du wohl geschrottet. wobei da durchaus noch Hoffnung besteht, ihn wieder zu beleben.

Ob Atmega168 oder ATmega168P ist wohl egal, da habe ich mich geirrt. Die unterscheiden sich nicht bei den Fusebits, sondern nur bei der Prozessor Kennung. Das sollte der ISP Programmer bzw. avrdude selber feststellen, falls da etwas nicht stimmt.

Das eingebrannte Programm kann nur funktionieren, falls auch der Prozessor noch läuft, d.h. wenn er einen Prozessor Takt bekommt. Der Takt ist halt dummerweise von den fuse bits abhängig.

Mit dem Multimeter könntest du z.B. die Versorgungsspannung prüfen, viel mehr aber wohl kaum.

Zuerst zum Multimeter: Es ist ein Voltcraft VC480, das laut Beschreibung

Zitat:

sinusförmige Wechselspannung bis max. 10 MHz

messen kann. So ähnlich hatte ich das auch in Erinnerung. Nun wird der Takt aber kein Sinus, sondern ja wohl Rechteck sein. Dann gab es noch eine Einschränkung:

Zitat:

Bei Spannungen ... kleiner 600 mVrms über 1MHz und < 10 MHz ist keine Frequenzmessung möglich.

Schön aber auch, ich kenne mV, was sind denn nun wieder mVrms? Mir ist auch nicht gelungen, irgendwas auf die Anzeige zu bekommen (Quarz Mittelfuss gegen rechtes oder linkes Bein war nix. Und da ich eh unsicher war, ob die Messerei schaden tut, hab ich es dann auch gelassen). Na gut - der Takt scheint ja noch da zu sein -

Die gute Nachricht: Der ATMega168 scheint noch am Leben zu sein. Zumindest tut er genau dass, was ich zuletzt geflashed habe - die Back-LED im Wechsel schalten und die Motoren anzusteuern. Er scheint jetzt auch mit der richtigen Frequenz zu laufen. Zumindest ist der Ablauf jetzt ein ganzes Stück schneller als vor der Manipulation der FUSE-Bits.

Die schlechte Nachricht: ich bekomme nach wie vor keinen Kontakt zum Controller.

Zitat:

Enter programming mode: FAILED!

ist die spartanische Antwort vom AVR-Studio

Zitat:

stk500v2_command() : command failed

meint avrdude. Dann hat wohl der Programmer das Abziehen vom USB-Anschluss nicht überlebt? Sind die Teile wirklich derart empfindlich? Oder kann es doch am Controller liegen? Hat sich dort die ISP-Schnittstelle deaktiviert? Dann wiederum sollte mein andere ATMega168 (noch im Originalzustand) doch reagieren (was er nicht tut)!

Was ist eigentlich empfehlenswert als Programmer?
Wenn ich es richtig verstanden habe, nutzt ihr selbst gebaute Programmer. Ich fand die Anbindung über USB ganz entspannt. Es gibt mir auch die Möglichkeit, auf neuere Hardware (Notebook) zu wechseln. Auch das Durchleiten der Versorgungspannung vereinfacht den Aufbau. Das Mappen auf die COM-Ports stört mich aber erheblich. Ich würde es gut finden, wenn die Software gegen USB geht und keinen COM-Port benötigt!

Ich werd blöd: jetzt kann ich den Chip wieder auslesen! Es klappt aber nur, wenn der Programmer nicht mehr die Target-Spannung anlegt. Zumindest für das Lesen. Beim Schreiben muss ich dann die Target-Spannung am Asuro anlegen. Na gut, damit kann ich leben.

Nun komm ich wieder zu meinem ersten Problem: die IR-Kommunikation auf dem Adapter geht nicht. Ich werd jetzt noch mal ein paar Tests mit SetPUTC machen und mir dann erst mal ne Mütze Schlaf holen.

Ok, die letzte Erkenntnis:

1. ) Die IR-Dioden (Front und seitlich) arbeiten. Mit UartPutc wird was gesendet.
2.) Die Zeichen auf der Gegenseite lassen sich nicht rekonstruieren (empfange mit dem IR-Programmer) - scheint wohl Takt irgendwo noch nicht zu stimmen
3.) Die Abstandsmessung sendet keine IR-Signale

Meine Modifizierung (wegen ATMega168)

Code:

uint8_t objekt_sichtbar(uint8_t distance) { uint16_t j,z; DDRD |= (1 << DDD1); // Port D1 als Ausgang PORTD &= ~(1 << PD1); // PD1 auf LOW #if defined(__AVR_ATmega168__) OCR2A = 254-distance; //OCR2=0xFE ( sehr nahe ) #else OCR2 = 254-distance; //OCR2=0xFE ( sehr nahe ) #endif z=0; for(j=0;j<30;j++) // loop time: 5ms { if (PIND & (1 << PD0))z++; Sleep(6); // 6*Sleep(6)=1ms } if (z>=29) return FALSE; // Objekt nicht gefunden else return TRUE; } // der Rest ist unveraendert, denke ich uint8_t abstand() { uint8_t k,n; k=255; for(n=0;n<8;n++) { if (!objekt_sichtbar(n)) k=n; // solange kein Objekt, Distanz erhoehen } return k; } int main(void){ uint8_t n; Init(); FrontLED(ON); StatusLED(OFF); n = 0; while(1) { n=abstand(); if(n!=255) { if (n<6) StatusLED(GREEN); if (n<4) StatusLED(YELLOW); if (n<3) StatusLED(RED); if (n<2) BackLED(ON,ON); } Msleep(10); } }

Ich muss ehrlich sein: ich hab noch nicht geschaut, welcher Befehl einen "Beep" über IR-Diode sendet und welcher empfängt. Bin jetzt auch zu müde ...

Moin moin

Ich muss mich hier mal mit ein klinken, da es auch um die FuseBits vom Atmega 168 geht. Ich weigere mich einfach zu akzeptieren, dass ich 5€ für 2 Chips in den Sand gesetzt habe.

Nachdem ich die Fuses verbockt habe - genau wie oben - habe ich mal so, die low SCK Modus von meinem AvrDoper ausprobiert und damit kam ich tatsächlich an meinen Chip ran! Dachte ich mir:

Ok, schnell wieder die Standard-Einstellungen drauf und dann in Ruhe lassen:

Ergebnis, verklickt, zu schnell, da schon lange frustiert damit ...

Jetzt komm ich gar nicht mehr ran. Ich habe mMn Int. RC OSC 128 khz angeklickt. (Da lfuse auf 0x63)

lfuse auf 0x62 wäre mit intern 8Mhz wahrscheinlich sinnvoller gewesen...

Kann es sein, dass mein Programmierer jetzt auch für diese super langsamen 128 khz zu schnell ist?

Ich nutze den AVR-Doper (http://www.obdev.at/products/vusb/avrdoper.html) Kennt sich jemand mit diesem Problem aus?

Ich muss mir das mal anlesen.

Anderes Thema: Gibts denn über High-Voltage Programming ne Möglichkeit dass alles zurückzusetzten auf die Standard-Einstellungen, oder was bringt mir das?

Danke und Entschuldigung, aber ich will das nur schnell runter geschrieben haben, da ich jetzt die Nase voll hab!

Andun

Hi Andun,

mit einem HV-Progger kannst Du das auf jeden Fall wieder gerade biegen.

Gruss,

O.

Ein HV-Programmer kostet aber auch viel im Gegensatz zur ISP Programmierung.