Quarz und Clock bei AVR series 1 (z.B. Attiny 816)

[Michael W. (micha124)]

Hallo,

ich gelange gerade in einem Projekt mit dem Attiny4313 an die 
Speichergrenze und überlege daher hier noch einen Switch zu einem der 
neuen series-1 oder auch 0 zu machen (also z.B. einen >=Attiny816).

Ich bin hier aber gerade ziemlich verwirrt in Bezug auf die 
Quarz-Nutzung. Da ich eine serielle Busanbindung mache, habe ich 
zumindest beim 4313 einen 3,6864MHz Quarz verwendet und entsprechend an 
XTAL1/XTAL2 angeschlossen.

Hier hat sich wohl was vom Grunddesign geändert und ich finde hierzu 
aber keine Erläuterung. Bei den series-0 kann gar kein externer Quarz 
angehängt werden, bei den series-1 lese ich das Datenblatt so, dass hier 
ausschließlich ein 32768 kHz Quarz angeschlossen werden kann. Ansonsten 
gibt es noch einen internen 20MHz Oszilator oder ich muss eine komplette 
externe Clock-Source anhängen.

Beim 4313 konnte ich da mehr oder weniger beliebige Quarze und damit 
auch beliebige Systemtaktraten erreichen.

Wurde das nun tatsächlich geändert, dass der mit einfachen Mitteln 
entweder ungenau mit ~20MHz oder mit Quarz auf 32kHz arbeitet? Oder ist 
der interne Osci so genau, dass es keinen Quarz mehr braucht und die 
Taktrate wird dann nur per Prescaler heruntergeschraubt - warum dann 
aber die 32kHz Option?

Oder würde der mit Quarz die 32kHz nur für eine SystemClock verwenden, 
für den Systemtakt aber die 20MHz?

Kann ich bei dieser Reihe hier auch die "gewohnten" 3,7MHz nehmen (in 
der Annahme, dass hier auch der Stromverbrauch besser ist - 
Geschwindigkeit ist nicht mein Problem)? Ich hänge auch nicht an der 
Taktfrequenz, will aber zumindest halbwegs sicher gehen, dass die 
serielle Kommunikation auch mit dem neuen Layout noch funktioniert (weil 
ich hier gleich noch neue Platinen brauche und an sich nur die CPU 
tauschen würde)

Wenn hier jemand zur Aufklärung beitragen kann, wäre ich sehr dankbar.
Ebenso so auch, wenn das Upgrade sinnvoller auf eine andere CPU gehen 
sollte (wobei ich in der AVR-Familie bleiben will)

Grüße Micha

[Gerhard H. (hauptmann)]

Der interne Clock ist bei den neuen AVRs genauer und erübrigt Quarze für 
serielle Kommunikation, wenn Baudraten und externe 
Temperaturschwankungen nicht gerade exorbitant ausfallen.
Die 32kHz Option lässt sich zum Beispiel für eine noch genauere 
Taktnachjustierung verwenden bzw. als Taktgeber für eine eingebaute RTC.

Michael W. schrieb:
> wenn das Upgrade sinnvoller auf eine andere CPU gehen
> sollte (wobei ich in der AVR-Familie bleiben will)

Für universelle Verwendung auf minimalem (aber bequem lötbaren) SMD Raum 
empfehle ich die neuen AVR64DD14 aufwärts, bei mehr Platz und Pinbedarf 
genauso die AVR128-DB Reihe (beide inkl. DIP Gehäuse-Versionen). Auf die 
neuen AVRs sollte man der vielen Vorteile wegen jetzt wirklich langsam 
umsteigen.

[Georg M. (g_m)]

Beide Quarze möglich z.B. bei:

AVR32EA28/32/48
AVR16EA28/32/48

[Peter D. (peda)]

Michael W. schrieb:
> überlege daher hier noch einen Switch zu einem der
> neuen series-1 oder auch 0 zu machen (also z.B. einen >=Attiny816).

Die neuen AVRs haben doch recht umfangreiche Änderungen zu den 
klassischen, besonders die Timer wurden komplett umgestellt.

Willst Du möglichst wenig am bisherigen Code ändern, rate ich zum 
ATmega328PB.

[Michael W. (micha124)]

Hi

Gerhard H. schrieb:
> Für universelle Verwendung auf minimalem (aber bequem lötbaren) SMD Raum
> empfehle ich die neuen AVR64DD14 aufwärts, bei mehr Platz und Pinbedarf
> genauso die AVR128-DB Reihe (beide inkl. DIP Gehäuse-Versionen). Auf die
> neuen AVRs sollte man der vielen Vorteile wegen jetzt wirklich langsam
> umsteigen.

vielen Dank für den Tip. Ich werde den erstmal verfolgen.

Peter D. schrieb:
> Die neuen AVRs haben doch recht umfangreiche Änderungen zu den
> klassischen, besonders die Timer wurden komplett umgestellt.
> Willst Du möglichst wenig am bisherigen Code ändern, rate ich zum
> ATmega328PB.

Danke für die Info
Ich werde den 328 mal im Hinterkopf behalten. Da ich aber von ausgehe, 
dass der Switch eh irgendwann notwendig sein wird und ich auch nicht 
zuviele Varianten haben will (das ganze ist weiterhin Hobby und private 
Use - ich muss also nicht den letzten Cent am Chip sparen), kann ich mit 
etwas Code umschreiben auch leben und würde die series-1 dann eher als 
neuen Default sehen.

Einziger Nachteil, den ich aber schon behoben habe: ich habe aktuell 
noch keinen Programmer für UPDI, mir aber jetzt doch mal einen ICE 
gegönnt.

Grüße und Danke für die ganzen Meinungen und Aufklärungen

Micha

[Gerhard H. (hauptmann)]

Michael W. schrieb:
> ich habe aktuell noch keinen Programmer für UPDI, mir aber jetzt doch
> mal einen ICE gegönnt

Der kleine Debugger nEDBG der auf jedem 20€ Curiosity Nano AVR 
Evaluationsboard zu finden ist hätte für UPDI alleine auch gelangt.

[Georg M. (g_m)]

Michael W. schrieb:
> mit etwas Code umschreiben

Den Programmcode wird man schon komplett neu schreiben müssen. Aber die 
neue Schreibweise ist deutlich verständlicher als die frühere mit vielen 
"<<".

PORTA.OUTSET = PIN1_bm;             // PA1 on

PORTA.OUTCLR = PIN2_bm;             // PA2 off

PORTA.PIN6CTRL = PORT_PULLUPEN_bm;  // Pull-up on PA6

ADC0.CTRLB = ADC_SAMPNUM_ACC16_gc;   // accumulate 16 sampling results

[Michael W. (micha124)]

Gerhard H. schrieb:
> Der kleine Debugger nEDBG der auf jedem 20€ Curiosity Nano
> Evaluationsboard zu finden ist hätte für UPDI alleine auch gelangt.

ja, nur wegen UPDI ist der ICE overkill. Das war jetzt auch nur der 
letzte Anstoß gewesen. Mit dem ICE habe ich schon eine Weile 
geliebäugelt

Georg M. schrieb:
> Den Programmcode wird man schon komplett neu schreiben müssen. Aber die
> neue Schreibweise ist deutlich verständlicher als die frühere mit vielen

den Punkt hatte ich vorher schon gesehen gehabt und freue mich ehrlich 
gesagt auch auf die neue Möglichkeit eben wegen der Lesbarkeit und hoffe 
auch auf eine einfachere Preprozessor-Parameterisierung.
Der direkte HW-Zugriff ist bei dem Projekt auch ziemlich lokalisiert, so 
dass das relativ einfach sein sollte.

Grüße Micha