ARM-uC mit möglichst schnellen GPIOs

Gast #1351398
Hi,

ich bin auf der Suche nach einem ARM-basierten uC (am liebsten einen 
Cortex-M3 wg. geringer Interrupt-Latenz), der möglichst schnelle GPIOs 
hat (Toggelfrequenz >= 16 MHz). Ich habe mir mal die Luminarys 
angeschaut. An sich sehr tolle Teile, allerdings benötigen die IOs wohl 
2 Takte zum setzen (bzw. löschen), so dass ich selbst mit der maximalen 
Core-Frequenz von 50 MHz "nur" auf 12,5 MHz Toggelfrequenz komme.

Luminary hat zwar was in der Pipeline mit der 9000-Serie, doch suche ich 
etwas, was jetzt schon verfügbar ist, und nicht mit etwas Glück in Kürze 
in homöopathischen Dosen und mit schlechter Tool-Unterstützung und 
fehlerhaftem Docs daherkommt.

Danke für Eure Vorschläge.

Gruß

Peter
#1351414
STM32 ist auch nicht grad schnell. Alle ARMs mit GPIO über 
Periphieriebus (APB) sind dabei tendentiell etwas langsam.

Schnell sind die LPC2000 (ARM7) in den einigermassen neuen Versionen und 
auch die noch ein bischen frischen LPC1700 (CM3), weil deren Fast-GPIO 
direkt am Primärbus (AHB) hängt. Aber da bei ARMs ein Store mindestens 
seine 2 Takte braucht sind auch da keine Wunder zu erwarten.

ARM ist zwingend? Ziemlich fix mit GPIO sind die PIC24H/dsPIC33 mit 1 
Takt, was bei 40MHz auf bis zu 20MHz am Pin rausläuft.
Gast #1351431
ARM ist nicht zwingend, nur ist da schon etwas Know-How und die Tools 
vorhanden. Das würde einiges einfacher machen. Die PICs schau ich mir 
mal an. Danke.

Sind die LPC1000er schon verfügbar? Ich dachte die sind auch noch im 
Sampling-Status.
#1351439
Habe ich auch so in Erinnerung. Deshalb hatte ich die ja "bischen 
frisch" genannt. Ausserdem tut man gut daran, nicht der erste Kunde zu 
sein, wenn man nicht als Bugsuchschweinchen dienen will.

Vielleicht sind die LPC2300 trotz weniger effizientem Interruptsystem 
verwendbar.
Gast #1356759
Und was soll das schnelle toggeln bringen ? Grosse Kapazitaeten mit 
kleinen Stroemen umladen ? Falls man das wirklich muss, koennte man einm 
CPLD/FPGA andenken. Aber auch da benoetigt man oberhalb einer Last einen 
Treiber.
#1356836
Tätigkeiten für die man bei Controllern sehr schnelle GPIO benötigt sind 
natürlich eher die Domäne von CPLDs und FPGAs, garkeine Frage.

Aber nicht jeder will die verwenden, Mancher steuert beispielsweise 
einen Bildschirm oder ein LCD ohne speziellem Controller direkt mit 
einem AVR an. Da kann ein schnelles und exaktes Zeitverhalten durchaus 
wichtig werden.

Bei sowas ist der ARM oder AVR dann eben zu beispielsweise 70% nur damit 
ausgelastet. Und? Für unverbrauchte Rechenzeit gibt's kein Geld zurück. 
Ein FPGA wäre teurer und grösser und braucht gänzlich anderes Knowhow.
Gast #1356849
> Bei sowas ist der ARM oder AVR dann eben zu beispielsweise 70%
> nur damit ausgelastet. Und?

Nun, ich nehme mal an, daß die Grundaufgabe nicht nur ist, einen Pin so 
schnell wie möglich toggeln zu lassen, sondern daß das Toggeln von 
irgendwas abhängig ist bzw. der Prozessor generell noch irgendwas 
anderes tun soll. Leider kann man aber in der Zwischenzeit nichts 
anderes tun. Schon ein Interrupt würde so lange dauern, daß das Signal 
für eine Weile unterbrochen werden muß. Und zwischen dem Toggeln noch 
andere Befehle auszuführen, ist auch eher schwierig, wenn man dabei dass 
Timing einhalten will.
#1356870
Hast du mal in Benedikts LCD-Codes reingesehen? VGA hat er wohl auch 
schon mal verbrochen. Das ist naturgemäss ziemlich zeitkritisch. Geht 
trotzdem.

Ich habe diverse Displays via VRAM mit Daten beworfen, mal mit AVR, mal 
mit STM32. Die Effizienz der Ansteuerung vom VRAM hängt exakt vom 
Zeitverhalten der GPIO ab, das geht deshalb auf dem AVR schneller als 
auf dem STM32.
Gast #1356889
Schnelles togglen ist zwar erst einmal ganz nett, aber eigentlich zu 
nichts nütze. Wie Rolf bereits schrieb, kann jeder Interrupt das 
schnelle Spiel lange Zeit unterbrechen.
Geschickter wäre es, ein UART/SIO (o.ä.) für schnelle Bitausgaben 
einzusetzen. Wenn der µC eine DMA-Einheit hat, könnte auch diese 
Bit-Muster unterbrechungsfrei und schnell ausgeben.

Externe Hardware (diskrete Logik, CPLD) ist natürlich aufwändiger, aber 
vom Timing vorhersehbar. Unter Umständen könnte auch ein kleiner, 
separater AVR für diese Funktion verwendet werden.
#1356898
Gast schrieb:

> Schnelles togglen ist zwar erst einmal ganz nett, aber eigentlich zu
> nichts nütze. Wie Rolf bereits schrieb, kann jeder Interrupt das
> schnelle Spiel lange Zeit unterbrechen.

Weshalb meine VRAM-Zyklen beispielsweise bei abgeschalteten Interrupts 
erfolgen. Bei <1µs kein Drama, je schneller die GPIO desto kürzer.

Und Benedikt verwendet deshalb garkeine Interrupts, ausser dem einen der 
die meiste Zeit verbrät und das Display steuert.
Gast #1356912
@A. K.

Selbst habe ich auch einen Tiny2313 so programmiert, daß er einen 
SAA1101 Sync.-Generator ersetzt. Ich weiss also, was Du meinst.
Dennoch sind das aber so spezielle Anwendungen, daß ich nicht danach 
meinen Hauptprozessor aussuchen würde.
#1356937
Es muss ja nicht gleich ein FPGA sein. Ein kleiner CPLD tuts meist, der 
kann problemlos taktgenause IO-Klimpern nebenbei machen. Denn füttert 
man dann halt langsam und zeitunkritisch. VGA erzeugung per uC ist zwar 
ne nette Spielerei, praktisch aber eher nur bedingt sinnvoll.

MFG
Falk

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 17 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.