SAM-Controller, Einstieg und Auswahl

Alexxx schrieb:

> Wo gibt es eine Info, WAS genau in dem Prozessor mit Gehäuse xy drin
> ist?

https://www.microchip.com/ParamChartSearch/chart.aspx?branchID=211&popular=1

Wenn du bspw. als CPU einen Cortex-M0+ auswählst, ganz hinten "QFN" beim 
Gehäuse eingibst und dann vielleicht noch die mit der niedrigen 
Pinanzahl wählst, solltest du deine Wünsche problemlos erfüllt bekommen. 
Deine Peripheriewünsche werden ja wohl von praktisch allen Devices 
erfüllt.

Alexxx schrieb:

> Was würde ein Cortex-M3 für mich bringen?

Mehr Rechenleistung. Mehr CPU-Power scheinst du aber – zumindest nach 
dem, was du bislang geschrieben hast – nicht ernsthaft zu brauchen. 
Sind ja nicht nur M3, auch M4, M7 und M23.

Die M3 & Co. haben aber bei Atmicrochip eine völlig andere Peripherie 
als die M0+. Die Peripherie der M0+ finde ich insgesamt recht angenehm, 
modern, dagegen wirkt die vielfach von den älteren SAMs 
(prä-Cortex-M-Ära) übernommene der M3 … M7 irgendwie dinosaurierhaft.

Stefanus F. schrieb:
> Ein kleiner Schwenk von SAM zu STM32

Warum die Missioniererei?

Er schrieb doch recht deutlich, dass er für die Atmel-Linie bereits 
Entwicklungswerkzeuge hat. Ansonsten sind STM32 einfach mal anders, aber 
deshalb nicht notwendigerweise überall besser, und die paar relativ 
simplen Anforderungen, die der TE stellt, werden von derart vielen MCUs 
problemlos erfüllt, dass es kein Problem ist, auf den Wunsch Rücksicht 
zu nehmen, bereits vorhandene Entwicklungswerkzeuge beizubehalten.

Stefanus F. schrieb:

> Ja, die Atmel Debugger sind (vermutlich) nicht für STM32 geeignet.

Sie gehen schon auch, aber natürlich nicht mit den 
Atmel/Microchip-Tools. Mit OpenOCD kann jeder mit jedem.

> Debugger für STM32 bekommt man allerdings fast geschenkt, insofern kann
> ein Blick ins andere lager nicht schaden.

Man muss auch mit den SAMs nicht unbedingt ein AtmelICE benutzen. Mit 
OpenOCD gehen auch FT2232-basierte Teile prima (wie natürlich auch für 
alle anderen Cortex-M), wird aber vermutlich von Atmel Studio nicht 
unterstützt.

> Das soll kein Witz sein, das waren für mich die Gründe, mich nicht
> weiter mit Atmel Produkten zu beschäftigen (ich meine jetzt nicht mein
> eigenes Tutorial sondern insgesamt die Verfügbarkeit von für mich
> verständlichen Anleitungen).

Bei den SAMDxx muss man als Einstiegshürde eigentlich nur das Clock 
System nehmen, das ist ein bisschen komplex mit seinen vielen 
Taktgenerator-Modulen. Es gibt aber hier auch schon ein paar Threads 
dazu, wie man das Ganze "bare metal" in Betrieb nehmen kann (also ohne 
ASF oder Atmel Start oder sowas).

Die eigentlichen Peripherals sind relativ straightforward, gerade dann, 
wenn man sowieso schon von den Xmegas kommt.

Alexxx schrieb:
> Bei den Sams (D21) kann die Peripherie und die Ports nur mit maximal
> 24MHz laufen?

Ja, ich glaube.

Die größeren sind da natürlich auch schneller, wir haben hier gerade 
Cortex-M7 mit 160 MHz Peripherietakt in Benutzung.

Der Programmer ist nicht der Kostenfaktor. Ja, jeder Hersteller hat da 
was eigenes, aber Du kannst Dier auch einen JLink kaufen, der so gut wie 
alle ARM-Controller sowie PIC32 (MIPS, ähnliche Leistungsklasse) Renesas 
RX und RISC-V kann. Das ist sozusagen der Standard im Embedded-Bereich.

fchk

Jörg W. schrieb:
> Die M3 & Co. haben aber bei Atmicrochip eine völlig andere Peripherie
> als die M0+. Die Peripherie der M0+ finde ich insgesamt recht angenehm,
> modern, dagegen wirkt die vielfach von den älteren SAMs
> (prä-Cortex-M-Ära) übernommene der M3 … M7 irgendwie dinosaurierhaft.

Atmel hat doch mal damit geworben, dass die Periph. gleich bleibt für 
neuere Devices, damit man schneller umziehen kann.
Das sorgt dann natürlich für Dinosaurier Periph aus ARM7TDMI Zeiten 
selbst bei neueren Cortex-A5 SoCs.

Die STM32 Periph wird dann bei Cortex-M90 (oder sowas) sicher auch 
irgendwann also Dino beschimpft.

Mw E. schrieb:
> Atmel hat doch mal damit geworben, dass die Periph. gleich bleibt für
> neuere Devices, damit man schneller umziehen kann.

Zum anderen haben sie dann wieder so sinnfreie Aktionen dabei: beim 
Umzug von SAM4E auf SAME70 bekam das TWI eine Erweiterung, um schneller 
arbeiten zu können. Daher ist es jetzt ein "High-Speed Two-Wire 
Interface", folglich wurden nicht nur die Basisregister von TWIx auf 
TWIHSx umbenannt, sondern natürlich auch (wie zu Kernighan und Ritchies 
Zeiten) alle Bitfelder und Konstanten darin heißen dann statt TWI_XXX 
jetzt TWIHS_XXX. Selbstredend, obwohl die Register bis auf die 
zusätzlichen Bits für die Feature-Erweiterung 1:1 identisch sind.

Die Hardwareentwickler, die diese Umbenennung so gedankenlos 
durchgezogen haben, sollte man mal ein Vierteljahr in die 
Softwareentwicklung stecken …

Kannst ja das Softpack/ASF nuzen.
Oh moment, da heißt es ja auch anders ;)
(ist zudem auch genauso verbuggt wie der STM32 HAL)
Ist schon geil, wenn der USART ein FractionalPart hat aber der vom 
Treiber nicht genutzt wird und man sich wundert wieso der UART die 
1Mbaud mit 4% Abweichung raushustet obwohls bangOn gehen sollte mit FP 
:/

Alles muss man selber machen, sonst ist es sch**sse.

Alexxx schrieb:
> Wo gibt es eine Info, WAS genau in dem Prozessor mit Gehäuse xy drin
> ist?
> *Wo ist die Portbelegung des dezidierten Typs zu finden?*

Grobe Übersicht:
http://ww1.microchip.com/downloads/en/DeviceDoc/60001455D.pdf

Genaue infos dann im jeweiligen Datenblatt.

Wenn du auch mit 10x10 leben könntest, dann nimm den SAM4S oder eher den 
SAM4E.

Aber nimm nicht den SAM4L...der ist bzgl. DMA echt so umständlich.

Beim SAM4E hat jede Peripherie die DMA (PDC) unterstützt, direkt 
Register bei der Peripherie....beim SAM4L muss man alles umständlich 
zuweisen.

Ist nur ein Vorschlag. JA, es entspricht nicht deiner gewünschten 
Baugröße aber Power haben sie. :)


Die SAM D nutzen das neue Framework, ja das ist Geschmackssache, außer 
du progst eh alles selbst, dann ist es eh egal ;)

Das ASF ansich hat paar Bugs oder manchmal sogar nicht alles enthalten, 
aber lässt sich recht leicht ändern/erweitern.

Gruß

Alexxx schrieb:
> Gibt es für den D21 etc. keine überschaubare, schlanke HAL?

Eigentlich steht alles was man wissen muss im ReferenceManual.
Die Bitedefinitionen muss man nicht abtippen, dafür gibts die CMSIS 
Header.
Die CMSIS Header sollten sich auf der Herstellerwebseite oder in einem 
der vielen ASF Ordner finden lassen.

Im Gegensatz zu den AVRs musste ersteinmal für jede Periph, die du 
nutzen willst, den Takt einschalten.
ARM SOCs haben nämlich meist sowas wie einen System Controller und Power 
Manager.

Desweiteren starten die mit einem Grundtakt aus einem internen RC 
Oszilaltor und dann darfste selber per PLL den neuen, hohen Takt 
einstellen.
Auf ein externes Quarz muss man auch selber umschalten.

Die Bridges sind ersteinmal egal, die sind transparent.
Erst bei größeren SOCs kann man an der der Busmatrix Prioritäten und 
Schedulingverfahren umstellen.

Ich benutze inzwischen ganz gerne die C21, die C20 sind die Variante 
davon ohne CAN, das müssten so ziemlich die aktuellsten M0+ von Atmel 
bzw. Microchip sein.
Das TQFP32 von denen hat 7x7 mm mit 0,8mm Pitch.
Danach kamen die D5x/E5x auf den Markt, das sind M4F die bis 120MHz 
getaktet werden sollen.
Die QFN48 davon haben ebenfalls 7x7 mm.

Die neuesten Controller aus der Familie müssten die SAML11 sein, die 
haben aber weniger Peripherie als die C21 und die E51.
Nur finde ich die ohne CAN-FD ohnehin nicht sonderlich interessant. :-)

Die Errata sheets sind extra Dokumente:
https://www.microchip.com/wwwproducts/en/ATSAMC21E18A

Rudolph R. schrieb:
> das müssten so ziemlich die aktuellsten M0+ von Atmel bzw. Microchip
> sein.

Die C sind halt 5-V-Typen, dürften ansonsten den Ds sehr ähnlich sein.

Alexxx schrieb:
> keine überschaubare, schlanke HAL?

So recht nicht, aber das, was andere als HAL bezeichnen, ist durchaus 
auch nicht wirklich schlank, leider.

Wie gesagt, es gibt hier im Forum Threads für einen "bare metal"-Anfang, 
der die grundlegende Initialisierung der diversen Takte enthält.

Grundsätzlich laufen die Dinger auch erstmal mit einem internen Takt 
los, der ist eben nur vergleichsweise langsam (2 MHz wimre.).

Vor allem ist seine erste Aussage grundlegend falsch.
Hier sind genausoviele STM Leute anwesend wie ATSAM.
Beides wird ziemlich gleich empfohlen mit einer Tendenz zum STM32.
-> Daher: er will nur stänkern mit dümmsten Trollaussagen

Da der Fred bisher zivilisiert war und son Kasper hier querschießen muss 
könnten wir ja mal ab seinem ersten Post bis hierher den Löschhammer 
ansetzen?

Alexxx schrieb:
> Bei den Sams (D21) kann die Peripherie und die Ports nur mit maximal
> 24MHz laufen?

Nein, mit bis 48MHz wie der Core.
Das ist etwas versteckt im Datenblatt, ab Kapitel 37.6, Seite 985.
Ein paar Timer laufen auch mit bis zu 96MHz.
Wie das gehen sollen ohne den Core auch auf 96MHz laufen zu lassen ist 
mir allerdings gerade ein Rätsel, denn nur GCLKGEN0 verträgt die 96MHz 
und da hängt der Core dran.

Beim C2x ist das ab Kapitel 45.6, Seite 1155.
Und da sieht man schon, dass der C2x anders ist, GCLKGEN0 bis 2 laufen 
mit bis zu 96MHz und 3 bis 8 laufen mit bis zu 66MHz.

Beim D/E5x ist das ab Kapitel 54.6, Seite 1989.
Der hat von allem mehr, die ersten 8 Takt-Generaoren laufen bis 200MHz 
und die meiste Peripherie läuft mit bis zu 100MHz.
Die haben auch zwei PLLs, damit ist nicht automatisch alles an den Takt 
vom Core gekoppelt.
Beim C21 bin ich gerade mit der (unbegründeten und damit sinnlosen) 
Anforderung konfrontiert, dass der CAN-Controller mit 40MHz oder einem 
vielfachen davon laufen soll, mit nur einer PLL kann ich somit den Core 
auch "nur" mit 40MHz laufen lassen, oder weniger genau aus dem internen 
Oszillator.



Was mir bei den ATSAM ansonsten sehr angenehm aufgefallen ist sind die 
ganzen SET/CLEAR/TOGGLE Register, so quer durch die ganze Peripherie.
Bei einem kurzen Ausflug zu MSP432 wat ich etwas überrascht die da nicht 
zu finden.

Sehr nett, wenn auch zum Einstieg manchmal lästig, ist auch die 
Enable-Protection mit der je nach Register auch mal einzelne Bits 
gesperrt werden.
Und oben drauf hat man noch den PAC, Peripheral Access Controller.

Jörg W. schrieb:
> Grundsätzlich laufen die Dinger auch erstmal mit einem internen Takt
> los, der ist eben nur vergleichsweise langsam (2 MHz wimre.).

Die D21 starten mit 1MHz, die C2x mit 8MHz und die D/E5x mit 48MHz.

Rudolph R. schrieb:
> Was mir bei den ATSAM ansonsten sehr angenehm aufgefallen ist sind die
> ganzen SET/CLEAR/TOGGLE Register, so quer durch die ganze Peripherie.

Daher schrieb ich ja oben, dass er mit dem Teil beim Umstieg von Xmega 
die wenigsten Probleme haben dürfte.

Jörg W. schrieb:
> Rudolph R. schrieb:
>> Was mir bei den ATSAM ansonsten sehr angenehm aufgefallen ist sind die
>> ganzen SET/CLEAR/TOGGLE Register, so quer durch die ganze Peripherie.
>
> Daher schrieb ich ja oben, dass er mit dem Teil beim Umstieg von Xmega
> die wenigsten Probleme haben dürfte.

Da es keinen Xmega mit CAN gibt, kenne ich die so gut wie nicht.
Bei den AVR32 dürfte es ähnlich aussehen, nur waren die praktisch schon 
tot als die endlich mal in den Umlauf gingen.

Also mich hat das überrascht und ich finde es auch generell ziemlich 
krass, wie viel Peripherie in die Dinger gestopft wurde.
Dazu kommt, dass die Preise offenbar so gestaltet sind, dass man sich 
endlich mal von den AVRs verabschieden soll.

Rudolph R. schrieb:

> Bei den AVR32 dürfte es ähnlich aussehen, nur waren die praktisch schon
> tot als die endlich mal in den Umlauf gingen.

Ja, sie sind von den ARMs überholt worden. Ein Nischendasein führen sie 
noch in Form der EDBG-Chips.

> Also mich hat das überrascht und ich finde es auch generell ziemlich
> krass, wie viel Peripherie in die Dinger gestopft wurde.

Das dürfte allerdings bei so ziemlich allen ARM-MCUs der Fall sein, also 
egal ob Atmicrochip, ST, NXP, ...

Daran merkt man einfach, dass die Chipfläche deutlich billiger ist als 
bei den Steinzeit-Technologien, in denen die AVRs so gefertigt werden.