Hallo zusammen, ich möchte von bisherigen Projekten mit Atmel AVR auf AT SAM C21 umsteigen. Die Taktgenerierung des AVR war sehr einfach gestaltet. Entweder interner RC Oszillator, externer Takt oder externer Oszillator. Dann einen internen Teiler und fertig war die CPU Clock. Leider musste man sich dabei nach den weiteren Anforderungen, insbesondere gewünschte UART und SPI Clocks richten, die man daraus generieren wollte. Hier ist der SAM C bzw. SAM D wesentlich flexibler mit seinen vielen Taktquellen, Prescalern, Multiplexern und besonders den FDPLLs, über die sich jeder Bus und jede Systemkomponente flexibel mit verschiedenen Takten versorgen und synchronisieren lässt. Was mir aus Datenblättern, Google und SuFu nicht klar geworden ist: - Gibt es Limitierungen, die ich bei dem Systemdesign beachten sollte? - Nach welchen Kriterien sollte ich die eingesetzten Quartze auswählen? - Betreibt man die 48 MHz CPU-Frequenz wirklich am besten per FDPLL aus einem 32 kHz Uhrenquartz? - Wozu dann der "schnellere" Quartzeingang mit "0,4 .. 32 MHz"? - Kann man durch Skalierung jeden internen Takt aus jedem externen Takt gewinnen? - Ist der interne Takt stabiler jitterfreier sonst irgendwie besser, wenn er aus einem 16 MHz oder 32 MHz Quartz generiert wird? - Macht es Sinn, die CPU mit einem "ungenauen" internen Oszillator zu betreiben und zeitkritische Peripherie (CAN, UART, RTC) aus einem Quartz zu betreiben? - Kann man einen CAN HS (125 kbit/s oder 500 kbit/s) auch mit einem Uhrenquartz stabil betreiben? Ich finde dazu keine Hinweise im Datenblatt. Wäre dankbar für Hinweise, wie ich das umfangreiche Taktsystem in den Griff bekomme, ohne dumme Anfängerfehler zu machen. Mir ist bewusst, dass ich sinnvollerweise mit einem Eval Board spielen sollte, deshalb habe ich bereits ein Sammy C21 bestellt. Gruß Thomas
Thomas S. schrieb: > - Betreibt man die 48 MHz CPU-Frequenz wirklich am besten per FDPLL aus > einem 32 kHz Uhrenquartz? Geht das beim Atmel? Würde mich interessieren. Bei dem STM32 können die Low Frequency Oszillatoren nicht mit der PLL verbunden werden. Ich vermute, weil der interne (analoge?) PLL Loop Filter eine viel zu kurze Zeitkonstante hat. Die dafür notwendige große Zeitkonstante ist gar nicht auf dem chip integrierbar, sondern würde einen externen Kondensator benötigen.
ohne weitere kentnisse über den chip: es ist üblich quarze im bereich einiger MHz zu wählen, wie beim AVR, deren ganzzahlige vielfache der maximal/gewünschten frequenz entsprechen. in diesem fall würde sich 12 anbieten. 12 x 4 = 48 16x3 = 48 8x6 = 48 also nimm also den günstiges oder schon vorhandene, alles andere kannst du einstellen.
Ich benutze einen 16MHz Quarz an dem ATSAMC21. Warum? Weil ich NX3225GB sowieso schon als "Standard" Quarz rumliegen hatte, der ATSAMC21 mit denen funktioniert und mir das etwas zu seltsam vorkam den Takt aus einem Uhrenquarz hoch zu ziehen. Inbesondere weil ich den ATSAMC21 nur für CAN-FD überhaupt haben wollte und das hat bei 2MBit doch ein wenig höhere Anforderungen an den Takt. Also einfach mal ausprobieren, das Sammy Board hat ja auch gleich beide Optionen zur Verfügung. Was an der FDPLL96M etwas blöd ist, die verträgt nur bis 2MHz Eingangs-Takt. Aber 2MHz Quarze sind etwas unpraktisch groß. Da ich mit dem Atmel START rumgespielt habe und das in der Richtung etwas beschränkt, um nicht zu sagen verbugt ist, war meine erste Idee, den Takt über GCLK1 runter zu teilen, in die PLL zu füttern und als 48MHz in GCLK0 für den Core zu füttern. Zum Glück hat die PLL aber einen Takt pre-scaler (OSCCTRL_DPLLCTRLB_DIV) und man kann entsprechend auch mehr als 2MHz direkt verwenden. Beim E51 ist das übrigens exakt das gleiche Spiel und auch der läuft mit genau dem gleichen 16MHz Quarz einwandfrei. Die CAN-Unit takte ich übrigens mit den 48MHz aus dem GCLK0, sehr viel niedriger darf man da auch nicht ansetzen, weil sonst die Time-Quanten zu niedrig werden.
Martin B. schrieb: >> - Betreibt man die 48 MHz CPU-Frequenz wirklich am besten per FDPLL aus >> einem 32 kHz Uhrenquartz? > > Geht das beim Atmel? Würde mich interessieren. Ja, geht. Eingangsfrequenzbereich ist 32 kHz bis 2 MHz. Rudolph R. schrieb: > Was an der FDPLL96M etwas blöd ist, die verträgt nur bis 2MHz > Eingangs-Takt. > Aber 2MHz Quarze sind etwas unpraktisch groß. Daher ist der Betrieb mit dem 32-kHz-Quarz keine so schlechte Idee. Diese sind aufgrund ihrer Stimmgabel-Konstruktion dann wieder vergleichsweise klein.
Habe es gefunden. Geht beim Atmel. Senkt natürlich den Stromverbrauch. Die high Speed Quartz Oszillatoren schlucken das eine oder andere milli Ampere. Wäre ein Argument. Mit Einschwingzeiten beim startup musst Du aber rechnen. Die Uhrenquartze brauchen da etwas, bis sie stabil sind.
Danke für die vielen Antworten, wir nähern uns der Sache :) Der Uhrenquartz ginge also und spart Strom, braucht aber Zeit zum stabilisieren. Rudolph schreibt von „höheren Anforderungen“ an den Takt bei CAN FD. Hätte es denn Vorteile (Jitter?), einen schnelleren Quartz zu verwenden? Sehe ich das richtig, dass Quartze über 2 MHz zwar unterstützt, aber ohnehin erstmal herunterskaliert werden und somit technisch die 2 MHz das Optimum wären (abgesehen von dem Fall, dass man für einen Zähler oder einen SERCOM den Takt direkt verwenden möchte)? Das einzige Problem ist wohl, dass es im 2 MHz Bereich praktisch nichts im SMD-Package gibt, wenn ich das richtig sehe. Gibt es eigentlich die vom AVR bekannte Limitierung, dass man bei Verwendung eines UART einen Baudratenquartz verwenden sollte, beim SAM noch? Oder bekommt man da jeden Takt so hinskaliert, dass das unkritisch ist? Wäre es mit einem Baudratenquartz möglich, per PLL die 48M zu generieren oder braucht man da runde Multiplikatoren? Nochmal ganz ketzerisch gefragt: Ich sehe einige Evalboards einen 16 MHz Quartz verwenden. Gibt es einen Grund, das zu tun, außer dass man damit noch den Schrank voll hat? 8 MHz sind in den gleichen Packages verfügbar und haben in dem Design eigentlich keine Nachteile, oder doch?
:
Bearbeitet durch User
Martin B. schrieb: > Mit Einschwingzeiten beim startup musst Du aber rechnen. Mehrere hundert Millisekunden sind normal. Daher sollte man den auch während der Schlafzeit durchlaufen lassen. (Kann sein, dass das beim SAMCxx sowieso gar nicht anders geht.) Thomas S. schrieb: > Gibt es eigentlich die vom AVR bekannte Limitierung, dass man bei > Verwendung eines UART einen Baudratenquartz verwenden sollte, beim SAM > noch? Der Baudratengenerator beherrscht dort fractional N division, aber dafür braucht es auch 'ne Weile, ihn zu verstehen. ;-) Außerdem hast du natürlich schon durch den höheren Master clock mehr Freizügigkeiten.
Jörg W. schrieb: > Martin B. schrieb: >> Mit Einschwingzeiten beim startup musst Du aber rechnen. > > Mehrere hundert Millisekunden [...] Die Frage kam mir eben auch noch. Danke für die Klarstellung, das ist natürlich sehr lange. Da lohnt es sich ja fast, den zweiten Taktgeber nur zum Überbrücken der Anschwingzeit mit zu bestücken. > Thomas S. schrieb: >> Gibt es eigentlich die vom AVR bekannte Limitierung, dass man bei >> Verwendung eines UART einen Baudratenquartz verwenden sollte, beim SAM >> noch? > > Der Baudratengenerator beherrscht dort fractional N division, Stimmt, hast ja Recht. Das hatte ich auch schon irgendwo gelesen, aber wieder vergessen. > aber dafür > braucht es auch 'ne Weile, ihn zu verstehen. ;-) Außerdem hast du > natürlich schon durch den höheren Master clock mehr Freizügigkeiten. Designfreiheit vs. Lernkurve - ein Konzept, das beim SAM sehr konsequent umgesetzt wurde ;-). Empfinde ich aber nicht mal negativ. Ich will ja den SAM verwenden, gerade weil ich mit dem Mega in Grenzen laufe. Besonders hat es mir das ganze Thema DMA angetan, womit endlich nicht mehr jedes CAN Frame oder SPI Byte einzeln aus dem Register in den SRAM geklingelt werden muss. Natürlich bringt das in der Konfiguration dann auch etwas Komplexität mit sich - da muss ich wohl durch...
Thomas S. schrieb: > Rudolph schreibt von „höheren Anforderungen“ an den Takt bei CAN FD. > Hätte es denn Vorteile (Jitter?), einen schnelleren Quartz zu verwenden? Jitter ist eine Sache, die absolute Frequenz ist da aber interessanter. Wenn ich mich jetzt nicht verrechne sendet CAN-FD so bis 576 Bits am Stück ohne neu zu synchronisieren, vielleicht auch 10 mehr oder so, egal. Davon bis 512 Bits auf 2MBit. Und sowas wie Stuff-Bits berücksichtigt das nicht mal. Die absolut zulässige Abweichung von der gewünschten Frequenz ist da auf jeden Fall schon mal deutlich kleiner als bei 500kBit HS-CAN, wenn ich auch gerade keine Lust habe das auszurechnen. Die Vorstellung 32kHz auf 48MHz zu multiplizieren und damit dann dann die CAN-Unit zu betreiben behagt mir da einfach weniger als 16MHz auf 2MHz zu teilen und wieder auf 48MHz zu bringen. Das geht auch sauber auf, im Gegensatz zu 48MHz/32768. Vielleicht liege ich mit dieser Einschätzung auch knapp neben der Realität, dazu müsste man sich aber mal die Zahlen genauer ansehen. Thomas S. schrieb: > Nochmal ganz ketzerisch gefragt: Ich sehe einige Evalboards einen 16 MHz > Quartz verwenden. Gibt es einen Grund, das zu tun, außer dass man damit > noch den Schrank voll hat? 8 MHz sind in den gleichen Packages verfügbar > und haben in dem Design eigentlich keine Nachteile, oder doch? Es gibt die 16MHz Quarze aber auch kleiner als die genannten 3225 Packages. Ich würde gerne irgendwann mal auf die NX2016GC umsteigen, die gibt es gar nicht unter 16MHz.
Thomas S. schrieb: > Da lohnt es sich ja fast, den zweiten Taktgeber nur zum Überbrücken der > Anschwingzeit mit zu bestücken. Naja, du hast doch in der Zeit den 32-kHz-RC-Oszillator als Überbrückung.
Rudolph schrieb: > behagt mir da einfach weniger als 16MHz auf > 2MHz zu teilen und wieder auf 48MHz zu bringen. > Das geht auch sauber auf, im Gegensatz zu 48MHz/32768. Der Grundgedanke steckte hinter dem Eröffnen dieses Threads. Ich habe mir nicht im Detail angeschaut, wie eine FDPLL funktioniert, aber wenn ich Pi / Wurzel2 teile und das mal eine gebrochenrationale Zahl nehme, um auf genau glatte 48 MHz zu kommen, scheint mir das auch weniger erstrebenswert als 16 / 2 * 6. Ist aber eher "gefühlt besser" als dass ich es rechnerisch zeigen könnte, deshalb die Nachfrage.
Hallo zusammen, eventuell kann mir jemand hier weiter helfen :-) Ich bin gerade an einem kleinen CAN Projekt dran. Verwendet soll dort der ATSAMC21 der ja CAN0 und CAN1 hat. Ich brauche da einmal die 250 kbit/s und am anderen die 500 kbit/s. CAN Standart Protokoll mit je 10 CAN ID's 8 byte länge die gesendet oder empfangen werden sollen. Ich suche nach einer Beispiel Konfiguration und Quarz Auswahl. Im Netz habe ich mal das was ich gefunden haben getestet aber so richtig schlau werde ich da nicht. Arbeite mit über das ATMEL Start und als ToolChain nehme ich das Microchip Studio. Hardware ist das Sammy-C21 V1.0 SAM C21 CAN Modul von CHIP45. Dort gibt es wohl ein kleines Beispiel Programm SAMMY-C21_CAN_echo_example.zip mit 125 kbit/s das ich aber nicht in das ATMEL Start zurücklesen kann. Grüße Andreas
:
Bearbeitet durch User
hat sich erledigt, Bus läuft wie er soll. Das CAN bit timing war das Thema, die Appl. Node von Microchip hat ein Anfänger geschrieben :-( und mich einige Stunden gekostet ...
:
Bearbeitet durch User
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.