Zitat Zitat von manhunt
... Da hat Atmel bzw der avr-gcc/avr-libc einfach bei der implementierung der atmega328p geschlampt ...
Das glaube ich erstmal NICHT (ist auch kein Spass - nicht so spät nachts). Bei wenigen anderen Fällen hatten sich ähnliche Vermutungen durch mich nie bewahrheitet. Ich hatte so etwas auch nie ernsthafter geglaubt. Es geht sicherlich auf eine Unsauberkeit im Code zurück, vielleicht bei meiner Headerdatei. Hier bekomme ich sicher die Quittung für "Mutiges Programmieren bei bescheidenen Sprachkenntnissen". Headerdatei gibts hier wegen 20 000 - Zeichen-Limit bei Forumpostings.

Zitat Zitat von manhunt
... hast du wirklich atmega328p eingegeben und wenn ja kannst du probieren das p wegzulassen ...
Ja und ja. Das "p" weglassen geht bei den Projekt Options nicht, da gibt es nur ein Flyout (die Programmierer kennen ja ihre Pappenheimer) bzw. beim Erstellen eines neuen Projektes eine feste Deviceliste, beide mit einer definierten Auswahl. Die Deklaration einer MCU im Code ist danach überflüssig, läuft mit oder ohne, "Die Programmierer ... " siehe oben.

Zitat Zitat von manhunt
... sicher nicht ALLE SFR vom 168 an den selben Adressen beim 328 sitzen ...
Ich hatte gestern vor posten meines Hilferufes die docs 2545P–AVR–02/09 zu ATmega48/88/168 und 8161C–AVR–05/09 zu ATmega48PA/88PA/168PA/328P miteinander verglichen. Die Vektortabellen sind für meine beiden Controller gleich, andere Hinweise für Unterschiede hatte ich nicht gefunden. Das auf mehrere ISR gestützte Programm für den m168 läuft im MiniD0 - siehe das Beispiel im obigen Link, da aber noch mit m168 - problemlos auf dem m328 im MiniD0 mit gleichen Bewegungen. Auch das erste Flashen ging problemlos, >>nachdem<< ich nach mehreren Versuchen festgestellt hatte, dass CKDIV8 aktiv war, wodurch der Controller weder bei 1,5 MHz noch bei 375 kHz erkannt wurde. Erst mit weniger als 100 kHz meldete er sich . . . . . Wird wohl ein anstrengendes Wochenende. Aber ich habe jetzt ja wieder neue m168er *gggg*.