Cortex: wozu Taktangabe für GPIO

Flankensteilheit. Wenn längere Leitungen dran hängen, dann produziert 
ein langsamer Pin weniger/keine Reflexionen.

Soweit jedenfalls die Theorie. In der Praxis konnte ich keinen 
nennenswerten Unterschied feststellen.

Martin schrieb:
> Warum muss man beim ARM (Cortex M3) beim Konfigurieren der GPIOs
> den Takt angeben?

Von welchem Cortex M3 reden wir? Die GPIOs werden von den Lizenznehmern 
unterschiedlich implementiert.

STM32, von denen kenne ich das jedenfalls.

soweit ich weiß kann man damit leider nicht die Flankensteilheit 
einstellen, sondern lediglich, mit welcher Taktrate das GPIO Modul 
getaktet wird. Das hat zur Folge, dass sich die Pins nur mit dieser 
Geschwindigkeit ändern lassen.
D.h. du kannst zwar schneller in die GPIO Register schreiben, jedoch 
werden die Änderungen niemals so schnell ausgegeben.

Ich bin mir dabei aber selbst nicht komplett sicher - korrigiert mich, 
wenn ich falsch liege.

Christian

Christian Aurich schrieb:
> soweit ich weiß kann man damit leider nicht die Flankensteilheit
> einstellen, sondern lediglich, mit welcher Taktrate das GPIO Modul
> getaktet wird.

Da diese Werte pro Pin definiert werden, nicht pro GPIO-Modul, scheidet 
das aus. Der Modultakt entspricht den APB-Takt, an dem das Modul hängt.

Zudem müssten diese Takte (2/10/50MHz) intern überhaupt irgendwie 
vorliegen, und dafür spricht nichts. Auch das in der Referenz 
aufgeführte Diagramm der Taktversorgung zeigt davon nichts.

Das Datasheet wiederum definiert ausdrücklich ein unterschiedliches 
Zeitverhalten, abhängig von der Pinkonfiguration. Nämlich 
Anstiegs/Abfallzeiten von max 5-12ns // 25ns // 125ns (F10x).

An meinem Discovery habe ich ein schönes buntes GLCD mit dem SSD1963 
Controller via FSMC angepappt. Mit ca. 15cm langen fliegenden Strippen.

Das geht auch, aber nicht wie in den Beispielen beschrieben mit 
50/100MHz sondern nur wenn ich GPIO_Speed_2MHz setze.

Hier läuft ein SSD1963 an 7" (800x480) zumindest rudimentär (ich stelle 
gerade auf NuttX um, daher verfolge ich die Richtung nicht weiter).

Zur GPIO-Clock: die Auswirkungen sind am Oszi schon recht deutlich zu 
sehen. Die Flankensteilheit ändert sich, dementsprechend auch 
Überschwinger usw.

DD4DA schrieb:
> erstaunlich finde ich, dass das an dem Board ursprünglich gelieferte
> Display (HY32D) mit einem SSD1289 ausgestattet zu sein. Der jedenfalls
> funktioniert mit 50Mhz GPIO Speed einwandfrei, was gegen die
> Empfindlichkeit des SSD1963 spricht. Leider habe ich noch keine
> preiswerten 5" und 7" Displays mit dem SSD1289 oder ILI9320 finden.

Gut zu wissen.

Ein anderes 3.2 Zoll Display (SSD1289) aus dem fernen Osten zeigt bei 
mir nämlich das gleiche Verhalten. Obwohl ich zur Initialisierung 
zunächst den Takt stark gebremst und viele Wartezyklen eingefügt habe 
komme ich über 2MHz nicht hinaus. Bei 10MHz reicht es die 
Schreibtischlampe ein/aus zu schalten dann ist dunkel.

Ohne FSMC, also mit Portpins wackeln, funktioniert zuverläßig. 
Allerdings gefühlte 10x langsamer.

Beim Microexplorer 3 der jetzt auch die Source Codes für die 
Pinconfiguration liefert, ist komischerweise immer 2Mhz als standard 
eingestellt, selbst bei SDIO ... kann das stimmen?

http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1533/PF251717?ecmp=microxplorer_enews_mth_mar2013

Martin schrieb:
> Warum muss man beim ARM (Cortex M3) beim Konfigurieren der GPIOs
> den Takt angeben?
Prinzipiell ist es einfach so, dass in den IO-Zellen eben nicht nur 
irgendwelche Treiber sitzen, sondern dass dort für viele Funktionen 
schon die erste Signalvorbereitung für den Prozessor stattfindet (z.B. 
Flankenerkennung für Pinchange-Interrupts usw.). Und große ASIC-Designs 
lassen sich nur mit synchroner (=getakteter) Beschreibung durchgehend 
verifizieren und simulieren.

BTW: Deshalb tauchen "asynchrone" Prozessordesigns alle 5-10 Jahre auf 
und verschwinden nach kurzer Diskussion wieder von der Bildfläche...
Zuletzt 2006:
http://www.tecchannel.de/test_technik/news/446217/hot_chips_taktloser_arm_prozessor/

Bronco schrieb:
> Der Takt ist beim AVR fest verdrahtet, beim ARM selektierbar.

In der Frage der IO-Taktung ist von ARM nicht vorgegeben, das definieren 
die Chiphersteller wie NXP, TI, ST selbst und dementsprechend 
unterscheiden sich die Chip in dieser Frage.

Bei den STM32 ist der Takt vom GPIO-Modul m.W. identisch mit dem Takt 
des IO-Busses (APB) an dem sie hängen. Der ist zwar wählbar, aber das 
betrifft dann auch die anderen IO-Module am betreffenden APB.

Bronco schrieb:
> Die GPIOs des AVR haben auch einen Takt
Da hatte Atmel bei den ersten AVR noch ein sporadisches Problem mit 
nicht einsynchronisierten Eingängen. Seit sie 2 Sync-Flipflops verwenden 
ist der Fehler weg... ;-)

Torsten S. schrieb:
> DD4DA schrieb:
>> erstaunlich finde ich, dass das an dem Board ursprünglich gelieferte
>> Display (HY32D) mit einem SSD1289 ausgestattet zu sein. Der jedenfalls
>> funktioniert mit 50Mhz GPIO Speed einwandfrei, was gegen die
>> Empfindlichkeit des SSD1963 spricht. Leider habe ich noch keine
>> preiswerten 5" und 7" Displays mit dem SSD1289 oder ILI9320 finden.
>
> Gut zu wissen.
>
> Ein anderes 3.2 Zoll Display (SSD1289) aus dem fernen Osten zeigt bei
> mir nämlich das gleiche Verhalten. Obwohl ich zur Initialisierung
> zunächst den Takt stark gebremst und viele Wartezyklen eingefügt habe
> komme ich über 2MHz nicht hinaus. Bei 10MHz reicht es die
> Schreibtischlampe ein/aus zu schalten dann ist dunkel.


Das hat doch nix mit dem Display zu tun, sondern mit der Terminierung. 
Wenn man mit so scharfen Flanken um sich wirft, sollte man wissen, was 
man tut! Wellenwiderstand

Uwe schrieb:
> Denke mal, daß man damit die Treiberstärke der Pins einstellen kann.

Das liegt nahe, es müsste sich aber im Datasheet als maximal lieferbarer 
Strom bemerkbar machen. Dort ist jedoch nichts verzeichnet.