Atmega 168PA - USBASP - 3,3V

Wichtig ist dass du die Vcc Eingängen ordentliche mit Kondensatoren 
bestückst, ein paar 100nF und ein paar µF Kerkos ganz nahe an den 
Eingängen und 100µF noch irgendwo auf der Platine.

Wenn es dann immer noch so ist dass dein ATmega168PA mit dem 3.3V und 
12MHz nicht läuft, solltest du erst mal probieren ab welcher Spannung 
genau er nicht läuft.
Verbinde ihn mit einer verstellbaren Spannungsversorgung und dreh die 
Spannung von 0V bis auf 5V.
Als Software kannst du eine nehmen die einfach einen Portpin Togglet 
oder per UART Daten sendet.

Mit dem P-Varianten habe ich nur gute erfahrungen gemacht.
Beispiel ATmega644P:
 - läuft mit 2.8V und 26MHz
 - bei 12V kann man runter bis auf 1.9V gehen

Manfred schrieb:
> Der PA ist von 1,8 –
> 5,5V bis 20mhz spezifiziert.

Nein, nicht direkt.

Datenblatt sagt:
•  Speed Grade:
– 0 - 4 MHz@1.8 - 5.5V, 0 - 10 MHz@2.7 - 5.5.V, 0 - 20 MHz @ 4.5 - 5.5V

Meine Informationen stammen aus dem vollen Datenblatt:

http://www.atmel.com/dyn/resources/prod_documents/doc8271.pdf

avion23 schrieb:
> Bei 3,3V schafft der laut Datenblatt keine 16MHz sondern nur 12MHz.
> Steht unter electrical characteristics.

Korrekt.

Manfred schrieb:
> Jetzt die Frage kann es sein das er auch mit 16mhz
> bei 3,3 läuft?

Kann sein, muss aber nicht. Mit 12Mhz läuft er sicher.

Figure 29-1 im vollen Datenblatt auf Seite 322 gibt Auskunft. Alles was 
innerhalb der 'Safe Operating Area' liegt , ist  von  Atmel 'garantiert' 
, ausserhalb nicht.

Mike J. schrieb:
> Als Software kannst du eine nehmen die einfach einen Portpin Togglet
> oder per UART Daten sendet.
Das ist völlig ohne Wert. Solange man nicht ALLE Komponenten testet.

avion23 schrieb:
> Das ist ein grosses Fragezeichen. Du uebertaktest die CPU damit
> effektiv
Ganz genau. Scheint beim 168 und 168P auch weniger Probleme zu bereiten. 
Obwohl der Timer 2 mit Uhrenquarz und internen 8 MHz unter 3 Volt auch 
Probleme bei der Rückkehr aus dem Sleepmode macht.

Die PA/A scheinen anspruchsvoller zu sein. Zeigen auch ein anderes 
Verhalten beim Aufwachen aus dem Sleep (längeres Einschwingen).

Letztlich outet sich der Arduino als Gurke, die ausserhalb der 
Spezifikation betrieben wird und mit 168P nur zufällig läuft.

mfg.

Thomas Eckmann schrieb:
> Das ist völlig ohne Wert. Solange man nicht ALLE Komponenten testet.

Es gibt ein Problem mit dem langsamen Flash und dem EEprom.
Wenn der Flash läuft dann läuft auch alles andere. (ausgenommen des 
EEprom)

Mike J. schrieb:
> Wenn der Flash läuft dann läuft auch alles andere.
Dein Wort in Gottes Ohr.

mfg.

Okay, ich kann nur sagen dass ich wohl immer die Chip Chargen abbekomme 
die besonders gut sind und daher bin ich privat ein "Undervolting-Fan" 
geworden, es macht einfach Spaß.
Die AVR scheinen einen recht großen Spielraum (nach unten) zu haben, 
besonders die P-Varianten.

Es wäre natürlich fatal wenn er es industriell so nutzt.

Meiner Meinung nach ist der Betrieb bei 5V (quasi kurz unter dem Abs. 
Max. Rating) auch nicht so sehr schlau.

Wenn sein Target-Board mit 16MHz betrieben wird und 3.3V zur Verfügung 
stehen sollte es aber funktionieren.

Es kann natürlich sein dass sein ISP-Kabel zu lang ist, entweder er 
senkt die Programmierfrequenz (Slow-ISP-Clock-Jumper) oder er verkürzt 
das Kabel.

avion23 schrieb:
> Man kann auch Abblock-Kondensatoren weglassen.
Wenn der Spannungseinbruch beim schalten der Logik so gering ist dass er 
nicht aus geht (Brownout bei 2.6-2.9V) okay, aber wer kann da schon 
abschätzen.

Er kann ja mal ein Bild seines Target-Boards zeigen, es gab z.B. schon 
Problem beim Betrieb des USBisp von Christian Ulrich, als Lösung wurde 
dann ein  47µF Kondensator an den 5V vom USB als Abblockkondensator 
angeschlossen.