Vielleicht interessiert es den einen oder anderen: "The AVR128DA28/32/48/64 microcontrollers of the AVR® DA family are ... running at up to 24 MHz", so steht es im Datenblatt, und zwar ab 1.8 V. Da sollte doch bei höherer Spannung etwas mehr möglich sein, zumal ja schon lange bei den ATxmega 32 MHz zulässig waren. Im Datenblatt steht bei CLKCTRL_OSCHFCTRLA für FRQSEL oberhalb 0x9 (für 24 MHz) "Other - Reserved" - nun, bei meinen AVR128DA28 kann ich auch 0xA sowie 0xB einstellen, was zu 28 bzw. 32 MHz führt.
Sicher kannst Du das, aber es ist nicht gesagt, dass das über den gesamten Temperatur- und Spannungsbereich und mit jedem Chip funktioniert. Es gibt genug Controller, die mit 80, 120 oder noch mehr MHz laufen. Pfuschen müssen da nur die Leute, die sich nicht in andere Architekturen einarbeiten können. fchk
S. Landolt schrieb: > Vielleicht interessiert es den einen oder anderen: > "The AVR128DA28/32/48/64 microcontrollers of the AVR® DA family are ... > running at up to 24 MHz", so steht es im Datenblatt, und zwar ab 1.8 V. > Da sollte doch bei höherer Spannung etwas mehr möglich sein, zumal ja > schon lange bei den ATxmega 32 MHz zulässig waren. > Im Datenblatt steht bei CLKCTRL_OSCHFCTRLA für FRQSEL oberhalb 0x9 > (für 24 MHz) "Other - Reserved" - nun, bei meinen AVR128DA28 kann ich > auch 0xA sowie 0xB einstellen, was zu 28 bzw. 32 MHz führt. Mich interessiert das. Allerdings ist schon klar, dass keine Wunder zu erwarten sind. Übertakten per Überspannung kann bei den AVR128DA prinzipbedingt nicht funktionieren. Ihren breiten Spannungbereich beziehen sie nämlich einzig daraus, dass der MCU-Core und weite Teile der Peripherie aus einem eingebauten DCDC-Wandler (grundsätzlich nach dem Ladungspumpen-Prinzip, aber ziemlich clever gestrickte Abwandlung davon) betrieben werden. D.h.: es ist fast scheißegal, welche Spannung du außen anlegst, alles taktkritische bekommt immer dieselbe Spannung zum Betrieb. Allerdings ist eine 33%ige Übertaktung ohne sofort offensichtlichen Crash bei eben dieser effektiv festen Spannung im Minimum ein gutes Zeichen. Die haben offensichtlich ihren Prozess einigermaßen im Griff und reichlich Sicherheit gelassen. 16,7%, also die 28Mhz könnte man also für reine Hobbylösungen wohl akzeptieren. Es ist anzunehmen, das in Zukunft schneller spezifizierte Varianten erscheinen werden. So der Markt will, den sowas entscheiden leider nicht die Techniker, sondern die Marketing-Fuzzies...
> ... eingebauten DCDC-Wandler ...
Deshalb steht wohl auch im aktuellen Datenblatt (das noch immer
'preliminary' ist, ohne 'Typical Characteristics' - ich glaub's ja
nicht) für den 'primary decoupling capacitor' 1 uF statt wie vorher 100
nF.
S. Landolt schrieb: > bei meinen AVR128DA28 kann ich > auch 0xA sowie 0xB einstellen, was zu 28 bzw. 32 MHz führt. Erinnert mich an so manche Motorradfahrer die ein Motorrad mit 50 PS haben und einen irren finanziellen Aufwand treiben um es auf 52 oder 53 PS zu bringen.
Beitrag #6426095 wurde von einem Moderator gelöscht.
Vorab: OT, gehen sie weiter, hier gibt es nichts relevantes zu sehen. jo mei schrieb: > Erinnert mich an so manche Motorradfahrer die ein Motorrad > mit 50 PS haben und einen irren finanziellen Aufwand treiben > um es auf 52 oder 53 PS zu bringen. Moby schrieb im Beitrag #6426095: > Was willst Du. Das eine ist kostenlos, das andere nicht. Das dachte ich auch. Was hat das setzen eines Steuerregisters auf undokumentierte Werte mit dem finanziellen Aufwand für das Tuning eines Saug-Motors gemeinsam? Das klingt wie der Vorschlag, einen Neuwagen zu kaufen, weil man bei 'nem Oldtimer aus Neugier bestimmte Infos abgreifen und anzeigen lassen will...
Bei meinen AVR128DA48 Curiosity Nano zu mindest funktioniert das auch. Finde ich cool, ich habe da ein Hobby Projekt wo etwas mehr Rechenpower ganz praktisch ist. Nicht falsch verstehen, das Projekt funktioniert auch bei 24MHz wunderbar (es funktioniert auch bei der alten Version mit dem Atmega1248P mit 20Mhz bestens).
Im Datenblatt der AVR128DB-Serie lugen die 32 MHz an manchen Stellen hervor, aber meist wird betont, dass 24 das Maximum für den Systemtakt darstellen.
Frank K. schrieb: > Sicher kannst Du das, aber es ist nicht gesagt, dass das über den > gesamten Temperatur- und Spannungsbereich und mit jedem Chip > funktioniert. > > Es gibt genug Controller, die mit 80, 120 oder noch mehr MHz laufen. > Pfuschen müssen da nur die Leute, die sich nicht in andere Architekturen > einarbeiten können. > > fchk Das ist (D)eine Sicht. Man kann aber auch Dinge damit tun ohne eine Basis Hardware großartig ändern zu müssen. Plötzlich kann man z.B. Impulse messen, ohne die nächste Plattform aufzumachen....
Und noch CLKCTRL_OSCHFTUNE = 0x1F gesetzt und jetzt rast er mit 36MHz. Das werde ich aber eher weniger nutzen, das war nur mal so zum testen desn CLKCTRL_OSCHFTUNE registers. Oder auf -0x15 dann läuft er exakt mit 30Mhz. Aber das sind alles nur Spielereien. Was mich interessiert, ist SPI wirklich auf die 10MHz beschränkt die im Datenblatt angegeben sind oder läuft SPI auch mit höherer Taktrate noch zuverlässig? Etwa wenn man bei den legalen 24MHz bleibt, kann man den SPI dann nicht mehr mit 12MHz betreiben?
an Peter S.: Eine höhere Instanz als das Datenblatt werden Sie nicht finden. Für das eigene Urteil gilt: selbst ausprobieren&prüfen. Falls Sie aber an fremden Erfahrungen interessiert sind (eigene sind besser): a) seit Jahren betreibe ich einen ATmega1284P mit 24 MHz und SPI sowie USART-SPI mit dem halben Takt. b) seit einiger Zeit läuft ein AVR128DA28 mit 43 MHz, u.a. USART sowie TCBs im 32-bit-Modus bei 'Input Capture on Event mode' sowie 'Input Capture Frequency and Pulse-Width Measurement mode'. Für SPI hatte ich hier noch keine Anwendung. Beides allerdings, wie bei Ihnen, Hobbyprojekte.
PS: Ist aber ein Stück weit Nervensache - bei jeder zweiten nicht auf Anhieb funktionierenden Programmerweiterung fragt man sich: liegt's am Übertakten? Humor hilft.
Ja ich dachte da eher an Erfahrung von anderen Hobbybastlern. Mit ATmega1284P und übertakten habe ich bis jetzt auch nie Probleme gehabt. Die scheinen ziemlich robust zu sein. Dann werde ich mal den SPI Test mit meinem Curiosity auf den nächsten Bastelabend legen müssen. Im Moment hangle ich mich mit Beispielen durch alle Funktionen das AVR128DA48 und ich muss sagen ich finde diese AVR Familie toll. AVR128DA28 mit 43MHz, d.h. da gehen auch die höheren Wert für CLKCTRL_OSCHFCTRLA, das muss ich gleich mal ausprobieren :-)
> ... alle Funktionen das AVR128DA48 ...
Mir scheint, dass Microchip diese nur als eine Art Vorserie für die
AVR128DB ansieht. Aber viel Neues kommt nicht hinzu, die erlangten
Kenntnisse sind also eine gute Grundlage für einen eventuell späteren
Wechsel.
(Ich hoffe allerdings, dass nicht in drei Monaten eine DC-Serie
angekündigt wird)
S. Landolt schrieb: > Ich hoffe allerdings, dass nicht in drei Monaten eine DC-Serie > angekündigt wird Laut 'SpenceKonde' ist zumindestens etwas über eine DD Serie im Busch. Soll jedoch maximal nur 32Pins haben. Daher erstmal keine Gefahr für einen noch größeren Brummer im Vergleich zur DB Serie. :-)
Da gibt es doch ein paar gröbere Unterschiede von DA zu DB. Ich denke beide bleiben. Der Port mit anderen Pegel ist zwar interessant aber warum haben sie nicht auch ein parallel port interface gemacht wie das einige PICs haben? Der Oszillator mit externem Takt ( die 32Mhz lassen grüssen) hatte ich zwar zu Beginn beim DA vermisst aber nur ganz kurz. Ich bin mal gespannt wenn es diese ohne die bekannten Fehler gibt und hoffe dass avrasm2 angepasst wird, mindestens den Core V4S sollte er kennen ond eine gemappte Read-only section wäre ganz praktisch.
> ... beide bleiben ... Es ist offenbar schwierig, bei dieser Flut von Varianten den Überblick zu behalten; in einer E-Mail vom Samstagabend teilt mir Microchip mit, sie hätten festgestellt, dass der voraussichtliche Liefertermin (der vierte mir genannte seit der Bestellung Mitte Oktober) nicht eingehalten wurde, sie würden der Sache nachgehen und sich wieder melden, sie entschuldigten sich vielmals. (so viel zum Thema 'mehr Ruhe', J.W.) > avrasm2 ... den Core V4S sollte er kennen Diese Warnung störte mich auch etwas, aber eigentlich kann ich damit leben.
Frank K. schrieb: > Es gibt genug Controller, die mit 80, 120 oder noch mehr MHz laufen. Oftmals ist auch eine Überschreitung der Datenblattangaben total unnötig und eine bessere Planung des Programmablaufs völlig ausreichend. Es gibt fast immer Programmteile, die unnötig oft neu berechnet werden. Das zu schnelle Rechnen kann sogar Nachteile haben, z.B. bei zu häufiger Temperaturmessung kann die Eigenerwärmung des Sensors die Messung verfälschen.
Ich habe jetzt ein bisschen mit SPI herumgespielt. SPI_CLK2X bei 24MHz macht keine Probleme, d.h. SPI funktioniert auch bei 12MHz, war ja auch zu erwarten. Bei 16MHz zickt das ganze, könnte natürlich auch an meinem Suboptimalen Setup liegen, mit Spannungsteiler statt Pegelkonverter. Ist aber völlig unwichtig. Ich will ja am Schluss bei 24MHz CPU Takt bleiben. Was mir hingegen negativ aufgefallen ist bei SPI ist folgender Hinweis im Datenblatt Alternatively, the IF can be cleared by first reading the SPIn.INTFLAGS register when IF is set, and then accessing the SPIn.DATA register. Und in der Tat, ich musste jedesmal SPI0_INTFLAGS lesen und danach SPI0_DATA sonst hatte ich immer weider Probleme. D.h. aber auch der Trick den man früher benutzen konnte in dem man eine Zyklus genaue Read Routine schrieb (die genau 16 Zyklen pro Byte benötigte) funktioniert hier nicht mehr. Es sind jetzt mindestens 17 Zyklen pro byte (lds braucht ja 3 Zyklus beim AVR128DA). Ich muss mal schauen ob man da ein Overlap einbauen kann (d.h. zuerst SPI0_DATA auslesen um das aktuelle Byte auszulesen und dann SPI0_INTFLAGS exakt 16 Zyklen nach dem schreiben des SPI0_DATA auslesen das den Transfer anstösst). Ist eh unwichtig, da ich wegen der CRC Berechnung mein Loop mindestens 18 Zyklen braucht.
:
Bearbeitet durch User
S. Landolt schrieb: > avrasm2 ... den Core V4S sollte er kennen > > Diese Warnung störte mich auch etwas, aber eigentlich kann ich damit > leben. Erübrigt sich mit der neuen Version im Microchip Studio.
an Peter S.: > Spannungsteiler ... Pegelkonverter Ist das noch nötig, der uC läuft ja bis 1.8 Volt hinunter? Auf jeden Fall sollte dann die DB-Serie einen Fortschritt bringen mit dem 'MVIO - Multi-Voltage I/O'. > Zyklus genaue Read Routine Wenn Sie ohnehin taktgenau arbeiten, ist dann das SPI-IF überhaupt von Interesse?
Für die Tests die ich im Moment mache wären eigentlich 5V nicht nötig aber bei der eigentlichen Anwendung wird der Rest der Schaltung mit 5V betrieben. Dann habe ich aber auch richtige Pegelkonverter für die SD-Card vorgesehen. Die DB Serie wäre sicher eine gute Lösung, dann könnte ich den SPI vom PORTC verwenden. Im Moment habe ich einfach keinen zur Hand. SPI funktioniert bei mir nur wenn ich SPI0_INTFLAGS auslese und danach SPI0_DATA, das SPI_IF Flag schaue ich aber gar nicht an. Ich muss das Timing nochmals minuziös analysieren, einige Instruktionen haben andere Zykluszeiten als der Atmega1284P auf dem das bis jetzt lief. Vielleicht habe ich mich auch einfach verrechnet oder etwas übersehen.
Wie ist denn die Genauigkeit bei 28/32MHz. Immer noch ausreichend für etwa einen UART-Betrieb?
an Wilhelm M.:
1 | 20 24 28 32 MHz |
2 | AVR128DB28: 19.96 23.94 27.95 31.96 |
3 | AVR128DA28: 19.98 23.98 27.97 31.98 |
Konditionierung per 32 KiHz-Quarz habe ich nicht ausprobiert.
Für UART Betrieb (8-bit no parity) reicht die Genauigkeit auch bei den nicht "dokumentierten" 32MHz. Das SPI Verhalten konnte ich weiter eingrenzen. Es liegt nicht daran, dass man SPI0_INTFLAGS lesen muss, es liegt daran, dass man mit SPI nicht so schnell hintereinander bytes empfangen kann wie beim Atmega1284P, bei maximalem SPI Clock (12MHz) muss der Zyklus mindestens 20 CPU Clocks lang sein, darunter gibt es Datensalat. Beim Atmega1248P geht es nahtlos.
PS: Oder allgemein gefragt, wie sieht Ihre Testanordnung aus? Programm(e) vorstellen wäre prima. Ich wollte ohnehin mal SPI sowie USART-SPI auf den AVR-Dx ausprobieren, da würde das jetzt passen. Geht aber alles nicht so schnell bei mir.
Peter S. schrieb: > Das SPI Verhalten konnte ich weiter eingrenzen. Es liegt nicht daran, > dass man SPI0_INTFLAGS lesen muss, es liegt daran, dass man mit SPI > nicht so schnell hintereinander bytes empfangen kann wie beim > Atmega1284P, bei maximalem SPI Clock (12MHz) muss der Zyklus mindestens > 20 CPU Clocks lang sein, darunter gibt es Datensalat. Beim Atmega1248P > geht es nahtlos. Ähem, über welches SPI redest du hier? Das native oder UART im SPI-Mode? Falls native: Nein, das konnte noch nie "nahtlos", sondern hat auch als Master schon immer mindestens einen Extra-Tick benötigt. Nahtlos ging es (dank double buffer) nur mit den USARTs im SPI-Mode. Wenn das für die nun tatsächlich so sein sollte, wie du beschreibst (kann ich mangels bisheriger eigener Versuche in dieser Richtung weder bestätigen noch widerlegen), dann wäre das definitiv ein BUG, da nicht so dokumentiert.
Ich verwende SPI, nicht der UART im SPI Mode und ja als Master um SD-Karten zu lesen. Da wollte ich die Blöcke so schnell wie möglich transferieren. Wobei, da lese ich gerade, der SPI unterstützt neu Buffering, das werde ich dann mal ausprobieren.
Veit D. schrieb: > Laut 'SpenceKonde' ist zumindestens etwas über eine DD Serie im Busch. > Soll jedoch maximal nur 32Pins haben. Daher erstmal keine Gefahr für > einen noch größeren Brummer im Vergleich zur DB Serie. :-) Dazu gibt es von MicroChip ein Prelim.DB. Soll wohl die Series nach unten abrunden.
Noch bastle ich an der SPI Routine um Blöcke von und zur SD-Karte zu lesen und schreiben. Wobei basteln meint, ausprobieren welche bits man lesen muss und wie schnell es maximal geht. Unter 18 CPU Zyklen pro byte bin ich aber noch nicht gekommen. In der Zwischenzeit hat ein AVR128DB den Weg in den Hobbykeller gefunden und dort natürlich gleich begonnen das mit dem Übertakten auszuprobieren. Lustigerweise kann man für FRQSEL alle Werte schreiben also von 0..F aber nur die Werte 0xA und 0xB führen zu höheren Taktrate von 28MHz und 32MHz, danach geht es wieder runter. Ich wollte es einfach wissen. Im Moment läuft er wieder mit 16MHz am externen Quartz.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.