Diese Erklärung war mir wohl zu einfach 
Danke Serenifly!
Kannst du zu den anderen Fragen noch was sagen?
Der µC soll bei 3V (2 AA Batterien) mit 16MHz (evtl. auch 8MHz, falls das geht und Energie spart) betrieben werden.
8 MHz geht immer, und ist auch Max. bei 3V Versorgung. Für 16 MHz werden 4.5 ... 5.5 V spezifiziert.
Ich hab aber einen ATmega169PA und der geht auch bei niedrigerer Spannung bis 16MHz
Speed Grade:
– ATmega169A/169PA/649A/649P:
• 0 - 16MHz @ 1.8 - 5.5V
Allerdings zappelt der interne quarz nur auf etwa 8MHz wodurch meine Obergrenze tatsächlich bei 8MHz ist. Dennoch wäre es interessant den µC auch auf niedrigeren Takten laufen zu lassen um somit strom zu sparen.
Das Wissen dafür bringt mir bloß nichts, da ich nicht weiß, wie ich nun die CPU frequenz einstellen soll/muss/kann. 
Gerade habe ich allerdings noch deutlich grundlegendere Fragen und Probleme und ich wollte nur meinen Anwendungsfall nennen. 
EDIT: aber wo wir schon beim Thema sind:
Ich hab nen Quarz mit der Aufschrift "M2083841" am Pin XTAL1 und XTAL2 gefunden. Damit hätte ich Frage 3 also geklärt. Der läuft mit 32768Hz.
Mir schwirrt der Kopf vor so vielen unterschiedlichen Tabellen 
Zu pins_arduino.h allgemein:
Ich würde ich einen Kommentar begrüßen, der den jeweiligen Controller angibt (hat bislang niemand gemacht).
Ebenso hilfreich wäre es, die konstanten Arrays mit der zugehörigen Größe zu versehen, nicht nur mit [], dann könnte der Compiler warnen wenn die Anzahl der Einträge nicht stimmt.
Zu Deiner pins_arduino.h, ohne Gewähr für Klammern:
#define LED_BUILTIN = 13 //; <-- hier kein ;
// Die Nummer (also das X) des jeweiligen PCINTx Pins - muß auf zwei Sätze 0-7 gemappt werden (in PCMSK0 bzw. PCMSK1)
//#define digitalPinToPCMSKbit(p) ( (((p) >= 0) && ((p) <= 15)) ? (p) : 0) //\ <--- kein \ hier
#define digitalPinToPCMSKbit(p) ( (((p) >= 0) && ((p) <= 7)) ? (p) :
(((p) >= 8) && ((p) <= 15)) ? ((p) - 8) : 0)
Aus den Mega Interrupts werde ich nicht ganz schlau. INT0-3 wird (plausibel) auf Vektor 2-5 gemappt, aber was soll dann Vektor 0 (???) für INT4 sein, und Vektor 1 (RESET) für INT5?
-
Was die analogen Pins betrifft, ADC0-7 sind auch digital nutzbar.
-
PE7 kann verwendet werden, wenn nicht für CLKO konfiguiert. Das Risiko trägt der Programmierer
-
was ist XTAL1 (TOSC1) und XTAL2 (TOSC2)?
Da wird üblicherweise der Quarz angeschlossen (externer Taktgenerator). -
Ist es sinnvoll GP5 als DigitalPin zu definieren, da er ja auch gleichzeitig Reset Pin ist?
Eher nicht. Port G hat nur 5 Bits (0-4), GP5 dürfte also garnicht zugreifbar sein. -
Darf und kann ich es so machen oder wird es so Probleme geben?
Kai Neahnung -
Ist "core" durch "variants" ersetzen erlaubt und brache ich den core Ordner überhaupt? (oder wie soll ich es machen?)
In "core" stehen allgemein gültige Dateien. Wenn dieser Ordner bei Dir fehlt, weiß ich auch nicht weiter.
Ansonsten gehört die pins_arduino.h in den zugehörigen Ordner unter "variants", also z.B. \variants\LCD. -
Sind die Fuse-Werte weiterhin korrekt durch das Ändern der Werte wie z.B. CPU-Takt? (Falls nein, wie müssen die aussehen?
Kai Neahnung -
Bezeichnung des "mcu" frei wählbar?
-
"protocol"-Name frei wählbar?
Vermutlich, vermutlich -
Warum ist dann dennoch häufig ein "L" hinter der Zahl angegeben?
Damit es ein "long" (32 Bit) Wert wird, nicht bei 8 oder 16 Bit abgeschnitten. -
Wenn ich alles angepasst habe (und es auch stimmt), kann ich dann denn "bootloader" drauf brennen und ab dann zukünftig ganz "normal" über meinen USB<=>Serial Adaper andere Sketches über SS, SCK, MISO und MOSI drauf laden ohne den bootloader flashen/brennen zu müssen?
Eigentlich müßte jeder Chip schon mit Bootloader kommen. Ausprobieren schafft Klarheit
Bislang habe ich nur USART0 (Serial USB) zum Programmieren meiner Pro Mini verwendet, die Signale abgezapft vom ausgestöpselten Prozessor meines Uno. Serial USB dürfte mit SPI nicht funktionieren, andere Baustelle.
Ich danke euch, Serenyfly und DrDiettrich, wirklich tausendfach!
Nana, nicht gleich so überschwenglich. Wenns dann doch nicht funktioniert, sind wir natürlich schuld, das kennen wir schon
Ansonsten überlege ich, mich mal im Hardware(?)-Forum umzusehen, was da an Doku zu den Konfigurationsdateien schon herumschwirrt.
Alter Verwalter... du hast dir das also wirklich komplett reingezogen und auch logisch nachvollzogen!
Vielen,vielen Dank erstmal dafür!
Das Semikolon bei der LED_BUILTIN hab ich weg gemacht. Da lag mein Fokus anscheinend noch bei den ganzen Tabellen und Registern...
Bei #define digitalPinToPCMSKbit(p) hast du natürlich vollkommen recht. Der zweite dämliche Fehler
DrDiettrich:
Aus den Mega Interrupts werde ich nicht ganz schlau. INT0-3 wird (plausibel) auf Vektor 2-5 gemappt, aber was soll dann Vektor 0 (???) für INT4 sein, und Vektor 1 (RESET) für INT5?
Du meinst mit "Mega" den 2560?
Ich hab mich auch gewundert und drösel es dir mal so auf, wie ich es mir erlärt habe:
#define digitalPinToInterrupt(p) ((p) == 2 ? 0 : ((p) == 3 ? 1 : ((p) >= 18 && (p) <= 21 ? 23 - (p) : NOT_AN_INTERRUPT)))
Das heißt:
Wenn p==2 (PE4) dann = 0
Wenn p==3 (PE5) dann = 1
Wenn p>= 18 && p <= 21 (PD3, PD2, PD1, PD0 in der Reihenfolge) dann = 23 - p (also 5,4,3,2)
Eigentlich sind die Interrupts so Hardwareseitig eingebunden:
PD0 (INT0)
PD1 (INT1)
PD2 (INT2)
PD3 (INT3)
PE4 (INT4)
PE5 (INT5)
PE6 (INT6)
PE7 (INT7)
Da der Mega2560 aber sehr sicher korrekt eingebunden wurde (ist ja nicht gerade ein seltenes Arduino Board), habe ich es mir so erklärt, dass einfach irgendeine Zahl beginnend bei 0 und nicht übereinstimmend mit dem echten "INT" zugewiesen werden muss.
Daher wird das hier "softwareseitig" zugewiesen:
PE4 (INT4) = INT0
PE5 (INT5) = INT1
PE6 (INT6) = (nicht belegt am Arduino MEGA)
PE7 (INT7) = (nicht belegt am Arduino MEGA)
PD0 (INT0) = INT2
PD1 (INT1) = INT3
PD2 (INT2) = INT4
PD3 (INT3) = INT5
Wäre auch kein Problem gewesen, dass ganze korrespondierend zu der Zahl zu vergeben, ist aber anscheinend nicht notwendig oder ist tatsächlich falsch, denn wenn man sich das Pinout Schaubild anschaut, dann steht da z.B. fälschlicherweise bei PD0 "INT0", was zwar hardwareseitig stimmt, aber nicht vom pinout_arduino.h...
Für mich ist es allerdings in jedem Fall egal, da der ATmega169PA zum Glück nur ein INTx hat
DrDiettrich:
- Was die analogen Pins betrifft, ADC0-7 sind auch digital nutzbar.
Das ist gut!
(kommt wahrscheinlich aus der Info "Port F also serves as an 8-bit bi-directional I/O port,")
DrDiettrich:
2. PE7 kann verwendet werden, wenn nicht für CLKO konfiguiert. Das Risiko trägt der Programmierer
Ok da muss ich wohl durch. In dem Schaltplan wird der PE7 verwendet und umändern mit Leiterbahn abkratzen und am Chip rumlöten lass ich mal besser
DrDiettrich:
3. was ist XTAL1 (TOSC1) und XTAL2 (TOSC2)?
Da wird üblicherweise der Quarz angeschlossen (externer Taktgenerator).
Ja das ist mir später auch aufgefallen, als ich den Quarz (aufschrift "M2083841") gesehen habe.
Angeblich hat der 32768Hz (kann das sein?).
Woher weiß der Kontroller welchen Takt er über XTAL1 und XTAL2 bekommt und wie er daraus seinen Arbeitstakt macht?
Beim Uno ist es einfach. Der hat nen 16MHz Quarz und läuft bei 16MHz, aber was will man mit nem 32kHz Quarz bei nem Controller der maximal auf 16MHz läuft (und am besten noch um Energie zu sparen noch irgendwie runter getaktet wird).
Das muss wieder irgendwie über die Fuses gehen, aber ich finde da nur die Einstellungen:
0,4-0,9 MHz
0,9-3,0 MHz
3,0-8 MHz
8- MHz (das hier also für mich bei 16MHz)
mit Start-up time:
158CK
1CK
16CK
Keine Ahnung was das ist
und dann noch
+0ms
+4.1ms
+65ms
das ist wohl das "delay", dass der µC beim start wartet um einem Programmer die chance zu geben einen neuen Bootloader drauf zu brennen (falls das nicht stimmt bitte korrigieren).
Um die Verwirrung perfekt zu machen kann ich dann noch:
"Divide clock by 8 internally; [CKDIV8=0]"
auswählen...
DrDiettrich:
4. Ist es sinnvoll GP5 als DigitalPin zu definieren, da er ja auch gleichzeitig Reset Pin ist?
Eher nicht. Port G hat nur 5 Bits (0-4), GP5 dürfte also garnicht zugreifbar sein.
Ok, ich habe PG5 komplett raus geschmissen und alles entsprechend angepasst...
(Danke Atmel für die Verwirrung)
DrDiettrich:
5. Darf und kann ich es so machen oder wird es so Probleme geben?
Kai Neahnung
Schade
DrDiettrich:
6. Ist "core" durch "variants" ersetzen erlaubt und brache ich den core Ordner überhaupt? (oder wie soll ich es machen?)
In "core" stehen allgemein gültige Dateien. Wenn dieser Ordner bei Dir fehlt, weiß ich auch nicht weiter.
Ansonsten gehört die pins_arduino.h in den zugehörigen Ordner unter "variants", also z.B. \variants\LCD.
Ja das war wahrscheinlich etwas zu ungenau formuliert.
Nick Lott hat bei seiner Anpassung für den ATmega169 einen "cores" Ordner dabei, in dem der Ordner "butterfly" ist (mit einigen Dateien darin).
In meinem Arduino Verzeichnis habe ich natürlich auch einen cores Ordner, der einen "arduino"-Ordner (statt butterfly) enthält.
Inwiefern sich der Inhalt bzw. die Funktion der Dateien unterscheidet überschreitet mein Wissen.
Ich weiß auch nicht wofür dieser Ordner genau benötigt wird.
Das Butterfly-Board ist ja ein eigenes (Atmel) Entwicklungsboard.
Ich benötige keine "Butterfly"-eigenen Funktionen sondern habe einen puren ATmega169PA.
Falls dieser Ordner also für hardwareseitige Besonderheiten des Boards ist und nicht zum verwenden des ATmegas169PA benötigt wird, dann käme mir das sehr recht.
DrDiettrich:
7. Sind die Fuse-Werte weiterhin korrekt durch das Ändern der Werte wie z.B. CPU-Takt? (Falls nein, wie müssen die aussehen?
Kai Neahnung
Das hat agmue ja quasi schon beantwortet.
Ich brauche also je nach Takt andere Fuse-Werte...
Man ist das Thema schwierig...
Jetzt muss ich noch den Zusammenhang zwischen externen Quarz und Takt mit dem der µC läuft verstehen um den Takt entsprechend anzupassen... (oder notfalls den internen quarz nehmen).
DrDiettrich:
8. Bezeichnung des "mcu" frei wählbar?
9. "protocol"-Name frei wählbar?
Vermutlich, vermutlich
Das klingt bedrohlich
DrDiettrich:
10. Warum ist dann dennoch häufig ein "L" hinter der Zahl angegeben?
Damit es ein "long" (32 Bit) Wert wird, nicht bei 8 oder 16 Bit abgeschnitten.
Danke!
DrDiettrich:
11. Wenn ich alles angepasst habe (und es auch stimmt), kann ich dann denn "bootloader" drauf brennen und ab dann zukünftig ganz "normal" über meinen USB<=>Serial Adaper andere Sketches über SS, SCK, MISO und MOSI drauf laden ohne den bootloader flashen/brennen zu müssen?
Eigentlich müßte jeder Chip schon mit Bootloader kommen. Ausprobieren schafft Klarheit
Bislang habe ich nur USART0 (Serial USB) zum Programmieren meiner Pro Mini verwendet, die Signale abgezapft vom ausgestöpselten Prozessor meines Uno. Serial USB dürfte mit SPI nicht funktionieren, andere Baustelle.
Ähmm... ja da wird auch irgendein Bootloader drauf sein, aber ich meine, dass über die Arduino IDE ein eigener "Arduino"-Bootloader geflasht wird, der dann eben z.B. die Funktion "einen Sketch hochladen" bereit stellt.
Also so wie ich es verstanden habe ist der Bootloader das "Bios der µC" und das ist beim Arduino doch etwas anders, damit auch Leute wie ich in den Genuss kommen einen µC programmieren zu können
DrDiettrich:
Ich danke euch, Serenyfly und DrDiettrich, wirklich tausendfach!Nana, nicht gleich so überschwenglich. Wenns dann doch nicht funktioniert, sind wir natürlich schuld, das kennen wir schon
Natürlich! Wer denn sonst? 
Zu den Interrupts habe ich mir mal den Uno angeschaut (variants\standard), und da werden die Pins für INT0 und INT1 auf 0 und 1 gemappt. Es sind also keine Vektor Nummern, sondern anscheinend die INTx Nummern.
Damit wäre die Zuordnung beim Mega für Pin 2 und 3 falsch (kopiert ohne Anpassung), und Deine Zuordnung (D20-->0) richtig.
Zur Taktung (Diagramm: Clock Distribution): Der Oszillator (clock source) hat Einfluß auf die Einschwingzeit, nach dem Prescaler auf die Baudraten und ADC Konvertierungszeit, Watchdog, und natürlich auch noch auf die Timer (PWM) und millis/micros(). Flash und EEPROM Schreiben geht wohl meist über den eingebauten Oszillator. Nach unten gibt es keine Grenze, die Controller arbeiten statisch.
Wie zwischen Controllern und Boards tatsächlich unterschieden wird, ist mir irgendwie schleierhaft. Eigentlich sollte doch eine einzige Tabelle für die logischen Pins auf Ports und Bits reichen, der Rest hängt ja nicht vom Board sondern vom Controller ab. Der Compiler muß die richtige (der vielen) pins_arduino.h (etc.?) auswählen, und das geht anscheinend über die Controller Auswahl, die das Verzeichnis mit den zugehörigen Spezialdateien angibt. Dazu gehören wohl auch noch globale #defines, die Einfluß auf Details in den Standard-Headern haben. Die Varianten sollten alle im Verzeichnis avr\variants liegen (gesucht/gefunden werden), wie da cores dazupaßt weiß ich nicht - sollte ja dem Namen nach eigentlich die verschiedenen Controller abdecken. Aber vielleicht war es zu aufwendig oder unsicher, etwaige Anpassungen an den 169 in die Dateien in cores einzuflicken (die gehen ja beim nächsten Update der IDE verloren), das würde dann den extra cores Ordner erklären.
Jetzt muß ich erst mal weg...
DrDiettrich:
Zu den Interrupts habe ich mir mal den Uno angeschaut (variants\standard), und da werden die Pins für INT0 und INT1 auf 0 und 1 gemappt. Es sind also keine Vektor Nummern, sondern anscheinend die INTx Nummern.
Nein! Das sind Arduino-spezifische Interrupt Nummern:
Tabelle unten
Auf dem Mega ist z.B. Pin 18, #5, aber auf dem Prozessor ist es INT3
Du meinst daß es nur Zufall ist, daß INT0-INT3 auf den Vektoren 2-5 (#2-#5) liegen?
Sereniflys Beitrag soll glaube ich nur meine Vermutung bestätigen, dass die Interrupts in der pins_arduino.h frei gewählt/vergeben werden können.
Ich habs auch erst zwei mal lesen müssen, weil es ein bisschen klingt nach "für das Arduino Mega ist das so vorgegeben, daher kommt die Nummerierung der Interrupts".
Das wäre dann aber von der flaschen Seite aus betrachtet, weil ja zuerste der µC und dann das Board drum herum kommt... Das "Nein!" war wohl eher auf deine Aussage bezogen, dass das beim Mega "falsch gemacht" wurde.
Es wäre doch sinnvoll den 32kHz Quarz als Taktgeber (low-frequency crystal) zu verwenden anstatt nur den internen Quarz oder?
Dann könnte man den µC auch mal schlafen legen und dadurch Energie sparen.
Außerdem sollte dann der Timer genauer laufen (wobei ich das mit dem Kalibrieren de nicht verstanden habe), da der Interne ja nicht sehr genau ist.
Allerdings fehlt mir dazu die Info im Datenblatt, mit welchem Takt ich den µC dann laufen lassen kann.
Der wird ja dann nicht auf 32kHz getaktet sein oder?
Darf ich den Takt dann in der boards.txt frei wählen oder wie? (nur beschränkt auf max. 8MHz durch die Spannung von max. 3V)
Das scheint mir unlaubwürdig, weil das bedeuten würde, dass der µC erst zur Laufzeit seinen Takt vorgegeben bekommt...
Meine CKSEL-Einstellungen wären mit 32kHz Quarz dann (wie auf S35. im Datenblatt)
"0111" und SUT "10".
Das ergibt dann "Start-up time from power-down and power-save": 32K CK mit "Additional delay from reset": 4CK + 65ms.
Zum Nutzen des internen Quarzes wäre dann CKSEL= 0010 mit SUT = 10, also 6CK + 65ms.
Was nehmen?
Der Sinn der Arduino Software ist ja, dass das ganze von den Prozessor-Eigenheiten unabhängig ist. Deshalb gibt es da für die Pins eigenen Nummern. Und gerade hier bestimmt man wie die Arduino Nummern zu den Prozessor Nummern zugeordnet sind.
Es wäre doch sinnvoll den 32kHz Quarz als Taktgeber (low-frequency crystal) zu verwenden anstatt nur den internen Quarz oder?
32kHz Quarze sind Uhrenquarze. Weil man dadurch durch einen Binärteiler einfach auf einen Sekundentakt kommt. Als Taktgeben für einen µC ist das viel zu langsam!
Aha, also wird selbst wenn ich den "low-frequency crystal" wähle, wird eigentlich der interne Quarz als Taktgeber verwendet und der 32kHz Quarz diehnt dann nur zum "freischalten" der low-power einstellungen?
Ich stolpere auch immer wieder über "Calibrated Internal RC Oscillator".
Heißt das ich muss wenn ich den 32kMh Quarz als Takt aktiviere, dass ich da erst was kalibrieren muss?
Ich verstehe das mit dem Quarz einfach nicht.
Da kenne ich mich nicht so aus
"Calibrated Internal RC Oscillator" ist genau was der Name sagt. Der interne RC Oszillator. Das kein Quarz! RC-Oszillatoren sind ungenau, weshalb man den über ein Register kalibrieren kann.
Anscheinend ist das Thema eine relativ graue Zone.
Wenn selbst du und DrDiettrich teilweise nicht mehr 100%ig weiter wissen...
Wie soll dann meiner einer das hin bekommen?
Vielleicht verirrt sich ja einer von den anderen Forum Gurus (uwe, schultewolter, Doc_Arduino, michael_x, combie, Eisebaer, jurs und sth77) hierher - wenn sie nicht eh schon heimlich mitlesen 
Anwendungsfall: ATmega169PA auf 3V (Batterie) mit 8MHz (und weniger)und 32kHz Quarz zum für "power-save"-Modus. Klingt eigentlich total simpel
Fraglich ist, ob ich mehr als die Anpassung der boards.txt, das Erstellen der pins_arduino.h im Ordner variants und eventuell noch einen Eintrag in der programmers.txt brauche.
Vom butterfly exisiert ja ein "cores" und ein "bootloaders"-Ordner (Quelle), allerdings weiß ich nicht, ob ich die Arbeit bereits mit der pins_arduino.h erledigt habe und ob vielleicht sogar in einem der beiden Ordner etwas definiert ist, was butterfly spezifisch ist und bei mir etwas schaltet, was nicht sein darf (z.B. CLKO) oder meine Pins überschreibt.
Schon krass, dass in der sonst so voller Tutorials strotzenden Arduino-Welt hierzu kaum was zu finden ist.
(Dies, das und jenes ist schon alles was einigermaßen nennenswert ist).
Sollte bei mir etwas anderes als Elektroschrott rauskommen, werd ich mich dem vielleicht mal im April annehmen und was dazu schreiben - vielleicht hilft es ja auch anderen dummies...
Bis dahin hoffe ich auf weiterhin so großartige Unterstützung - die wirklich keinesfalls selbstverständlich ist.
Liebe Grüße!
Leon333:
Ich verstehe das mit dem Quarz einfach nicht.
Ich schließe mal von einem ATtiny85 auf den ATmega169PA, ohne zu wissen, ob das Sinn macht: Entweder läuft der interne RC Oszillator oder der externe Quarz, nicht beide zusammen. Alle meine ATtinys verwende ich ohne externen Quarz und wähle in der IDE "ATtiny 85 @ 1 MHz" oder "ATtiny 85 @ 8 MHz", was dann mit den Fuses (in der IDE Bootloader brennen) übertragen wird.
DrDiettrich:
Eigentlich müßte jeder Chip schon mit Bootloader kommen. Ausprobieren schafft Klarheit
Da einige Firmen damit werben, ihr IC würde mit Bootloader geliefert werden, was sicher den Preis erhöht, sollte im Umkehrschluß gelten, nicht jeder Prozessor wird mit Bootloader geliefert.
DrDiettrich:
11. Wenn ich alles angepasst habe (und es auch stimmt), kann ich dann denn "bootloader" drauf brennen und ab dann zukünftig ganz "normal" über meinen USB<=>Serial Adaper andere Sketches über SS, SCK, MISO und MOSI drauf laden ohne den bootloader flashen/brennen zu müssen?
SS, SCK, MISO und MOSI bringe ich mit ICSP (beim UNO die sechs Stifte neben dem Reset-Knopf) oder SPI in Verbindung. ICSP wird zum Flashen ohne Bootloader verwendet, entweder zum Übertragen des Bootloaders oder des Sketches. USB geht dann an die serielle Schnittstelle, also RxD und TxD (ggf. als Nullmodem wie beim ProMini).
Alle Angaben als Denkanstoß ausdrücklich ohne Gewähr
Ja das mit dem ATiny85 ergibt auch Sinn.
Da wird dann wahrscheinlich nur der CKDIV8 aktiviert oder deaktiviert, wass dann 1 bzw. 8MHz macht.
Das mit dem "Entweder läuft der interner RC Oszillator oder der externe Quarz" kann so nicht stimmen.
Sonst würde diese Tabelle keinen Sinn ergeben:
| Device clocking option | CKSEL3..0 |
|---|---|
| External XTAL/ceramic resonator | 1111 - 1000 |
| External low-frequency XTAL | 0111 - 0110 |
| Calibrated internal RC oscillator | 0010 |
| External clock | 0000 |
| Reserved | 0011, 0001, 0101, 0100 |
Beim setzen von CKSEL 0111 - 0110 MUSS der Interne RC Oszillator als Taktgeber genutzt werden, denn die 32kHz sind ja bei weitem nicht ausreichend (und ich bin immernoch nicht dahinter gekommen, was für nen Vorteil dieser "Betriebsmodus" hat).
Und so wie du es beschreibst mit dem ICSP hatte ich es auch gehofft.
Also über die SS, SCK, MISO und MOSI Pins zuerst den Arduino Bootloader drauf flashen (da ist aktuell schon ein Bootloader drauf, da ich aus einem vorhandenen System/Schaltung die Kontrolle über den µC übernehmen will).
Das heißt ich will mich zuerst des µC bemächtigen und dann fröhlich (wenn ich da bin, bin ich wirklich fröhlich) Sketches über ICSP drauf laden will...
Irgendwelche Einwände?
Zum Strom sparen kann man den Controller schlafen legen, wenn er nichts zu tun hat, und über Interrupts wieder aufwecken. Im Standby kann man ja auf Ströme im Bereich der Selbstentladung der Batterie kommen.
Wenn er wach ist, soll er mindestens so schnell laufen wie notwendig, um alle anstehenden Aufgaben zu erledigen.
Bei 32kHz dürfte da nicht viel übrigbleiben, außer vielleicht für einen Wecker (Anzeige multiplexen, Uhrzeit und Weckzeit einstellen, Weckton erzeugen, auf Abstellen warten...). Oder für Überwachungsaufgaben (Rauchmelder...), bei denen es auf ein paar Sekunden Reaktionszeit nicht ankommt. Ob es für eine Waage reicht, die ja auch nur selten was zu tun bekommt, bliebe auszuprobieren. Wenn der Benutzer vor Erschöpfung runterfällt, bevor die Anzeige kommt, findet sowas sicher keinen großen Anklang
Im Datenblatt vom ATmega328 im Abschnitt 9.5 steht: "The Low-frequency Crystal Oscillator is optimized for use with a 32.768kHz watch crystal."
Leon333:
und ich bin immernoch nicht dahinter gekommen, was für nen Vorteil dieser "Betriebsmodus" hat
Das stand schon weiter oben: Es ist ein Uhrenquarz. Weil 32768 eine Zweierpotenz ist, kommt man durch Teilen schön auf 1 Hz.
Leon333:
Das mit dem "Entweder läuft der interner RC Oszillator oder der externe Quarz" kann so nicht stimmen.
In 9.6 Calibrated Internal RC Oscillator steht: "If selected, it will operate with no external components." Ich kann aber auch nicht ausschließen, daß bei einem externen Quarz der interne Oszillator mitläuft.
EDIT: Da gehen ein paar Linien am Multiplexer vorbei, die hatte ich übersehen.
Wenn man das Diagramm 11 ansieht, dann gibt es darin neben dem RC Oszillator auch noch einen Watchdog Oszillator und Timer/Counter(+LCD) Oszillator. Die dürften zumindest immer dann mitlaufen, wenn der CPU Takt zu langsam wird, um EEPROM und Flash Schreibzyklen, USART Baudrate und ggf. ADC am Laufen zu halten.
Ich würde davon ausgehen, daß der Betrieb all dieser Oszillatoren nicht dokumentiert ist, weil der Programmierer daran nichts ändern kann (und darf). Z.B. war ich etwas verwundert, daß beim Pro Mini die Baudrate von der Versorgungsspannung abhängt, also anscheinend bei 3,3V die Taktfrequenz automatisch halbiert wird. Ob das nur für die Baudrate gilt, oder für den ganzen Prozessor, habe ich nicht ausprobiert. Die AVR Clock Control Unit ist einfach eine große Blackbox, mit einigen wenigen dokumentierten und einstellbaren Features. Dazu kommt dann noch, was die Standardbibliothek ggf. daran herumfummelt, ob die vielleicht auch an der Umschaltung entsprechend der Versorgungsspannung schuld ist.
Also dass eröffnet mir jetzt eine völlig neue Sicht, wenn der "low-frequency crystal" wirklich den Chip auf nur 32kHz runter taktet.
Ich hatte gedacht, dass der Uhrenquarz lediglich dazu dient das der µC damit einen Abgleich macht um die reale Zeit "im Auge zu behalten".
Sozusagen, dass der Interne RC Oszillator den Arbeitstakt bestimmt, aber der Uhrenquarz dafür sorgt, dass der µC möglichst genau die Sekunden zählen kann.
Sozusagen als "Dualmodus" mit einstellbarem Takt bis 8MHz und mit Echtzeitabgleich - und falls notwendig mit "energy-save-mode" um in einen "halbwachen Zustand" auf 32kHz zu fallen.
Das ist aber anscheinend zu viel "interpretiert" und falsch.
Nur damit ihr es wisst: Das ist der erste µC mit dem ich mich wirklich beschäftige. Dementsprechend schwierig ist das lesen des Datenblattes für mich.
Also: "low-frequency crystal"-mode = 32kHz Chiptakt. Check.
Mir ist gerade aufgefallen, dass ich vor lauter Fokus auf Integieren des µC in die Arduino IDE noch recht wenig über das System und die Schaltung gesagt habe.
Der ATmega169PA wird in einem Easy Home Heizkörperregler verwendet mit dem ich aber nur sehr bedingt zufrieden bin (und daher selber besser machen will).
Ich hab im Anhang mal ein Bild des Boards gepackt (zum Teil beschriftet).
Links ist eine IR Diode plus Dekoder, die in das Getriebe schauen und die Anzahl der Umdrehungen des Motors mitzählen. Oben der Anschluss neben der pseudo USB Buchse (hatte anfangs gehofft, dass ich darüber wie ein Arduino flashen kann, aber Pustekuchen) ist für den Motor, der über ein einfache H brücke bestromt wird.
In der Mite rechts ist noch ein Inkrementalgeber für ein Steuerrad mit der der Nutzer was einstellen kann.
Auf der Rückseite ist dann der ATmega169PA und ein LCD Display.
Jetzt bleibt nur die Frage offen, wozu die den 32kHz Quarz verwenden...
Theoretisch wäre es möglich (so selten wie das Teil auf Eingaben reagiert), dass die den µC tatsächlich nur auf 32kHz takten...
Kann ich denn den Uhrenquarz irgendwie dafür nutzen, mir die korrekte Zeit zu errechnen und damit den LCD anzusteuern? Dann wäre der nicht komplett unnütz
(Sorry ich hatte den Beitrag schon um 10:00 fertig, aber hab vergessen auf "Post" zu drücken... )
Leon333:
Sozusagen, dass der Interne RC Oszillator den Arbeitstakt bestimmt, aber der Uhrenquarz dafür sorgt, dass der µC möglichst genau die Sekunden zählen kann.
Kann man auch machen. Dafür ist aber Timer2 da. Der hat einen speziellen Modus wo man so einen Quarz anschließen kann und damit den µC praktisch als RTC verwenden kann. Das hat aber mit dem eigentlichen µC Takt überhaupt nichts zu tun.