Mahlzeit zusammen, Hab da ne Frage weil ich bald von AVR auf ARM umsteigen will. Wieviele MIPS hat denn so ein AT91SAM7S256 µC wirklich? Ich lese oft, dass sie 16/32 Bit Controller sind, heißt das jetzt, dass sie bei einem Clock Cycle 32 oder 16 Bit verarbeiten können (so wie die ATMEGAs 8 Bit)? Der Leistungsunterschied zu einem AVR muss doch gewaltig sein. Kann mir vielleicht jemand über die "Grenzen" dieser Controller sagen? Dann gibt es da noch die ARM9-er Reihe, die ja 180Mhz haben. Kann man sie alle über den gleichen Programmer in diesem Shop proggen??
Wie schnell so ein ARM im Vergleich zum AVR ist hängt (natürlich) von der Anwendung ab. Wenn die Aufgabe im Wesentlichen darin besteht IO-Pins zu toggeln, ist ein ARM nur dann schneller wenn er seine höhere mögliche Taktfrequenz ausnutzt. Die 32Bit nutzen ihm da nichts. Der ARM7 ist ein echter 32Bit Prozessor. Die 16/32Bit beziehen sich wohl auf die beiden Befehlssätze (Thumb/ARM). Im Thumb-Mode ist jeder Befehl wie auch beim AVR 16Bit breit. Die CPU arbeitet dann aber trotzdem mit 32Bit. Die Befehle sind nur etwas weniger leistungsfähig und man braucht daher oft mehr davon als es bei den 32Bit ARM-Befehlen nötig wäre um eine Operation durchzuführen. Unterm Strich spart man aber etwas Programmspeicher ein. Punkten kann ein ARM gegenüber dem AVR wenn viele 16/32/64Bit Operationen durchgeführt werden oder große Datenmengen von A nach B geschoben werden sollen. Zu den Grenzen erstmal eine Gegenfrage: Wo liegen deiner Meinung nach die Grenzen des dir schon bekannten AVR? Einen 60MHz ARM7 kann man noch als MP3 Player verwenden. D. h. ohne externen Dekoder. Für Linux ist mir der ARM7 etwas zu schwach. Das wird imho erst auf einem ARM9 mit zusätzlicher MMU interessant. Wegen des schon zwingend erforderlichen externen Speicher ist auch der Aufwand für einen ARM7 zu groß. Die JTAG Adapter können afaik alle ARM7/9 programmieren. Ich würde dir aber empfehlen mit einem ARM7 wie dem SAM oder dem LPC2000 zu beginnen. Für die Teile gibt es reichlich Beispiele im Netz und wenn dir die Leistung für irgendetwas nicht reicht kannst du dann immer noch auf den ARM9 gehen. Dann ist da noch der 'ARM7 Nachfolger' Cortex-M3. Luminary und ST bieten Controller mit diesem Kern an. NXP soll angeblich im Laufe des Jahres folgen. Der M3 hat einige Vorteile gegenüber dem ARM7, insbesondere beim Interrupt Handling und er kann in Hardware dividieren. Ich arbeite privat und beruflich seit knapp einem Jahr mit dem ARM7. Die meiner Meinung nach eher kleinen Vorteile des M3 rechtfertigen zur Zeit keinen Wechsel. Zumal die neuen Chips sich ersteinmal bewähren müssen. In diesem Jahr wird das sicher nichts mehr. Aber da du ja noch nichts mit dem ARM7 zu tun hattest sind die ja vielleicht etwas für dich? Wegen dem AT91SAM: Lass dich nicht davon beirren das Atmel so tolle 8Bit Controller baut. Der SAM ist ein ganz anderes Kaliber der mit dem AVR nichts zu tun hat. Orientiere dich lieber an den Datenblättern/Erratas verschiedener Hersteller (v.a. NXP) und den verfügbaren Beispielprogrammen. Vergleiche die Peripherie (verfügbare IO Leitungen), überlege dir ob du jede Schaltung mit dem JTAG Adapter programmieren willst und wie die Alternative aussieht.
Danke für deine Antwort. Worin für mich die Grenzen eines AVR liegen ist zum beispiel ein sehr einfaches Fernsehbild in s/w oder wiedergabe von midi dateien. Er kann einfach zu wenig mit seinen 16 MHz.
mit einem ARM könnte ich doch z.B. ein Farbbild erzeugen, einen MP3 Player auf Software bauen, USB Schnittstelle benützen, etc. etc.
Mal so ganz nebenbei, wo kauft ihr denn eure ARM µCs, in Österreich lassen sich die Dinger nicht so gut finden
>Die meiner Meinung nach eher kleinen Vorteile des M3 >rechtfertigen zur Zeit keinen Wechsel. Hmmmm, vernünftiger Interruptcontroller mit fester Latenz von 12 Zyklen anstatt Ärger mit spurious Interrupts und variablen Latenzen von 24 - 42 Zyklen, Bitbanding für schnelles I/O anstatt Load/Store sind also "kleine Vorteile"? Für mich sind das massive Vorteile. Einziges Argument für den ARM7 ist die Tatsache, daß bei ihm mehr Fehler bekannt sind, da er länger auf dem Markt ist. Für den Umstieg vom AVR auf den ARM ist der Cortex ansonsten sicherlich wesentlich besser geeignet.
Der Support für Thumb2 im GNU Compiler ist noch etwas dünn. Codesourcey hat das schon drin, aber GNUARM und WinARM m.W. noch nicht.
Thumb2 kommt erst im Mainline erst mit GCC4.3, aktuell ist aber noch GCC4.2(.2). In der Codesourcery Toolchain ist der Thumb2 Support allerdings schon eine ganze Weile enthalten, und sollte damit auch mehr als ausreichend stabil sein. @ Dieter: Die Interrupt Latenz dürfte für einen überwältigenden Anteil der User ziemlich egal sein, und wer schnelles Bitbanging braucht sollte wohl eher einen anderen uC verwenden, der die gewünschte Funktionalität in Hardware mitbringt. Der Cortex-M3 ist "nett", in meinen Augen aber v.a. eine Möglichkeit für ARM, neue Lizenzen zu verkaufen - ein schlagendes Argument, die bewährten ARM7 zugunsten eines Cortex-M3 aufzugeben sehe ich bisher nicht. @Stark Arm MP3 in Software dürfte einen 50MHz ARM7 ziemlich auslasten (ein 70MHz Modell hat dann also noch einige Prozent Reserve). Auf einem ARM9 mit 180MHz bleibt wohl eine Last von 20-30% übrig. Ein ARM9E mit seinen DSP Befehlen schneidet dann nochmal ein Stück besser ab. "USB Schnittstellen" in Form eines USB Hosts findest du nur bei größeren ARMen, z.B. AT91RM9200 (ARM920T), EP93xx (ARM920T) oder AT91SAM926x (ARM926EJ-S). Aber auch die sind allesamt Full-Speed, also maximal 12 Mbps. Eine Ausnahme bildet da der LPC24xx (ARM7TDMI-S), der einen USB Controller mit Device, Host und OTG Funktionalität mitbringt (auch nur Full-Speed). Hier bleibt aber die Frage, welche Funktionalität sich sinnvoll in dem ARM7 integrieren lässt - USB Speichersticks wären sicher möglich. Ein Farbbild zu generieren ist sicherlich möglich, die Frage ist, worauf du das Bild anzeigen möchtest. LCD Displays gibt es mit einer Vielzahl unterschiedlicher Interfaces, für VGA wirst du um einen zusätzlichen Chip kaum herumkommen. Einige ARM uCs bringen integrierte LCD Display Controller, teilweise gehen die aber zu Lasten der Systemperformance (StrongARM war da ein unrühmliches Beispiel). Wenn's bewegte Bilder sein sollen steigen die Anforderungen nochmals gewaltig an. Gruß, Dominic
Ich meine Hier eigentlich mehr so ein Projekt wie eine kleine PS - schau doch mal bei Wiki nach der PS 2 hat nicht mehr als 300 MHz (CPU). MP3 in Software wurde schon mit verschiedenen ARM mit < 50 realisiert. Ich kenne mich mit AT90Sam und LPC oder diesen M3 nicht so gut aus. Mir geht es vor allem um möglichst viele MIPS, gute und schnelle Interruptsteuerung und schnelle IO. Welcher Controllertyp ist da am besten von denen geeignet?
@Dieter: Das sind alles Gründe den M3 anstelle eines 8Bit µCs einzusetzen. Derzeit besteht ja noch eine beachtliche Kluft zwischen den 8Bittern und dem ARM7. Einen ARM nimmt man ja üblicherweise dort wo viele Daten bewegt werden müssen oder man eine relativ hohe Komplexität in der Software hat (z.B. Maschinensteuerung mit RTOS). Latenzen und primitive IO werden da immer unbedeutender. Sicher wird es dünn für den ARM7: Von unten kommt der M3 (obwohl der ja an sich nicht auf einfache Anwendungen beschränkt ist) und von oben der ARM9. Wer allerdings bereits den ARM7 einsetzt kann Stand heute aber dabei bleiben. Zunächst sind es Microchip, Atmel und die diversen 8051 Hersteller die den M3 fürchten müssen. @Stark Arm: Prinzipiell ist der M3 dem ARM7 gerade in diesem Bereichen überlegen. Schau dir aber die Datenblätter von den Controllern an und Vergleiche die Peripherie. Der Kern ist nicht alles. Für den Einstieg in die M3 Welt finde ich das LM3S6965 Eval-Board von Luminary recht interessant. Dieser STM32-Primer ist auch witzig. Doch ich habe auch so schon genug zu tun ;)
Stark Arm wrote: > Ich meine Hier eigentlich mehr so ein Projekt wie eine kleine PS - schau > doch mal bei Wiki nach der PS 2 hat nicht mehr als 300 MHz (CPU). Hast du dir schon mal die Technical Specifications der Emotion Engine angesehen? Da kann kein ARM auch nur Ansatzweise mithalten: - 64 bit Main CPU - FPU - zwei Vektor-Units mit je 9 Floating-Point Multiplizierern - zusammen 6.2 GFLOPs Dazu kommt dann noch der graphics synthesizer, ein "einfacher" 3D Grafik Chip, der die von der Emotion Engine aufbereitete Geometrie rendert und das Video-Signal generiert. Für I/O gibt's einen eigenen I/O Prozessor (ein ~30MHz MIPS Kern, der als Hauptprozessor in der PS1 zu finden war), und ein Sound-Prozessor kommt auch noch dazu. > MP3 in Software wurde schon mit verschiedenen ARM mit < 50 MIPS realisiert. Eben - ein 50MHz ARM7 kommt niemals auf 50 MIPS. Und wenn du dich nicht auf niedrige Bitraten beschränken willst wirst du etwas in dieser Größenordnung brauchen. Klar kann es sein, dass 40 MHz ausreichen, viel weniger darf's aber nicht sei.
Danke für die vielen Infos, ich weiß noch immer nicht wirklich mit welchen ARM ich weitermachen soll. Am liebsten würde ich bei ATMEL bleiben, weil ich auch viel mit AVR gemacht habe und ATMEL Produkte gut kenne. Reizen würde mich aber die LPC Reihe. @Dominic R.: Ich weiß, mit einem ARM9 wird man niemals eine PS2 machen können. Das Beispiel war mehr als Vergleich gedacht. Schau dir mal den Sprung von PS1 zu PS2 und den Unterschied zwichen PS2 und 3 an. Da ist das zweitere schon viel gewaltiger. Aber sowas wie eine PS1 sollte schon drin sein, auch wenn man einen zusätzlichen Farbsignal IC verwenden muss
Empfehlung: ARM7: LPC214x (NXP, Philips), ARM7: AT91SAM7X (Atmel), Cortex-M3: STM32 (STMicro). Angefangen mit ARMs habe ich mit dem MCB2140 (LPC2148) von Keil. Ein sehr schön zu programmierender Proz. Gut nach Datenblatt programmierbar, mit kleinen Hürden, wenn man aus der AVR-Welt kommt. Ansonsten sehr leistungsfähig, und nach etwas Einarbeitung auch nicht schwer zu programmieren. Als Cortex hat mich der STM32F103 von STM sehr überzeugt. Ich arbeite mit dem MCBSTM32 (Keil). Sehr einfach zu programmieren, wenn man eine Kleinigkeit, die hier beim GPIO anders gemacht wird, erst mal raushat (Hab da nen schönen Beitrag an anderer Stelle hier im Forum geschrieben). Ansonsten ähnlich einfach wie AVR, programmierung frei nach Datenblatt. Sehr schön: Debug-Modul und Core sind voneinander entkoppelt, so dass man durch verprogrammieren z.B. des Clocking nicht so leicht auf die Schnauze fallen kann. Weiterhin sehr leistungsfähig (Cortex-M3), sehr schnelles INT-Verhalten durch direkte Kopplung von NVIC und Core (der ist im CM3 Bestandteil des Core wenn man so will). Nettes Feature sind AntiTamper sowie eine Clock-Sicherung, die beim Ausfall der externen Clock auf die interne umschaltet, und die externe Clock auch automatisch wiederaufnehmen kann. Ohne dass der Core abschmiert. Super sind auch die von STM mitgelieferten structs für die Register. Programmierung a'la GPIOA->DATA=0xff; AT91SAM7X (Atmel SAM7X-Board) bin ich noch am Anfang (gerade erst bekommen, und da arbeite ich privat dran :-). Wie immer bei Atmel ein sehr schönes Datenblatt :-) GPIO etwas anders als AVR, aber auch simpel zu programmieren. Mehr hab ich noch nicht gemacht, doch ein Blick ins Datenblatt verrät, dass auch die Peripherals nicht schwer zu proggen sind. Auch beim Atmel finden sich diese schönen structs, die das Proggen erleichtern und die Register in Gruppen zusammenfassen. Alle diese Controller bringen einiges an Flash und RAM mit, was grössere Projekte oder einiges an zusätzlicher Software als eine Art OS neben der eigentlichen Firmware erlaubt (bei mir war es (m)eine Shell). The other Side: Beim LPC hab ich mich einmal ausgesperrt, hab versehentlich den JTAG-Port als GPIO konfiguriert. Nachdem ich bei Philips auf der Seite ein Flash Tool gefunden hatte, welches den Proz per serieller Schnittstelle programmiert, war das schnell wieder behoben. Beim STM war ich Anfangs etwas über die GPIO-Conf am Fluchen. Man setzt hier kein Pullup-Register, Data Dorection Register, Alternate Function Register, sondern alles in einem Rutsch in einem Register. Hat den Sinn, dass es beim Portumschalten keine Spikes gibt! Beim Atmel SAM7X hab ich mich erst mal dusselig gesucht nach einem Register, mit welchem man '1'en und '0'en gemeinsam auf ein Portregister schreiben kann. Der Port muss hierfür ein klein wenig anders konfiguriert werden. Kleinigkeit. Verwirrend am DEV-Kit ist nur, dass die LEDs bei '0' leuchten :-) VG, /r.
Stark Arm wrote: > Danke für die vielen Infos, ich weiß noch immer nicht wirklich mit > welchen ARM ich weitermachen soll. Am liebsten würde ich bei ATMEL > bleiben, weil ich auch viel mit AVR gemacht habe und ATMEL Produkte gut > kenne. Reizen würde mich aber die LPC Reihe. > > @Dominic R.: Ich weiß, mit einem ARM9 wird man niemals eine PS2 machen > können. Das Beispiel war mehr als Vergleich gedacht. Schau dir mal den > Sprung von PS1 zu PS2 und den Unterschied zwichen PS2 und 3 an. Da ist > das zweitere schon viel gewaltiger. Aber sowas wie eine PS1 sollte schon > drin sein, auch wenn man einen zusätzlichen Farbsignal IC verwenden muss Mit einem ARM7 wie LPC2000 oder AT91SAM7 wirst du auch die Leistungsfähigkeit einer PS1 kaum erreichen, selbst wenn du einen zusätzlichen IC für das Videosignal einsetzt. Die 4KB On-Chip ICache sind um einiges effizienter sein als der branch buffer der LPCs, die AT91SAM7 Linie verfügt garnicht erst über etwas Vergleichbares, und müssen für single-cycle operation im Thumb-Modus laufen, was den Code um ~30% aufbläst (und damit ähnlich viel Performance kostet, gegenüber einem System, das ARM Code ohne wait-states ausführen könnte). Insgesamt 3,5 MB RAM und 512 KB ROM verlangen nach einem AT91SAM7SE oder LPC22xx/24xx mit externem Speicher, was mangels Caches zu Performance Engpässen führen wird. Zu den 30 MIPS der CPU kommen dann nochmal 66 MIPS der Vektor-Einheit, eine Data-Decompression-Engine die es auf 80 MIPS bringt, ein Grafik-Chip der zumindest 2D Beschleunigung bietet, und ein Sound-Prozessor. Die PS1 kann hier dank hoher Parallelität einiges an Performance wettmachen, da Spiele wie fast alle Multimediainhalte sich naturgemäß gut zur Parallelisierung eignen. Ich würde mindestens zu einem ARM9 mit ~200MHz greifen, dazu noch ein Grafik-Chip, der zumindest häufige 2D Funktionen (Blitter, Sprites) in Hardware beherrscht. Gruß, Dominic
z.B. ein ARM926: EP9315 von Cirrus Logic. Läuft bei rund 200MHz, hat Caches und MMU on Board, sowie eine Grafikkarte, Sound, USB, Netzwerk, ... mit auf dem Chip. Ist für SetTopBoxen usw. entwickelt. Greetz, /r.
> Ich meine Hier eigentlich mehr so ein Projekt wie eine kleine PS - schau > doch mal bei Wiki nach der PS 2 hat nicht mehr als 300 MHz (CPU). Man kann Prozessoren nicht einfach nach der Taktrate beurteilen, denn es spielt eine große Rolle, was der Prozessor pro Takt erledigt. Bei der Emotion Engine der PS2 handelt es sich um einen MIPS R5900 Kern (sowas ähnliches wurde früher in Workstations eingebaut und hat mit Embedded nicht allzuviel zu tun) mit FPU und zusätzlichen Vektoreinheiten, wie Dominic schon erwähnt hat. Die CPU ist also hochgradig superskalar, was ein Embedded-Prozessor von der Stange üblicherweise nicht ist. Dazu kommt, daß die CPU bei aktuellen Spielekonsolen sich ohnehin nur um den generellen Ablauf, Künstliche Intelligenz und einen Teil der Berechnungen kümmert (bei der PS2 mehr als bei anderen). Die PS2 hat für die Grafik noch den sog. Graphics Synthesizer, bei dem das VRAM über eine 2560-Bit Bus (kein Tippfehler!) angebunden ist. Auch die alte Playstation hat mit einem 30 MHz MIPS R3000A nicht gerade die schnellste CPU, aber sie muß überwiegend die ganzen Spezialchips steuern: - SPU kümmert sich um den Ton - GTE macht geometrische Berechnungen - GPU rendert und schickt das ganze an den Fernseher Ohne solche Spezialchips bekommst du bestenfalls Grafik in der Art vom alten Pac-Man, Spaceinvaders oder Atari VCS. Selbst der C64 konnte nur über den (für damalige Verhältnisse) sehr guten VIC-II bessere Grafik darstellen.
Sehr interessant, solche Dinge wusste ich gar nicht. Woher denn, wenn man die ganze Zeit nur mit 8 Bit bei 16 Mhz beschäftigt ist.
Random ... wrote: > z.B. ein ARM926: EP9315 von Cirrus Logic. > Läuft bei rund 200MHz, hat Caches und MMU on Board, sowie eine > Grafikkarte, Sound, USB, Netzwerk, ... mit auf dem Chip. Ist für > SetTopBoxen usw. entwickelt. Der EP9315 ist, wie alle EP93xx, ein ARM920T, d.h. ARMv4T, und kein ARM926EJ-S, der ARMv5(TE) implementieren würde. Vorteil von ARM926EJ-S wäre unter anderem eine Reihe von DSP Befehlen, die Multimedia-lastige Anwendungen beschleunigen. Aber klar, generell wäre der EP9315 eine Möglichkeit, wobei ich leider nicht weiss, wie gut/schlecht dessen Graphics Accelerator ist. Vorteil wäre hier die vermutlich gute Anbindung an den ARM920T. Gruß, Dominic
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.