www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM-uC mit möglichst schnellen GPIOs


Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der LPC1768 trudelt dieser Tage gerade so bei den Distributoren ein. Bei 
Digikey ist allerdings noch ein Bestand von "0" gelistet.
Soll es ein kleiner uC sein, schau Dir doch mal den LPC2103 an, der hat 
bereits fast I/Os kostet wenig und kann bis 17.5 MHz toggeln.

Vielleicht hilfts ja :-)
Robert

Autor: ?? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir scheint es auch wenig sinnvoll, einen ARM mit dem Toggeln eines Pins 
zu 100% auszulasten.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.