Von ARM7 zu ARM Cortex-A ratsam?

Gast #5868212
Lesenswert?

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 :)
Persönliche Seite #5868222
Lesenswert?

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 :-)
Persönliche Seite #5868227
Lesenswert?

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.
Gast #5868748
Lesenswert?

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.
Gast #5868771
Lesenswert?

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...
Gast #5868774
Lesenswert?

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.
Gast #5869190
Lesenswert?

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
Gast #5869414
Lesenswert?

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"...
#5869442
Lesenswert?

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...

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren