Hallo, ich habe bisher Atmel-8Bit-Controller programmiert und habe jetzt ein neues Projekt, bei dem die Leistungsfähigkeit des XMegas zu knapp sein könnte. Deshalb überlege ich mir, auf einen 32Bitter umzusteigen. Da wir für die Microchip-SAMs schon einen Debugger haben, wären die bevorzugt. Ich habe schon nach einer Übersicht über die SAM-Controller gesucht, aber nix gefunden, wo die für mich wichtige Peripherie parametrisch gesucht werden kann. Habt ihr mir da einen Link? 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?* Wo gibt es gute Tutorials oder Einführungen in einen Prozessortyp? Meine (sich teilweise sich widersprechenden) Anforderungen: - maximale Gehäusegröße 7x7, wenn möglich kein BGA, besser QFN. 5x5 Gehäusegröße wäre wünschenswert - mindestens 48MHz Systemtakt - Aller mindestens 3 benutzbare Timer, besser mehr. mind. 2 PWMs + >= 1 Modul zum Frequenz messen -> Zeit-Capture - 2x SPI, DMA-Einheiten - günstig wäre auch ein Hardware-Multiplizierer - Stromverbrauch <100mA, @3,3V Über sachdienliche Informationen würde ich mich freuen.
Würde den D21 im QFN48 in den Ring werfen. Da hast du 3 Timer für PWM, 3 GP-Timer, 7x7mm Gehäuse, Hardwaremultiplier in 1-Cycle Ausführung, die Timer können Capture, SPI und DMA geht. Wenn du kleinere Gehäuse suchst, wirst du um BGA nicht rumkommen. Alexxx schrieb: > Wo gibt es eine Info, WAS genau in dem Prozessor mit Gehäuse xy drin > ist? Datenblatt, unter 'Configuration Summary' Alexxx schrieb: > *Wo ist die Portbelegung des dezidierten Typs zu finden?* Datenblatt, 'Pinout' und 'I/O Multiplexing'. Wenn du keine spezielle Peripherie (USB, Ethernet, mehrere Cores) brauchst, sind die C und D Serie ein guter Startpunkt.
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.
Danke schon mal. Was würde ein Cortex-M3 für mich bringen? Gibt es irgendwo Tutorials, Beispiele für D21 (und Cortex-M3, Cortex-M4)? Die Atmel-/Microchip-Datenblätter finde ich sch... - Da bin ich oft verwirrter als zuvor.
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.
:
Bearbeitet durch Moderator
Ein kleiner Schwenk von SAM zu STM: STM32F3 (Cortex M4F) gibt es in LQFP32 7x7mm Falls Dir 32MHz genügen: STM32L0 (Cortex M0+) gibt es ebenfalls in LQFP32 7x7mm. Einige STM32L0 Modelle gibt es auch in TSSOP20 6,5x4,4mm und in UQFP20 3x3mm Dazu kann ich Tutorials anbieten: http://stefanfrings.de/stm32/index.html
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.
Jörg W. schrieb: > Warum die Missioniererei? War nicht so gemeint. Ich habe nichts gegen SAM, nur keine Ahnung. > Ansonsten sind STM32 einfach mal anders ohne Zweifel > aber deshalb nicht notwendigerweise überall besser das will ich auch nicht behaupten. Ja, die Atmel Debugger sind (vermutlich) nicht für STM32 geeignet. Debugger für STM32 bekommt man allerdings fast geschenkt, insofern kann ein Blick ins andere lager nicht schaden. Vielleicht gefallen ihm meine Tutorials ja so gut, dass er deswegen wechselt. 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). Aber wie gesagt will ich niemandem die SAM Controller mies machen. Die sind auch gut - gar keine Frage.
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.
Danke auch für den Hinweis auf die STM32. Bei den Sams (D21) kann die Peripherie und die Ports nur mit maximal 24MHz laufen? Toll finde ich beim D21 dass er ein Eventsystem hat. Bei meinen Anforderungen bin ich noch vorsichtig, da ich noch nicht alles beieinander habe, was ich brauche. Jedenfalls habe ich komplexe Timings, muss einen Datenstrom von mind. 2MBits/s einlesen, verarbeiten und Datenframes vorbereiten zum ausgeben...
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 …
:
Bearbeitet durch Moderator
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ß
:
Bearbeitet durch User
Beitrag #5979050 wurde von einem Moderator gelöscht.
Danke nochmals für die ganzen Infos zu euren Erfahrungen. Ich finde das ASF undurchschaubar, alles in zig unter-unter...-Ordnern verteilt. Gibt es für den D21 etc. keine überschaubare, schlanke HAL? Nochmal die Frage nach Tutorials! Die Explain-Spielzeug-Boards benutzen ja das ASF. Da lernt man nicht die ganzen Feinheiten von Takterzeugung, den Bridges und anderer Peripherie. Wie hat die grundsätzliche Initialisierung statt zu finden? Welche Fallstrike/Einschränkungen/Dokulücken gibt es? Im SAM D21 Family Data sh. gibt es keinen Errata-Abschnitt mehr? Für was ist eigentlich das auxiliary Flash? Kann man da einfach Justierkonstante etc. speichern?
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
Alexxx schrieb: > Die Explain-Spielzeug-Boards benutzen ja das ASF. Da lernt man nicht die > ganzen Feinheiten von Takterzeugung, den Bridges und anderer Peripherie. Gut erkannt.
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.).
:
Bearbeitet durch Moderator
Auf registerebene gibt es auf github von ataradov ein paar Starter Projekte, die ich gerne nehme
Beitrag #5980056 wurde von einem Moderator gelöscht.
Beitrag #5980064 wurde vom Autor gelöscht.
Beitrag #5980070 wurde von einem Moderator gelöscht.
Beitrag #5980074 wurde von einem Moderator gelöscht.
Beitrag #5980077 wurde von einem Moderator gelöscht.
Beitrag #5980084 wurde von einem Moderator gelöscht.
Beitrag #5980087 wurde vom Autor gelöscht.
Beitrag #5980088 wurde von einem Moderator gelöscht.
Beitrag #5980092 wurde vom Autor gelöscht.
Beitrag #5980095 wurde von einem Moderator gelöscht.
Beitrag #5980097 wurde von einem Moderator gelöscht.
Beitrag #5980103 wurde von einem Moderator gelöscht.
Beitrag #5980106 wurde vom Autor gelöscht.
Beitrag #5980110 wurde vom Autor gelöscht.
Beitrag #5980112 wurde von einem Moderator gelöscht.
Beitrag #5980113 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch Moderator
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.