Moin, ich werde mich demnächst mit der GBA Entwicklung auseinander setzen, dessen Herzstück ein ARM7 Basierter uC ist. Grund dafür ist, dass ich mich schon mal auf den Umstieg zu den großen Playern vorbereiten möchte (gemeint ist die Cortex-A Reihe). (Davor hatte ich viel mit AVR8 und Z80 Assembler Programmierung zu tun.) Programmiert wird Anfangs nur mit Assembler, später dann auch in Hochsprachen wie C/C++. Jetzt stellt sich mir aber die Frage, ob ich nicht besser gleich zu den Cortex-M Reihen übergehen sollte, da ich denke, dass diese mehr mit der "A" Reihe gemeinsam haben als die alte ARM7. Soweit ich weiß unterstützen beide Architekturen (ARM7 und Cortex-M) die Thumb Instruktionen, was eine wichtige Gemeinsamkeit zu scheinen ist. Was sagt ihr dazu, lieber ARM7 oder Cortx-M Reihe bevor es zu den Cortex-A Reihen geht? Bitte mit Begründung :)
ARM7 --> Cortex-M (Microcontroller) ARM9 --> Cortex-R (Realtime) ARM11 --> Cortex-A (Application) Der passende Umstieg von ARM7 auf Cortex wäre demnach Cortex-M (z.B. M3, M4). Geht es nur um Rechenleistung, es gibt mittlerweile Cortex-M (4, 7) mit bis 300MHz. Willst du ein Linux programmieren oder dich bare-metal mit MMU rumschlagen, nimm Cortex-A :-)
:
Bearbeitet durch User
Ahmad Mahmad schrieb: > Was sagt ihr dazu, lieber ARM7 oder Cortx-M Reihe bevor es zu den > Cortex-A Reihen geht? Bitte mit Begründung :) Cortex-A und -M haben unterschiedliche Anwendungszwecke. Du musst wissen, was dir wichtig ist: - Leistungsaufnahme - Echtzeitfähigkeit - Performance, Rechenleistung - Speichergröße - Multimedia-Fähigkeiten - Möglichkeit "richtige" Betriebssysteme wie Linux auszuführen - Möglichkeit, ohne Betriebssystem ("Bare Metal") zu arbeiten - Komplexität der Programmierung - Schnelle Interfaces - Flexible Auswahl bei Gehäuse, Varianten - Einfache Integration in Schaltungen - Preis-Rechenleistungs-Verhältnis usw usf... Die Cortex-A sind sehr viel komplexer als die -M und ohne Linux schwer bis gar nicht nutzbar. Die -M zielen auf den typischen Mikrocontroller-Markt ab, eben wie AVR. "ARM7" ist etwas unspezifisch; die gibt es auch in "klein" (ARM7TDMI, Mikrocontroller) bis "groß" (ARM720T, Anwendungsprozessor), eben wie Cortex-M und -A. Daher kann man nicht "einen" Nachfolger empfehlen.
Random .. schrieb: > es gibt mittlerweile Cortex-M (4, 7) > mit bis 300MHz. Mach mal 600MHz draus, siehe z.B. i.MX RT Serie von NXP: https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/i.mx-applications-processors/i.mx-rt-series:IMX-RT-SERIES
Niklas G. schrieb: > Die Cortex-A sind sehr viel komplexer als die -M und ohne Linux schwer > bis gar nicht nutzbar Die Cortex-A sind ganz ohne Linux genauso einfach zu programmieren. Es gibt Libraries und RTOS Jim M. schrieb: > Mach mal 600MHz draus, siehe z.B. i.MX RT Serie von NXP Ein BCM283x ist viel billiger und wesentlich schneller. Random .. schrieb: > bare-metal mit MMU rumschlagen Auch nicht anders als sich bare-metal mit MPU rumschlagen.
Lothar schrieb: > Die Cortex-A sind ganz ohne Linux genauso einfach zu programmieren. Es > gibt Libraries und RTOS Die Libraries und RTOS und allgemein die Umgebungen sind aber auch deutlich komplexer. Bis man z.B. bei TI Sitara erstmal durchgeklickt hat welche Komponente wofür ist...
Lothar schrieb: > Auch nicht anders als sich bare-metal mit MPU rumschlagen. Bei der MMU muss man sich auch erstmal mit den ganzen Cache Konfigurationen auseinander setzen und die richtigen Maintenance Operationen benutzen wenn es um Multicore oder DMA geht. Die Informationen dazu sind auch etwas versteckt und man macht das Programm schnell mal langsamer als schneller. Sowas wie Page Coloring ist auch nicht sofort einsichtig... Für das Exception Handling braucht's auch eine gute Dosis Assembler; bei Cortex-M geht das komplett in C.
Niklas Gürtler schrieb: > TI Sitara erstmal durchgeklickt hat welche Komponente wofür Kannst Dir mal ansehen wie es dieses "einfache" OS auf TI Sitara macht: https://www.riscosopen.org/wiki/documentation/show/OS_Memory https://www.riscosopen.org/content/downloads/titanium https://gitlab.riscosopen.org/RiscOS/Sources/HAL/HAL_Titanium
Niklas Gürtler schrieb: > Bei der MMU muss man sich auch erstmal mit den ganzen Cache > Konfigurationen auseinander setzen Nicht wenn mein Programm das einzige ist was läuft. Und es ging doch darum Cortex-A wie Cortex-M als uC zu nutzen oder? Ausserdem gibt es auch Dual-Core uC wie z.B. LPC5500 mit 2x M33 ; protected memory access MOV R0, #&0D ; physical to logical address map (permanent) LDR R1, gpiobase ; physical address MOV R2, #&100 ; logical address space size 256 bytes SWI "OS_Memory" ; MMU MOV R12, R3 ; returned logical address pointer
Lothar schrieb: > Kannst Dir mal ansehen wie es dieses "einfache" OS auf TI Sitara macht: Ich weiß wie das geht, habe auch eine Art RTOS für Sitara geschrieben... habe auf jeden Fall trotz Cortex-M-Erfahrung eine Weile gebraucht um das alles zu sortieren. Allein schon das Projekt Setup in CCS ist spaßig. Lothar schrieb: > Nicht wenn mein Programm das einzige ist was läuft. Doch, auch dann braucht man die MMU um den Cache zu konfigurieren. Man behält aber eben ständig die gleiche Konfiguration bei. Wobei: Wenn man das für "Singlethread" hinbekommen hat ist das Umschalten beim Kontextwechsel dann auch nicht mehr so weit weg. Lothar schrieb: > Und es ging doch darum Cortex-A wie Cortex-M als uC zu nutzen oder? Ja? War mir nicht klar. Lothar schrieb: > SWI "OS_Memory" ; MMU Heißt das nicht mittlerweile "SVC"...
Niklas Gürtler schrieb: > Heißt das nicht mittlerweile "SVC" Es ist derselbe ARM Opcode der je nach verwendetem Assembler als SWI (AASM) oder SVC (GNU Assembler) angezeigt wird.
Lothar schrieb: > Thomas O. schrieb: >> Game Boy Advance > > Der hatte einen ARM7/Z80 Dual-Core :-) Lief wohl auf CP/M mir war schon klar das etwas anderes gemeint ist. Kleiner Seitenhieb auf dieses Hijacking, früher hat man nach AVR gegoogelt und es kamen µikrocontroller von Atmel als Suchergebnisse heutzutage steht das für automatic voltage regulation, Arbeitsvertragsrichtlinien, Arbeitgeberverband der Deutschen Volksbanken und Raiffeisenbanken...
Lothar schrieb: >> Game Boy Advance > Der hatte einen ARM7/Z80 Dual-Core :-) Lief wohl auf CP/M Der Z80 ist von Advance-Cartridges nicht nutzbar, und CP/M geht wegen des unpassenden Speicherlayouts auch nicht. Leider.
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.