Hallo, für ein Projekt, in dem ein ATSAM4SD32CA Controller eingesetzt wird, stelle ich mir gerade die Frage, ob ich die ASF(4) einsetzen soll. Auf dem ersten Blick scheint die Architektur ganz vernünftig zu sein, auf dem 2. Blick ist die Dokumentation auf jeden Fall schon mal sehr dürftig. Auch die Notwendigkeit, ein Web-Tool zu nutzen, damit man überhaupt an die Sourcen heran kommt (was ist wenn ich in 10 Jahren von mal was an dem Projekt ändern muss, gibt es da dieses Web-Tool noch?), flößt nicht gerade Vertrauen ein. Hat jemand von euch Erfahrung mit der Library gemacht (evtl. sogar mit einem SAM4)? Lieber Finger weg? Woher bekäme man Beschreibungen der Peripheral Registers? Schönen Grüße, Torsten
Torsten R. schrieb: > Auch die Notwendigkeit, ein Web-Tool zu nutzen, damit man überhaupt an > die Sourcen heran kommt (was ist wenn ich in 10 Jahren von mal was an > dem Projekt ändern muss, gibt es da dieses Web-Tool noch?), flößt nicht > gerade Vertrauen ein. Du meinst also https://start.atmel.com/ und nicht AFS4? Das sind erstmal zwei getrennte Dinge, auch wenn Atmel Start dann AFS4 verwendet. Die ganze Atmel Software-Basis ist schon länger am dahin vegetieren und wird von Microchip nicht mehr gepflegt. Die ARM GNU Toolchain 6.3.1 ist inzwischen zwei Jahre alt und der GCC6 da drin noch ein Jahr älter. Das bedeutet ja nicht, dass die nicht mehr funktioniert, aber ARM ist inzwischen bei GCC 8. Und das Start hat erhebliche Macken. Zum Beispiel ist es mir im Start noch nicht gelungen den Takt-Vorteiler der PLL zu verwenden um einen ATSAMC21 oder ATSAME51 mit einem 16MHz Quarz zu verwenden ohne den Takt über eine der GCLCK Units runter teilen zu müssen. Und man kann die SERCOM Units im Start problemlos so konfigurieren das die Hardware nachher nicht laufen würde. Also zum Rumspielen sehr nett, aber mit Vorsicht zu geniessen. Microchip will auf MPLAB-X umziehen und dort deren MPLAB-XC Compiler promoten, dagegen ist an sich erstmal nichts zu sagen. In Zukunft soll Start wohl durch Harmony ersetzt werden. Mit all dem kann ich mich bisher aber nicht anfreunden, vor allem weil Microchip bisher nur Beta-Ware raus haut aber so tut, als ob das alles schon fertig wäre. Und man kann bei der Installation nicht mal auswählen was man haben will und bekommt so das volle PIC Paket mit serviert. Mir passt auch nicht das ich plötzlich einen XC32-GCC entweder kastriert benutzen soll, oder für viel Geld kaufen darf, obwohl nicht klar wird wo jetzt der Vorteil gegenüber dem freien GCC ist. Und im Job darf man die "Free" Version von den XC Compilern gleich gar nicht benutzen. Immerhin ist es (noch) möglich die Atmel AVR/ARM Toolchains zu benutzen. An der Stelle hat Microchip leider so gar nichts von Atmel oder auch anderen Herstellern gelernt. Torsten R. schrieb: > Woher bekäme man Beschreibungen der Peripheral Registers? Äh? Wie wäre es denn mit dem Datenblatt? https://www.microchip.com/wwwproducts/en/ATSAM4SD32C Und das hier ist hilfreich: https://microchipdeveloper.com/32arm:sam-bare-metal-c-programming Wäre nur mal nett, wenn Microchip einen Mitarbeiter abstellen würde der sich um die ATSAM kümmern darf und da mal etwas mehr Tiefe rein bringt. Aber Microchip hat es zum Beispiel nach mehreren Jahren noch nicht geschafft in deren eigenem Forum mal AVR und ATSAM Unter-Foren anzulegen. https://www.microchip.com/forums/Forums Ich hatte zum Beispiel auf der Embedded World am Stand von Microchip durchaus den Eindruck, dass die AVR und ATSAM in der Familie integriert sind. Aber jenseits vom Marketing fehlt mir da noch einiges an sichtbarem Fortschritt. Ich frage mich zum Beispiel, warum gibt es immer noch keine B-Revision von dem ATSAMD51/ATSAME51 bei der wenigstens einige der Errata gefixt sind?
Hi Rudolph, Rudolph R. schrieb: > Torsten R. schrieb: > Du meinst also https://start.atmel.com/ und nicht AFS4? Ich meine AFS4. Start muss ich wohl aber verwenden, um überhaupt an die Sourcen heran zu kommen. > Die ARM GNU Toolchain 6.3.1 ist inzwischen zwei Jahre alt und der GCC6 > da drin noch ein Jahr älter. > Das bedeutet ja nicht, dass die nicht mehr funktioniert, aber ARM ist > inzwischen bei GCC 8. Wir haben im Projekt noch einen anderen ARM Controller und werden von daher den gleichen arm-none-eabi-gcc einsetzen (version 8). Ich habe nun meine Anforderungen umzusetzen und bevor ich anfange das Rad neu zu erfinden, gucke ich mich mal um, um zu sehen, was es bereits so gibt. ASF3, ASF4 gibt es. Alles von Hand schreiben würde für UART / GPIO bestimmt noch gehen, aber z.b. USB CDC oder MSD wären schon eigene Projekte. > Torsten R. schrieb: >> Woher bekäme man Beschreibungen der Peripheral Registers? > > Äh? > Wie wäre es denn mit dem Datenblatt? Bei anderen Herstellern, wie ST oder Nordic bekommst Du mit deren SDK, auch header, in denen die Peripherals als structs definiert sind und mit Makros für die einzelnden Bit-Positionen in Registern etc. Das nimmt zumindest ein wenig Arbeit ab und eliminiert noch mal eine Fehlerquelle. Gibt es soetwas bei Atmel nicht? > > Und das hier ist hilfreich: > https://microchipdeveloper.com/32arm:sam-bare-metal-c-programming Ah, das scheint genau das zu sein, wovon ich oben sprach :-) Vielleicht sind diese header in dem ASF3 mit drinnen. Schönen Dank für Deine hilfreichen Einblicke! mfg Torsten
Torsten R. schrieb: >> Du meinst also https://start.atmel.com/ und nicht AFS4? > > Ich meine AFS4. Start muss ich wohl aber verwenden, um überhaupt an die > Sourcen heran zu kommen. Für das AFS4 gibt es wohl keinen anderen Weg da ran zu kommen. Ich gehe auch nicht davon aus, dass da noch Arbeit rein gesteckt wird. >> Torsten R. schrieb: >>> Woher bekäme man Beschreibungen der Peripheral Registers? >> >> Äh? >> Wie wäre es denn mit dem Datenblatt? > > Bei anderen Herstellern, wie ST oder Nordic bekommst Du mit deren SDK, > auch header, in denen die Peripherals als structs definiert sind und mit > Makros für die einzelnden Bit-Positionen in Registern etc. > > Das nimmt zumindest ein wenig Arbeit ab und eliminiert noch mal eine > Fehlerquelle. Gibt es soetwas bei Atmel nicht? Ah, Includes suchst Du. Da ist zum Beispiel das Atmel-Studio 7: https://www.microchip.com/mplab/avr-support/atmel-studio-7 Nach der Installation liegen unter anderem die Includes dann hier: C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel Updates für die Packs bekommt man hier: http://packs.download.atmel.com/ Das System hat Microchip inzwischen wohl auch für MPLAB-X übernommen. Wenn ich mir mal so meine MPLAB-X Installation ansehe findet sich das hier: C:\Program Files (x86)\Microchip\MPLABX\v5.15\packs\Microchip Aktuell wäre MPLAB-X ssv5.20. Wie man die Includes mit einem aktuellen GCC benutzt, müsste ich vielleicht irgendwann mal heraus finden. Vielleicht habe ich schon zu lange kein Makefile mehr editiert, aber vermisst habe ich das auch nicht. :-)
Rudolph R. schrieb: > Updates für die Packs bekommt man hier: http://packs.download.atmel.com/ Fine, da scheint alles drinnen zu sein (ist nur eine umbenannte zip-Datei, die unter anderem eine umbenannte zip-Datei enthält). > Wie man die Includes mit einem aktuellen GCC benutzt, müsste ich > vielleicht irgendwann mal heraus finden. Sieht aus wie ganz gewöhnliches C (und sogar an uns C++-User haben sie gedacht). > Vielleicht habe ich schon zu lange kein Makefile mehr editiert, aber > vermisst habe ich das auch nicht. :-) Guck Dir CMake an!
Wo wir schonmal bei Atmel Start sind : Was ich noch gar nicht kapiert habe, wie ich vorgehen muss, wenn ich per Atmel Start etwas konfiguriere, dass dann herunterlade, mit meinem Atmel Studio öffne, das ganze umfangreich mit meinem Code ergänze und dann merke, dass in der per Start getätigten Konfiguration noch ein Fehler ist. Kurz gesagt, wie bekomme ich die veränderte Start Konfiguration in mein bestehendes Studio Projekt ?
Mir kam das gerade ein wenig seltsam vor, dass der Packs-Download noch von Atmel.com läuft. Und es gibt in der Tat ein https://packs.download.microchip.com/ wo man auch Packs für PICs findet sowie für die Serien von ehemals Atmel die bereits von MPLAB-X unterstützt werden. Seltsamerweise hat die neue Packs Seite ein CMSIS 5.0.1 von 2017, die Atmel.com Seite aber ein 5.4.0 von 2018. Was mich aber so richtig stört sind die neuen Includes. Zum Beispiel beim ATSAMC21: 3.0.22 (2019-04-11) Removed legacy headers Da fehlt jetzt der komplette Ordner include/instance. Da sind die Einzel-Register Defines drin, sowas wie "REG_ADC0_CTRLA". Warum zum Geier macht man sowas ohne Vorwarnung, kann man das nicht erstmal auf "deprecated" setzen und Warnungen generieren, bevor man das einfach so raus wirft? Und ohne die "Doku" dafür anzupassen. Und wieso ist das auf einmal "legacy"? Ganz toll, da habe ich mich gerade dran gewöhnt das hier zu benutzen: REG_PORT_OUTTGL0 = PORT_PA27; Da kann ich mich schon wieder drauf einstellen das in Zukunft nur noch so benutzen zu können: PORT->Group[0].OUTTGL.reg = PORT_PA27; Oder "TC4->COUNT16.CTRLBSET.reg = TC_CTRLBSET_CMD_READSYNC;" statt "REG_TC4_CTRLBSET = TC_CTRLBSET_CMD_READSYNC;". Warum auch immer das nicht PORT0->OUTTGL.reg ist, sondern an der Stelle inkonsistent sein muss. Aber wenigstens kann ich mein Projekt im Atmel Studio 7 nicht mal öffnen solange Microchip.SAMC21_DFP.3.0.22.atpack installiert ist.
:
Bearbeitet durch User
Klingt zumindest so, als sollte man Deiner Erfahrung nach die Finger von Atmel für Neuentwicklungen lassen...
Naja, so auch nicht, mit dem was da ist kann man ja sehr gut arbeiten. :-) Nur was Microchip als Vorwärtsbewegung ansieht ist für mich bestenfalls seitlich oder gar rückwärts. Wenn es darauf ankommt kann man sich damit sicher auch arrangieren und da ich jetzt weiss wo die Reise mit den Includes hingehen wird kann ich das ja langsam mal umstellen - solange mich nichts dazu zwingt. Das ist jetzt alles im Umbruch. Auf der einen Seite ist der Support für die alte Atmel Software offenbar schon eingestellt, auf der anderen Seite nimmt der neue Support durch die Microchip Software erst langsam Fahrt auf. Das Start/AFS4 wirkt unfertig und hat Bugs, wird aber wahrscheinlich so bleiben bis es ganz verschwindet. In MPLAB-X gibt es aber bisher praktisch nur Support für aktuellere Serien wie C21 und D5x/E5x. Woanders hingehen ist mitunter dann auch nicht so leicht, ich wüsste nicht womit ich den ATSAMC21E18A ersetzen könnte. Der ist niedlich und kann iso CAN-FD.
Hallo zusammen, hier erstmal eins vorab: "Atmel START" und Atmel Studio 7 funktionieren und wenn man mal das Prinzip (den Ablauf) kapiert hat, dann ist es super toll. Ich habe in ganz kurzer Zeit (wenige Tage) ADC, SysTick, WDT, Timer TCC und Timer TC, USB, Event-System (super toll), die ganzen Clock-Chains, Pin-IRQs mit edge filter, SPI, USART, I2C, RTC und einen PWM Ausgang "reingeklickt". "Atmel START" erzeugt nach jedem Upload (Generate Project) eine "driver_examples.c", in der man für jede der erzeugten Instanzen Demo-Code erhält. "Atmel START" funktioniert übrigens nicht nur im Browser "start.atmel.com" sondern auch in einem in das Studio eingebauten Browser. Da hat man dann gleich einen Button "Generate Project" und der saugt sich alle upgedateten Dateien runter, macht ein Fenster auf, was neu/geändert ist und kopiert es rein. Nachdem ich prinzipiell in den Atmel-Dateien nichts ändere, kann ich alle Dateien bedenkenlos reinholen, nur mein "main.c" lass ich nicht ändern, ist aber auch nicht nötig (der Haken ist da nicht gesetzt). Dann findet man im Projekt-Explorer Unterordner HAL (Hardware Abstraction Layer), HPL (Hardware Proxy Layer) und HRI (Hardware Register Interface, da findet man übrigens die ganzen Register drin) jede Menge .c und .h Dateien, die man genüsslich studieren kann (geht ganz leicht, auf eine Funktion klicken, rechte Mausstate, Goto Implementation"). So, wenn man das alles mal kapiert hat, dann ist man wirklich schnell. Bis ich es verstanden habe, habe ich allerdings ein paar Tage gebraucht. Die Dokumentation ist unter aller Sau!!! Aber die Chips sind toll, speziell mein ATSAMD21G, was der kann für so wenig Geld ist wirklich toll. Natürlich finde ich das Web-basierte "Atmel START" (auch das im Studio ist Web-basiert) nicht toll, man kann ja auch nicht offline daran rumkonfigurieren, neben den vielen anderen Argumenten. Da ist mir ein lokaler "Processor Expert" wie bei Freescale schon lieber. Die Hilfe zu "Atmel START" ist übrigens genauso übel! Und es gibt grobe Macken. Nach dem Ändern in Atmel START kam nach dem Click auf "Generate Project" nur die Meldung "Unable to generate project", Ursache unbekannt, kein weiterer Hinweis. Da bei jedem Download ein Backup angelegt wird, konnte ich rückwärts ändern bis es wieder ging. Ursache war dann ein Input Pin, der falsch konfiguriert war (ich wollte die External-IRQ Funktion und die Pin-Abfrage gleichzeitig nutzen). Atmel START hat das zugelassen, aber bei Export gesteikt und ohne Angabe von Gründen. Sowas ist übel. Man kann aber die .atstart Datei auch im Browser (start.atmel.com) importieren, da kriegt man geringfügig mehr Informationen, aber da stand bei mir plötzlich was von ATSAMC20 (statt ATSAMD21) und das hat mich auch wieder in die falsche Richtung geführt. Richtig pervers wurde es als ich einen Debug printf auf den USART machen wollte und ich dachte, das dauert max. 1 Stunde. Falsch! 2 Tage!!! Man kann bei "Atmel START" unter "Add Software Components" "Middleware" "Utilities" eine "STDIO Redirect" hinzufügen. Die macht dann einen USART als Client automatisch dazu. Mein USART war aber fertig und ich wollte einen ohne Buffer und ohne Interrupts, also ein schlankes Teil". Weit gefehlt. Die "STDIO Redirect" kann nur mit dem völlig überzogenen zu Tode abstrahierten HAL USART, nicht aber mit meinem Lite USART ohne Buffer und ohne IRQ. Angeblich verfügbare Makros "FDEV_SETUP_STREAM" (oder auch klein, mikrocontroller.net) waren nicht aufzufinden, Anleitungen dass man den "ptr_put" abändern soll (auf die eigene USART Write verbiegen, AVRFreaks) ging auch nicht. Als es mir zu blöd wurde weiter zu suchen/lesen, habe ich einen printf reingemacht um da rein zu steppen. Beim Übersetzen kam die Meldung "undefined reference to `_write'", jetzt war klar was er will. Suche nach dem _write Prototyp: Wieder 1 Stunde!!!! Ja, jetzt weiss ich dass der Prototyp in der ASF4 Doku steht. Noch perverser wurde es, als ich den ATSAMD21G in den DeepSleep versetzen wollte. Alle Application Notes von Atmel erkären mir, wie man den Stromverbrauch am besten messen sollte (muss man mir wirklich nicht sagen, auch nicht, dass man das nicht mit angeschlossenem Debug-Tool macht) aber in keiner stehen die 20 Zeilen Code drin, die man vor dem "_go_to_sleep();" machen sollte und die 20 Zeilen Code danach. Man sollte nämlich alle (!!!) nicht benötigten (!!!) Oszillatoren und Clock-Generators ausschalten. Aber bei einem Wake-up sollte man auch wissen, dass die Aufweck-Peripherie (z.B. WDT oder RTC oder Pin) dann an einem langsamen Clock (z.B. 32KHz) hängen und dann die Register-Synchronisation scheiss langsam ist. Die braucht nämlich 5-6 Cyclen (danke MartinL, forum.arduino.cc) und das sind bei 32KHz 150µsec !!! und bei 1KHz (WDT oder RTC) 5msec (ja millisecs!!!). Also vor der Abfrage warum man aufgeweckt wurde erstmal den zugehörigen Oszillator wieder hochfahren (geht bei RC-Oszillator und der DFLL48MHz recht schnell). Atmel oder besser Microchip hat keinen Bock darauf einen Muster-Code vorzulegen! Und so kommt es, dass einer im DeepSleep 3mA verbraucht, ein anderer 300µA und noch einer hat es geschfft auf 10µA runter zu kommen (der darf aber seinen Code nicht posten). Dummerweise habe ich den DeepSleep zuerst programmiert, erst dann den Debug-UART, weil ich zuvor den SWD-Debug-Print benutzt habe). Jetzt weiss ich, dass unter "Middleware" "Utilities" eine "Sleep Manager" ist. Den werde ich morgen mal ausprobieren. Aber die "Middleware" hat mich nie interessiert, weil da High-Level-Protokolle, JPG-Compression, Crypto, Displays, etc. etc. drin sind, also etwas was ich nicht brauche. Ja, jetzt schaue ich mir den "Middleware" an weil da vielleicht nochwas drin ist, was man auf unterster Ebene brauchen kann. Generell zu Atmel START: Die Abtraktion ist so krass, dass man bei gefühlten 500 .c und .h Dateien in den Ordnern nicht mehr durchkommt, da irgendwas nachvollziehen zu können. O.k., jetzt bin ich über die hoffentlich meisten Fehler drüber hinweg, aber das war harte Kost. Atmel Studio ist so irgendwie mein 50. oder 100. IDE das ich nutze. Aber die IDEs werden immer perverser (kompilizierter). Andererseits werden die Chips auch immer umfangreicher. Wer hat da schon Lust und die Zeit, mal schnell 1117 Seiten ATSAMD21G Datenblatt zu lesen? Mit Atmel START musste ich nur wenige Sachen dort gezielt nachlesen, der Rest ging automatisch. Und dafür akzeptiere ich die paar Macken. Bei meinem anderen Teil-Projekt durfte ich knapp 2000 Seiten MCU-Users-Guide (LPC43S70) durchlesen und da musste ich wirklich ohne Code-Generator Zeile für Zeile programmieren. Das war anstrengender als die paar Tage mit Atmel START. Ich liebe Atmel also weiterhin, auch wenn sie jetzt Microchip sind. Und Gott sei dank habe ich die PICs hinter mir, ein Wunder, dass die überhaupt dafür einen C-Compliler hinbekommen haben. Aber den Assembler-Code, den der generieren muss, will man nicht wirklich sehen :-) Zum Schluss noch etwas, das mir noch bevorsteht: Mit nur 200 Zeilen in meinem "main.c" und sonst nichts von mir (!!!), allerding jede Menge Peripherals (siehe oben) habe ich "Program Memory Usage: 27864 bytes 82,5% Full" und "Data Memory Usage: 2984 bytes 72,9% Full". O.k., die Debug-printfs werden per #define ausschaltbar gemacht, dann wird es weniger. Aber dafür ist TinyUSB (danke hathach (tinyusb.org)) noch nicht drin. Also werde ich in ARM M0 Assembler meinen Code etwas verbessern und schneller machen, weil es mich mit der ganzen Abstraktion nervt, dass bei 48MHz CPU clock (=20nanosecs bei 1-Cycle Instructions) in C mal schnell 500nanosec werden! Und ausserdem liebe ich es, in Assember direkt mit der Hardware zu "sabbeln". Leute, es lohnt sich, dass man sich ein paar Tage mit Atmel START beschäftigt, dann ist alles ganz easy und ich kann gar nicht mehr verstehen, warum ich solange für die knapp 200 Zeilen in meinem "main.c" gebraucht habe :-) Harald
Harald schrieb: > hier erstmal eins vorab: "Atmel START" und Atmel Studio 7 funktionieren > und wenn man mal das Prinzip (den Ablauf) kapiert hat, dann ist es super > toll. Mal davon ab, dass ich unter funktionieren was ganz anderes verstehe, START ist tot und wird nicht mehr gefixt. Mich kotzen zwar gerade die neuen Includes von Microchip an und für MPLAB-X kann ich mich so überhaupt nicht begeistern, aber MPLAB Harmony ist längst an START vorbei gezogen: https://github.com/Microchip-MPLAB-Harmony Vor allem wenn man sich Microchips Peripheral Library plib ansieht dann ist das eine völlig andere Nummer als das Bestreben von ASF3 und ASF4 den eigentlich Code möglichst gut zu verstecken: https://github.com/Microchip-MPLAB-Harmony/csp_apps_sam_c20_c21/tree/master/apps/adc/adc_sample/firmware/src/config/sam_c21n_xpro/peripheral/adc Das ist eher so wie die STM32Cube LowLevel HAL Library. Direkt Code und nachvollziehbar. Nicht mehr Schichten als eine Zwiebel um möglichst viel zu verbergen.
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.