Hallo Leute, vielleicht eine blöde Frage ... dennoch Warum muss man beim ARM (Cortex M3) beim Konfigurieren der GPIOs den Takt angeben? Vom AVR und PIC her, kenne ich es nicht. Gruß
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.
Jim Meba schrieb: > 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. http://de.wikipedia.org/wiki/Hern%C3%A1n_Cort%C3%A9s
Kan schrieb: > Jim Meba schrieb: >> 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. > > http://de.wikipedia.org/wiki/Hern%C3%A1n_Cort%C3%A9s Danke für den schnellen Link ;-) Ich habe mit STM32F107 angefangen und habe noch keinen wirklich guten Überblick über die unterschiedlichen anderen Implementierungen (NXP, TI). @ A.K. Vielen Dank. Gruß
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.
Torsten S. schrieb: > 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. Ich benutze ebenfalls einen STM32F103VC6 mit intern 72Mhz auf einem MiniSTV32 Board. Das 3.5" TFT-Display (HY35A) ist auch mit einem SSD1963 Controller ausgestattet und schmiert bei mehr als 10Mhz an dem FSMC (GPIO) Ports an unterschiedlichsten Programmstellen ab. Ganz besonders wenn das Display viele schnelle Änderungen darstellen (also auch übertragen) muss, fliegt es weg. Ein Display Reset mit folgendem LCD_Init() macht das Display wieder hell (Background LEDs) und zeigt wieder an. Aus dem Datenblatt des SSD1963 bin ich noch nicht schlau geworden, was das Timing des SSD1963 im Parallelbetrieb angeht. Ich habe die GPIO's der FSMC Ports von 50Mhz auf 10Mhz gestellt und damit scheint es zu funktionieren. 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. Vy 73 de Gerd
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/
Martin schrieb: > Vom AVR und PIC her, kenne ich es nicht. Die GPIOs des AVR haben auch einen Takt (clkIO), schau Dir den Block "SYNCHRONIZER" im Blockschaltbild "General Digital I/O" an (Datenblatt Kapitel "I/O Ports"). Der Takt ist beim AVR fest verdrahtet, beim ARM selektierbar.
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
Denke mal, daß man damit die Treiberstärke der Pins einstellen kann. Je nach angeschlossener Leitung muß ja eine mehr oder weniger große Kapazität umgeladen werden. So kenn ich das von FPGAs. Es macht mich jedoch stutzig, daß hier eine Frequenz angegeben wird ohne weitere elktrische parameter oder Bedingungen anzugeben.
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.
Lothar Miller 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... ;-) Wieso wundert es mich überhaupt nicht, daß Du gleich wieder das Thema "Einsynchronisieren" aufgreifst... ;^) Ohne Witz: bei dem Begriff "SYNCHRONIZER" mußte ich gleich an Dich denken...
Ich habe vor einiger Zeit mal die Flankensteilheit untersucht, der Unterschied war nur sehr geringfügig, jedoch messbar! Allerdings habe ich an einem offenen Pin gemessen. Das bringt's wohl eher nicht ohne Lust zu messen.
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.