Hallo, ich habe mir einen Eval-board mit einem ARM-Cortex A5 zugelegt. Leider habe ich erst im Nachhinein festgestellt, das das ARM-DS5(Eclipse) keine Bare-Metal Supported(zumindest nicht in der Community Edition). Kennt einer von euch eine gute und kostengünstige(Schüler) IDE für den Cortex-A5(Atmel SAMA5)? Ziel des ganzen ist der einstig in den ARM Bereich ohne OS und um Fragen zu vermeiden warum ein Cortex-A: was man hat hat man :) danke und grüße Basti
muss es ein A5 sein? Wie wärs mit M4 oder M7? Mit den Pins wackeln können die auch schon. Da schlage ich natürlich MDK-ARM Professional vor :-)
:
Bearbeitet durch User
Basti schrieb: > Ziel des ganzen ist der einstig in den ARM Bereich ohne OS Du hast das A5 Board ja nun schon, aber besser gewesen wäre ein Raspberry Pi 2 mit A7. Zum einen hat das eine große Community und es wurde schon gcc angepasst: http://www.valvers.com/open-software/raspberry-pi/step01-bare-metal-programming-in-cpt1/ Zum anderen gibt es ein Single-Task "Betriebssystem" das direkt als Bootloader für Executables genutzt werden kann. Hat noch den Vorteil dass das Executable die Kernel-Funktionen als Library nutzen kann (obwohl der Kernel nicht läuft): https://www.riscosopen.org/content/sales/risc-os-pico
im Nachhinein stimme ich da voll und ganz zu. jedoch war ich so naiv und habe geglaubt das alle Atmel-Prozessoren zum Atmel-Studio unterstützt werden. danke ich werds mir mal anschauen :) bin ich dann auf das "RTX" angewiesen, oder kann ich das weglassen?
Ungeachtet der möglichen IDEs frage ich mich, ob es sinnvoll ist, gleich mit so nem Monster anzufangen. Wenn Studenten was über die ARM Architektur lernen sollen, würde ich einen Cortex-M3 oder M4 vorschlagen. Das ist sehr viel übersichtlicher und verständlicher, und trotzdem noch so komplex, dass es den meissten deiner Studenten eine Herausforderung bieten sollte :-)
Basti schrieb: > bin ich dann auf das "RTX" angewiesen, oder kann ich das weglassen? Im Zuge des CMSIS Driver Modells basieren jetzt alle Beispiele sowie Middleware auf dem CMSIS-RTOS, was du aber nicht verwenden musst, solange du keine fertigen komponenten verwendest, die das brauchen (Ethernet, USB, File System, ...). Wenn du dein Projekt mit CMSIS-RTOS aufsetzt, ist main() bereits ein Thread. Sonst nicht. Minimum sind die startup.s und die system.s, die die CPU anwerfen, die PLL konfigurieren und dich nach main() bringen, sowie die MCU Headerfiles für die Peripherals. Was du ab da treibst, ist dir selbst überlassen. Als zweiten Schritt empfehle ich aber ein RTOS sehr, da es viele Aufgaben, die etwas grösser sind als ein Blinky, sehr viel einfacher machen und entzerren. Einfachstes Beispiel: Wait for Event im Thread, gekoppelt mit einem Interrupt (send event). So lernen deine Studis auch gleich, wie man ausserhalb vom Polling strukturiert Ressourcen sparen kann.
:
Bearbeitet durch User
Vielen dank für die vielen antworten. ich programmiere bereits seit 3 Jahren erst auf ATmega => AVR32 und nun ARM. ich habe mir mal das "MDK-ARM Professional" gezogen Dort gibt es jede menge unterstütze "Geräte" jedoch finde dort aber keine Cortex A5 oder den ATSAMA5 unter den Devices grüße
Richtig, das ist eine IDE/Debug Umgebung für Cortex-M. Blöde Frage: Suchst du für dich zum lernen oder zum lehren? :-)
mmpf da kann ich lange suchen ^^ aber unter den Features steht ARM7... ich such was zum Programmieren und Spaß zu haben :P dabei ist ein recht schöner Nebeneffekt das ich was darüber lerne. ich habe auch vor später(wenn ich dann mal irgendwann mit der schule und uni fertig bin) in dem bereich zu arbeiten. grüße
Weil auch die MicroCONTROLLER der Cortex-M-Reihe eine ArmV7-Architektur haben. Der A5 ist allerdings ein MicroPROZESSOR
:
Bearbeitet durch User
hallo basti, hast du dir das software package für die gnu tools schon mal angesehen (http://www.atmel.com/images/sama5d3x_softpack_1.4_for_CodeSourcery_201309.zip bzw. http://www.atmel.com/images/sama5d3x_xplained_softpack_1.4_for_CodeSourcery_201309.zip)? gruss gerhard
Ja habe ich dait konnte das keil nix anfangen okay das mit den vielen verschiedenen Versionen ist am Anfang etwas verwirrend. ist zwischen Mikroprozessor und mikrocontroller so ein großer unterschied? ich dachte der können einfach ein kleines bisschen mehr und sind schneller. also kennt keiner eine gute IDE für Bare-Metal Programmierung für ARM-COrtexA? schade muss ich doch noch was anderes kaufen ^_^ grüße
Basti schrieb: > also kennt keiner eine gute IDE für Bare-Metal Programmierung für > ARM-COrtexA? Könnte es sein, dass das ausser dir niemand macht? ;-)
hallo nochmals, unter \documentation\MigrationFromCStoEclipse.txt findest du eine anleitung wie du die beispiele und die library in die keil DS5 portieren kannst. gruss gerhard
kann sein das Bare-Metal auf Cortex-A eher unüblich ist. trotzdem mal vielen dank für die vielen Nachrichten. Das mit der anleitung werde ich mir anschauen, wobei das DS-5(C-E) eig. nur Linux unterstützt. dann wird der Cortex woll noch 1-2 Jahre warten müssen bis ich den dann unter Linux in betrieb nehme :) grüße basti
Hallo, super Entscheidung gleich einen A5 zu nehmen und dann noch den Atmel. Ist die absolut richtige Entscheidung für die Zukunft. Ich bin leider beim ARM9 von Atmel hängen geblieben. Es ist übrigens relativ egal ob M4 M7 ARM9 oder doch gleich A5, du wirst bei jeder CPU eine gewisse Einarbeitungszeit brauchen, und beim A5 lohnt es sich dann auch. Weil du damit alle ablederst. Das Ding hat richtig performance toll..... Also die emIDE mit gcc kann den A5 mit einem JLINK relativ gut unterstützen, es gibt dazu ein example Projekt welches du extra installieren musst. Es nimmt am Anfang halt ein paar Hürden, bis das Linker-Script file steht usw. Gruß Sascha
Da ich bald vor einem ähnlichen Problem stehe, schau mal hier: http://www.at91.com/linux4sam/bin/view/Linux4SAM/AT91Bootstrap http://www.atmel.com/tools/SAMA5D3SOFTWAREPACKAGE.aspx Welches Board hast du denn genau?
"Bare-Metal"-programmieren wollen aber nach ner IDE schreien **kopfschüttel**
Ich frage mich manchmal nach dem Sinn. Warum ARM Bare Metal? Assembler braucht man doch kaum noch. Und falls doch, dann guckt man in das Prozessor-Handbuch. Ob da nun ARM, AVR oder Mips ist, ist eigentlich egal. Es finden Register-Speichertransfers statt, oder Rechenoperatoren. Ob das Register nun AX oder R5 genannt wird, ist eigentlich egal. Ich habe mit verschiedenen ARMs zu tun. Die Unterschiede sind dabei für die Subsysteme wie SPI oder I2C, die bei jedem Prozessor woanders liegen und angesprochen werden müssen. Kann man SPI für einen STM, dann klappt das trotzdem nicht auf einem Sitara. Gelerntes Wissen nützt bei einem anderen ARM nichts. Und letztendlich wird alles in C programmiert. Dann ist es wieder egal, ob ein Arm oder ein Mips benutzt wird. Mein Fazit. Einfach vernünftig C programmieren lernen, dann kommt man mit fast jedem Prozessor klar. Und falls es doch Assembler sein muss: es gibt einen auf jedem Raspi. Das reicht zum Üben. Dazu brauche es nicht Bare Metal sein.
als Bord habe ich das "sama5d3 Xplained" bevor ich mir wieder was installiere, ohne es dann verwenden zu kommen :) das emIDE ist schon Baremetal fähig? der Grund warum ist einfach: natürlich kann ich einfach eine OS verwenden und mir das leben leicht machen, aber ich habe nicht die vorgabe schnell und billig irgendwas herzustellen. dehalb nehme ich mir die zeit und mühe gerne dabei etwas fundamentales zu lernen.
Basti schrieb: > dehalb nehme ich mir > die zeit und mühe gerne dabei etwas fundamentales zu lernen. Dann nimm doch irgendein Text-Editor zum editieren deiner Code (Notepad++, JEdit, VIM, Emacs, ...), benutze Make fürs Compilieren und Linken und GDB zum Debuggen. Das wird dir einige Fundamentals beibringen!
PittyJ schrieb: > Mein Fazit. Einfach vernünftig C programmieren lernen, dann kommt man > mit fast jedem Prozessor klar. Und falls es doch Assembler sein muss: es > gibt einen auf jedem Raspi. Das reicht zum Üben. Dazu brauche es nicht > Bare Metal sein. Ich glaube du hast eine völlig falsche Vorstellung von Bare-Metal. Bare-Metal heisst *nicht*: - emacs oder vi - assemblerorientiert - standardfrei - bibliothekslos - fixiert auf eine HW oder einen Hersteller Es heisst lediglich, dass du ohne Betriebssystem auf dem nackten Chip dein Programm aufspielst.
Basti schrieb: > kann sein das Bare-Metal auf Cortex-A eher unüblich ist. Basti schrieb: > als Bord habe ich das "sama5d3 Xplained" Ach, jetzt kommt der Grund für alles zum Vorschein. Naja, es paßt irgendwie nicht recht zusammen, sowas ohne BS betreiben zu wollen. Ich würde an deiner Stelle versuche, ein BSP von Windows CE dafür aufzutreiben und verstehen zu wollen (Lader + HAL) - und dann natürlich auch ein CE damit zu generieren und auf das Board zu laden. Damit hast du dann erstmal ne stabile Basis. Oder willst du all das, was da drinsteckt selber machen, so von der Speicherverwaltung über Kernel, Threadverwaltung, GDI, Filesystem, usw. bis zu einem selber ausgedachten API? Wenn du das tatsächlich binnen 10 Jahren schaffst, kriegst du hier ne Goldmedaille für Verwegenheit. W.S.
wie so so negativ? --Wenn du das tatsächlich binnen 10 Jahren schaffst, kriegst du hier --ne Goldmedaille für Verwegenheit. trotzdem vielen dank an Sascha ich werde mir die IDE anschauen und hoff einfach mal das es das ist was ich suche :) grüße Basti
Das ist wahrlich NICHT negativ. Auch nicht so gemeint. Aber entweder unterschätzt du den Berg an Arbeit oder du meinst es nicht wirklich ernst. Aber mein Hinweis auf WinCE war ernst gemeint. Sowas kann man stemmen, alle Soft gibt's frei herunterladbar (Platformbuilder + EVC) und es ist sogar ne IDE dabei. Obendrein kann man seine Apps notfalls auch auf nem alten Navi ausprobieren. W.S.
Hallo, Eigentlich ist der SAMA5 sehr schön mit Linux zu programmieren. Und das DS5 ist sehr gut. Schau mal hier http://www.mikrocontroller-software.de/ Das ist mein DokuWiki. Ich habe mal angefangen ein deutsches DokuWiki für embedded Linux mit dem Atmel Board zu erstellen. Ich suche auch noch Hilfe für ein paar Artikel.
wenn dem so ist möchte ich mich entschuldigen ich hatte eines falls vor einen kompletten Kernel selber zu schreiben, nur ein kleines bisschen. aber vielleicht sollte ich doch erst das Bord als Linux-board verwenden. grüße
Hallo Basti, ich halte die Idee einen Cortex-A bare-metal zu programmieren für gut. Auch wenn es unüblich ist weil auf Prozessoren dieser Klasse eigentlich immer ein OS läuft: Zu wissen was sich "unter der Haube" tut, ist niemals schlecht. Ich habe mit Cortex-A-Prozessoren leider keine Erfahrung. Funktioneren herkömmliche OpenSource-IDEs wie zB Em::Blocks nicht mit diesem Prozessor? Das würde mich ehrlich gesagt wundern. Der Prozessortyp sollte der IDE wohl relativ egal sein, solange die Toolchain ihn unterstützt. Und die Cortex-A sind von den "GNU Tools for ARM Embedded Processors" (https://launchpad.net/gcc-arm-embedded), denke ich, schon unterstützt. Insofern sehe ich da jetzt theoretisch kein Problem. Was du natürlich auch immer machen kannst, ist dein Projekt auf der Kommandozeile zu kompilieren. Da bin ich ein großer Fan davon, da man dadurch wirklich was für die Ewigkeit lernt. (IDEs ändern sich, aber die Kommandozeilenswitches vom GCC wohl eher selten.) Wenn die Kommandozeilen-debugging mit GDB zu kompliziert ist: Eclipse-CDT unterstützt seit neuestem auch Standalone-Debugging. Das heißt man benutzt Eclipse nur zum debuggen, ohne das ganze Projektmanagement-Gedöns drumherum. Ich sag aber gleich dazu, dass das mit einem gewissen Aufwand verbunden ist, da man sich der Herausforderung mit C, dem GCC, OpenOCD und GDB klar zu kommen zugleich stellen muss. Die Lernkurve ist zwar steil, allerdings tritt man gefühlt sehr lange auf der Stelle. Viel Erfolg!
Hallo, also ich habe auf einem ARM9 ein eigenes mini Betriebsystem hochgezogen, alles top Assembler optimiert, leuft super schnell ist durch nichts mehr zu schlagen. Man muss halt alles selber machen, aber danach hat man über die Hardware und dem Prozessor eine menge gelernt. Ich kann heute nur jedem empfehlen wenn er die Zeit hat, einmal so etwas zu realisieren und die Abhängigkeit von Betriebsystemen im klassischen Sinne zu reduzieren. Man braucht nicht unbedingt gleich ein Betriebssystem. Gruß Sascha
Sascha schrieb: > also ich habe auf einem ARM9 ein eigenes mini Betriebsystem hochgezogen, > alles top Assembler optimiert, leuft super schnell ist durch nichts mehr > zu schlagen. Kann man das irgendwo nachvollziehen?
Manuel W. schrieb: > ich halte die Idee einen Cortex-A bare-metal zu programmieren für gut Aber bevor es losgehen kann braucht es eine Startup-Firmware und insbesondere der Atmel A5 hat hochkomplexe Fuses ... Sascha schrieb: > ich habe auf einem ARM9 ein eigenes mini Betriebsystem hochgezogen Der ARM9 ist wesentlich weniger komplex als der A5. Ich hatte ja als Alternative schon das Raspberry Pi mit ARM11 (bzw. A7) empfohlen, hier gibt es auch schon eine Startup-Firmware mit der man sein Binary laden kann.
Hallo, nun gut ein first Bootloader wird ja wohl jeder Controller haben, wie Atmel Cortex A5 und auch alle seine ARM9 derivate. Einen Second-Bootloader muss man sich dann selber schreiben, habe ich auch gemacht und musste feststellen ist gar nicht so schwer. Man muss nur darauf hachten, mit der gleichen Konfiguration wie das Linker-script File einzusteigen. Somit hat man es einfacher, Code direkt über die IDE ohne Bootloader ins SDRAM einzuspielen und zu bebuggen oder auf ein Bootmedium zu legen und über den Second-Bootloader zu starten. Gruß Sascha
Hallo, sorry habe Link-script File mit der JTAG configurations Datei, die den Prozessor initialisiert verwechselt. Ist bei den meisten IDEs eine Macrodatei oder Startup Datei, welche SDRAM, PLL, Clock usw. erst im Prozessor initialisiert. Gruß Sascha
Hallo, Was ist den der unterschied zwischen dem first/second level Bootloader? bzw. was sind deren aufgaben?
Hallo, also der first Bootloader ist fest im ROM deiner CPU drin, den kannst du nicht ändern. Bei Atmel finde ich die Lösung sogar relativ gut. Nun wenn die CPU vom Reset geht wird dieser Code aus dem internen ROM gestartet und versucht dann über diverse Schnittstellen etwas brauchbares zu laden. Es wird versucht eine gültige Interrupttabelle zu laden mit dem kleinen Trick, dass ein Interruptvector der undefiniert ist die Länge des zu ladenden Codes angibt. So jetzt stell dir mal vor, dass zu diesem Zeitpunkt nur der interne Speicher der CPU funktionstüchtig ist. D.h. ein externes DDR oder SDRAM oder SRAM wurde bis jetzt noch nicht initialisiert. Der first Bootloader kann ja auch gar nicht wissen, was du an die CPU angehängt hast. Also wird dein Code (in dem Fall vieleicht der Second Bootloader) in das interne SRAM geladen. Dann wird ein Re-Mapping durchgeführt, also ROM gegen SRAM ausgetauscht und dein Code wird gestartet. O.K. Soweit ? Jetzt leuft natürlich dein Code (der Second-Bootloader) und kann die ganze CPU und dessen Hardware initialisieren, besonder das DDR oder SDRAM was extern dranhängt. Nun ist dein Programm aber z.B. 2Mbyte groß, was man mit Grafik und Sound schnell zusammenhat und das kann dann nachgeladen werden im DDR oder SDRAM und gestartet werden. Dann müssen nur noch die Interrupt Vectoren auf dein Programm angepasst werden (mit einer Copy Routine) und los geht es. Somit ist der Second-Bootloader beendet. Gruß Sascha
Also der First-bootloader ist das was man bei der AVR-mega Serie etc. schreibt? und im Second Bootloader muss man sich folglich keine Gedanken mehr über die Speicherverwaltung machen? vielen dank dir für die Ausführliche Erklärung :) Grüße
Basti schrieb: > Also der First-bootloader ist das was man bei der AVR-mega Serie etc. > schreibt? Ich denke das kann man nicht vergleichen. > und im Second Bootloader muss man sich folglich keine Gedanken mehr über > die Speicherverwaltung machen? Doch, da geht es erst los. Der SAMA5Dx unterscheidet sich nicht sehr von den bisherigen ARM926 basierenden Typen wie den ARM9G45. Cortex A5 statt 926, mehr und bessere Peripherie, aber der Bootprozess ist immer noch fast der Gleiche. 1. Level Bootloader bzw ROM Bootloader. Klappert eine Reihe von möglichen Bootdevices ab (NAND, SPI, I2C, MMC ...) und lädt von da (den 2. Level Bootloader) in den internen RAM (max 64 kB), und wenn nichts da ist, wird ein USB-Monitor gestartet (Gegenstück auf PC: SAM-BA) Addresse 0 mit den Vektoren zeigt auf den ROM in dieser Phse. 2. Level Bootloader Initialisiert den DDR2 Speicher und lädt dann die nächste Stufe. Addresse 0 mit den Vektoren zeigt auf den internen RAM in dieser Phse. 3. Level Bootloader typischerweise U-Boot. Addresse 0 mit den Vektoren zeigt auf den DDR2 Speicher in dieser Phse. Eine eigene Barmetal Anwendung sollte man anstelle des U-Boots benutzen, das macht am wenigsten Aufwand. Insbesondere sind dann schon wichtigsten Systemkomponennten initialisiert (PLL, DDR2) Man kann die Barmetal Anwendnung bei der Entwicklung auch direkt mit dem USB-Monitor laden, braucht dann aber ein SAM-BA Script zur initialisierung. (Gibt Beispiele)
Vielen dank nochmal für die ausführliche Erklärung :) ich glaub auch es wirklich das beste auf Level 3 anzufangen danke und grüße Basti
Ich habe recht viel Bare-Metal Programmierung auf einem Cortex A15 gemacht. Als IDE habe ich Code Composer genutzt. Praktisch ist es, wenn es irgendwelche Skripte gibt, die dir die Hardware (vorallem RAM und PLLs) initialisieren. Dann kann man alles schön in der IDE debuggen. Oder du fügst dein Programm in UBoot ein. Da hat man praktischerweise alle Funktionen für ein UART Terminal (und vieles mehr). Dafür ist das Debuggen etwas umständlich, da UBoot alles an das Ende des RAMs kopiert. UBoot nutzt übrigens keine Interrupts, wenn du die nutzen willst musst du manuell den GIC des ARM initialisieren und einen Stack für den IRQ Modus aufsetzen. (Speicherbereich reservieren, in den IRQ Modus wechseln und Speicheradresse in Stackpointerregister schreiben).
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.