Kann ich beim STM32F4/L4 die DMA durch ein externes Ereignis triggern? D.h. bei jeder LO->HI Flanke an einem Pin sollen die nächsten 16 Bits an einem Port ausgegeben oder eingelesen werden. Irgendwie scheint diese Möglichkeit nicht vorgesehen zu sein oder ich habe es im Refmanual überlesen... Eine Notlösung könnte sein, mit der doppelten Frequenz auf einen Timer zu gehen und dann dessen Überlauf zum triggern verwenden, aber das will ich möglichst vermeiden. Jörg
Auf ein Input capture event kann man auch triggern. Eine andere Möglichkeit ist mir nicht bekannt.
Joerg W. schrieb: > Kann ich beim STM32F4/L4 die DMA durch ein externes Ereignis triggern? > D.h. bei jeder LO->HI Flanke an einem Pin sollen die nächsten 16 Bits an > einem Port ausgegeben oder eingelesen werden. Irgendwie scheint diese > Möglichkeit nicht vorgesehen zu sein oder ich habe es im Refmanual > überlesen... > Eine Notlösung könnte sein, mit der doppelten Frequenz auf einen Timer > zu gehen und dann dessen Überlauf zum triggern verwenden, aber das will > ich möglichst vermeiden. Interessante Frage, Vorschlag zielt in dieselbe Richtung wie mein Vorredner. Hab grad RM0090 - DMA1 / DMA2 request mapping offen. Bin am überlegen, was man da am besten verbiegen könnte. Wie schnell soll es denn laufen? Mit welcher Latenzzeit/Jitter? F40x: TIM1 / TIM8 Interrupt/DMA generation on the following events: – Update: counter overflow/underflow, counter initialization (by software or internal/external trigger) – Trigger event (counter start, stop, initialization or count by internal/external trigger) – Input capture – Output compare – Break input TIM2 to TIM5 Interrupt/DMA generation on the following events: – Update: counter overflow/underflow, counter initialization (by software or internal/external trigger) – Trigger event (counter start, stop, initialization or count by internal/external trigger) – Input capture – Output compare
:
Bearbeitet durch User
Als Ergänzung: Ich hatte das schon mal getestet für eine 8/16 bit Übertragung zu einem FPGA. Auf github gab es damals auch schon jemand, der Übertragungsraten mit so einer DMA-Parallel-Schnittstelle getestet hatte. Die Ergebnisse konnte ich damals verifizieren. Ich meine es waren zwischen 6-8 Takte/Wort.
Das hatte ich damals auch gelesen: https://www.st.com/content/ccc/resource/technical/document/application_note/7a/88/df/e3/d3/36/40/29/DM00169730.pdfhttps://www.st.com/content/ccc/resource/technical/document/application_note/7a/88/df/e3/d3/36/40/29/DM00169730.pdf
Nett, dass die das mittlerweile in eine Appnote gepackt haben. Hab grad nochmal nachgeschaut: Als ich 2013 geschnallt habe, dass die DMA-Engine Datentransfers in die verschiedensten IO-Register, inkl. GPIO-Register erlaubt, habe ich eine bis dato FPGA-basierte Baugruppe in eine STM32F4 Baugruppe umgebaut. Vorher-> http://harerod.de/applications_ger.html#SSI_TOOL1 Nachher-> http://harerod.de/applications_ger.html#SSI_USB Das oben beschriebene Input Capture erlaubt den SSI-Slave-Betrieb. SSI-Master geht über einfach über Timer. Irgendwie schade, ich habe seitdem keine Anwendung mehr gehabt, die ein FPGA erfordert hätte. War alles mit STM32-Peripherie zu erledigen. Interessehalber - kann man diese Funktionen mit den HAL-Oberflächen zusammenklicken? Ich habe immer den Eindruck, dass die HAL-Geschichten viele spannende Tricks unterbinden. Nebenbemerkung: kleinere Prozessorfamilien haben mittlerweile Logikeinheiten auf dem Chip integriert. Beispiel ATtiny214 CCL. Das wird dem TO nicht reichen, spart aber bei vielen Anwendungen externe Gatter.
Ganz neue, größere STM32-Serien haben einen DMAMUX, z.B. die STM32L5. Mit dem kann man direkt EXTI-Lines als DMA-Trigger verwenden.
Ziel der ganzen Sache soll VGA-Ausgabe sein. Ein externes CPLD (XC9572XL) habe ich sowieso vorgesehen, schon wegen des Jitter-Problems. Dieses CPLD liefert neben den Synchron- auch Word-Trigger-Signale und "shiftet" 16 Bits Input nach 4 oder 8 Bits Output. Ein STM32L496 hat genügend RAM, um 640x400 in 16 Farben und ggf. 2 Pages darzustellen, oder 320x200 in 256 Farben. Wenn ich pro DMA-Event 16 Bits übertrage, komme ich auf 6,25MHz Triggerfrequenz, was bei 100MHz "Übertaktung" 16 AHB-Zyklen je Transfer ergibt. Laut AN4031 würde ein Transfer maximal 11 AHB-Zyklen brauchen, womit ich auf der sicheren Seite sein sollte. So kann ich mit dem HSYNC einen Interrupt auslösen lassen, um die DMA neu "nachzuladen". Ursprünglich wollte ich das in Software realisieren (das funktioniert auch schon), aber es ist schon irgendwie verschwendete Rechenzeit. Wenn schon ein AVR (bei 25MHz) VGA-Ausgabe über externes RAM und einfache 3D-Berechnungen (incl. Z-BUffer) kann, dann sollte sich aus einem STM32 noch einiges mehr herausholen lassen... Jörg
Mmmh. Warum möchtest Du externe Synchronisierung für den Bildaufbau? Wie auch immer, das ist doch eine klassische Datenpumpe, getaktet von einem internen Timer. Besser wird der Jitter durch externen Trigger auch nicht nicht. Hobbyprojekt Einzelstück? Dann ist sowieso alles erlaubt was Dir gefällt.
Alles über Timer zu machen, war auch meine ursprüngliche Idee, dafür gibt es auch genügend Beipiele im Netz. Aber um den Jitter auszugleichen, brauche ich einen Puffer zur Synchronisation. Das besagte CPLD ist für mich dafür die einfachste Lösung und hat noch genügend Platz, um das gesamte Timing zu übernehmen. Da das CPLD die Daten erst 16 AHB-Zyklen nach dem Auslösen braucht, hat der Controller (bzw. seine DMA) 15 AHB-Zyklen Zeit, um das nächste Datenwort an den Port zu schaufeln. Das ist selbst in Software (zumindest in ASM) problemlos realisierbar. Bei der vorgesehenen Lösung muss die CPU nur bei jedem HSYNC die DMA neu initialisieren (Speicheradresse +genügend großen Counter setzen), Zuordnung der Bits zum R-DAC und Blanking übernimmt alles das CPLD. Damit bin ich auch flexibler bei der Auflösung. Und ja, es ist ein reines Hobbyprojekt. Wobei die damit gemachten Erfahrungen auch in andere Dinge einfließen können... Jörg
Joerg W. schrieb: > Alles über Timer zu machen, war auch meine ursprüngliche Idee, dafür > gibt es auch genügend Beipiele im Netz. Aber um den Jitter > auszugleichen, brauche ich einen Puffer zur Synchronisation. Das besagte > CPLD ist für mich dafür die einfachste Lösung und hat noch genügend > Platz, um das gesamte Timing zu übernehmen. Na denne - ich denke das passt für Dich so. Interessehalber - gemeinsamer Takt für CPLD/MCU? > > Da das CPLD die Daten erst 16 AHB-Zyklen nach dem Auslösen braucht, hat > der Controller (bzw. seine DMA) 15 AHB-Zyklen Zeit, um das nächste > Datenwort an den Port zu schaufeln. Das ist selbst in Software > (zumindest in ASM) problemlos realisierbar. ASM -> seeehr sympathisch. ;) > Bei der vorgesehenen Lösung muss die CPU nur bei jedem HSYNC die DMA neu > initialisieren (Speicheradresse +genügend großen Counter setzen), > Zuordnung der Bits zum R-DAC und Blanking übernimmt alles das CPLD. > Damit bin ich auch flexibler bei der Auflösung. klar, sehr einfache Umsetzung im STM32 > Und ja, es ist ein reines Hobbyprojekt. Wobei die damit gemachten > Erfahrungen auch in andere Dinge einfließen können... Schon schlimm, gelle? Irgendwann ist alles Arbeit... :D
> Interessehalber - gemeinsamer Takt für CPLD/MCU? Optional. Das CPLD bekommt seinen Takt aus einem 25MHz Quarzoszillator, den Controller versorge ich meist auch damit (evtl. heruntergetaktet) um mir den weiteren Quarz einzusparen. Notwendig ist es nicht, da das Ganze ja mehr oder weniger asynchron funktioniert. Den Videotakt aus der PLL herunterzuteilen halte ich für nicht sinnvoll, zumindest bei anderen Controllern (S12XE) gab es dann teilweise deutliche Jitter-Effekte. ASM bringt halt je nach Anwendung nochmal Einiges an Geschwindigkeit. Und mir macht es einfach Spaß... auch wenn ich in den letzten Jahren für viele Dinge vermehrt C verwende. Das CPLD trägt natürlich nicht zur einfachen Nachbaubarkeit bei, aber Projekte sind meiner Erfahrung nach heute in den meisten Fällen nur noch dann interessant, wenn sie auf BoardXY laufen und sich mit IDEyz unter Windows laden und übersetzen lassen. Aber diesen "Markt" überlasse ich lieber Anderen. Jörg
Joerg W. schrieb: > Ziel der ganzen Sache soll VGA-Ausgabe sein. Ein externes CPLD > (XC9572XL) habe ich sowieso vorgesehen, schon wegen des Jitter-Problems. Ich nehme an, Du willst die Daten per FMC ausgeben. Sofern nichts Weiteres an diesem Bus angeschlossen ist, würde ich behaupten, daß darüber die Daten ohne Jitter erscheinen. Das CPLD wäre damit überflüssig. Die DMA-Übertragung ist recht schnell und kann zudem gepuffert ablaufen. Der Flaschenhals bei der Ausgabe ist die Geschwindigkeit des FMC. Und dieser "Flaschenhals" synchronisiert die Ausgabe durch das eingestellte Timing. Dieses Timing begrenzt die max. Geschwindigkeit, und da immer schon neue, gepufferte Daten anstehen, bricht die Geschwindigkeit auch zu keinem Punkt ein. Selber verwende ich diese Art der Ausgabe bei TFTs, die natürlich völlig zeitunktitisch arbeiten. Aber Jitter ist mir nie aufgefallen, weshalb es auch mit CRTs funktionieren sollte. Im einfachsten Fall kannst Du ja mal das Synchronsignal für VGA erzeugen und es mit einem Monitor testen.
Joerg W. schrieb: >> Interessehalber - gemeinsamer Takt für CPLD/MCU? > > Optional. Das CPLD bekommt seinen Takt aus einem 25MHz Quarzoszillator, > ... Die STM32F4 PLL hat einen deutlich größeren Jitter als z.B. der F1. Auch ohne programmierte Bandspreizung. Das merkt man bei High-Performance Ethernet-Anwendungen. Ich weiß nicht, ob man das auf dem Monitor sehen würde. Ich hänge wenn möglich gerne alles auf einen Takt, da dann von der EMV her die Effekte besser abzuschätzen sind. > ASM bringt halt je nach Anwendung nochmal Einiges an Geschwindigkeit. > Und mir macht es einfach Spaß... auch wenn ich in den letzten Jahren für > viele Dinge vermehrt C verwende. Wobei ARM-Thumb-Assembler schon was besonderes ist. Speziell wenn 68k 30 Jahre und x86 25 Jahre her sind und man zwischendurch bevorzugt auf AVR unterwegs war. Allerdings gab es auch immer mal Gründe Z80, 8051, PicoBlaze / KCPM3 und anderen Kram zu programmieren. Selbstverständlich ist C Standard. Aber wenn man in der Serie Material und Batteriekapazität sparen kann, dann ist das ein super Vorwand für ASM. :)
> Ich nehme an, Du willst die Daten per FMC ausgeben Nein. Ich habe einen LQFP64 vorgesehen und da gibt es den m.W. sowieso nicht. Ich nehme einfach einen I/O Port (PORT B oder PORT C), die sind sowieso einmal da. Außerdem kann der FMC nur 8 oder 16 Bit, für 16 Farben bräuchte man dann trotzdem eine externe Hardware. Mit CPLD sollten eventuell auch 1024x768 monochrom oder gar mit 4 Farben möglich sein, dann halt mit 64MHz Pixeltakt. Und da das CPLD das Timing intern "abarbeitet", muss der Controller nur innerhalb von 160µs nach dem Trigger die neuen Daten an den Port anlegen. Das geht per Software problemlos und sollte mit DMA auch unkritisch sein. > Selbstverständlich ist C Standard. Aber wenn man in der Serie Material > und Batteriekapazität sparen kann, dann ist das ein super Vorwand für > ASM. :) Was heißt "Vorwand"? Ich habe nicht vor, irgendwas in Serie zu bauen. Warum sollte ich etwas in C programmieren, wenn ich es in ASM effizienter kann? Wobei ich für C mittlerweise meinen eigenen "HAL" in Form einer Library geschrieben habe (teilweise in ASM ;-) Jörg
Auch wenn es nur indirekt zum Thema gehört, mit z.B. dem STM32H743 sollte es doch eigentlich möglich sein, einen IBM PC oder Atari ST komplett zu emulieren. Aber dafür müsste halt das "Video-Ausgabe-Problem" gelöst sein, wobei bei den Textmodi DMA auch nicht weiter hilft. Jörg
Wo siehst Du denn das Problem beim STM32H743? Dieser hat einen TFT-Controller, der doch eigentlich passende Synchronimpulse erzeugen sollte. Ich frage mal anders: Welche Monitore möchtest Du denn überhaupt betreiben? Die H7xx haben 512 KB RAM an einem Stück, wenn man nicht ext. Speicher verwenden möchte. Das dürfte die max. Auflösung begrenzen. Für monochrome Bildschirme wird man eher eine Pixelausgabe per SPI anstreben, da damit der höchste Pixeltakt möglich ist. Bei wenigen Farben <= 256 kann man per CLUT + TFT-Controller sich sein Spektrum selber zusammenstellen oder per DMA bis zu 8 Bit parallel per FMC ausgeben. Was sinnvoll sein kann, hängt von den übrigen Anforderungen und vom konkreten Monitor ab. Die Lösung für diverse Monitore wird es nicht geben. Mit einem Nucleo-H7xx-Board könntest Du kostengünstig Testsignale erzeugen.
Joerg W. schrieb: > Auch wenn es nur indirekt zum Thema gehört, mit z.B. dem STM32H743 > sollte es doch eigentlich möglich sein, einen IBM PC oder Atari ST > komplett zu emulieren. Aber dafür müsste halt das > "Video-Ausgabe-Problem" gelöst sein, wobei bei den Textmodi DMA auch > nicht weiter hilft. ... Atari ST? Das wäre ja Nostalgie pur. Weiß gar nicht, ob meine Ataris noch laufen würden. Die wollte ich schon lange in gute Hände abgeben. @ m.n. Mein erster 260ST hatte 192kB ROM-TOS und 512kB RAM. Das ist schon sehr nahe STM32H743. Bis auf die Rechenleistung, da hinkt die 8MHZ 68k doch etwas hinterher. Bin gespannt, ob hier jemand gelegentlich einen Atari ST Emulator vorstellt.
:
Bearbeitet durch User
> Welche Monitore möchtest Du denn überhaupt betreiben? In erster Linie VGA und wenn RGB (Scart) mit abfällt, ist das nur recht. Für die kleinen TFT gibt es bereits genügend vorhandene Lösungen, aber das ist für mich nicht interessant. Für eine reine "Grafikkarte" ist der STM32H7xx meiner Meinung nach oversized, der wäre halt als Emulator-Basis interessant. Dann aber mit eigenem Board. Bei den Disco-Boards habe ich die Erfahrung gemacht, dass das Ganze schnell in wackelige Provisorien ausartet und man teilweise erst mal Onboard-Komponenten entfernen muss, um alle Signale störungsfrei nutzen zu können. Da ist mir eine selbst geätzte Leiterplatte mit ein paar Drahtbrücken lieber, aber das muss jeder für sich entscheiden... > Bin gespannt, ob hier jemand gelegentlich einen Atari ST Emulator > vorstellt. Es ist mir zumindest die eine oder andere Überlegung wert und ein 5120STF sollte eigentlich möglich sein. Der Monochrom-Modus ließe sich via SPI oder I2S realisieren, für die Farbmodi wird es aber "haarig", da der ST hier Bitplanes verwendet und DMA nicht weiterhilft. Ich habe mir zwar schon eine Lösung ausgedacht, die nur einen externen R2R DAC braucht, während der Bildausgabe ist aber keine Emulation möglich. Alternativ könnte man die Videoausgabe in einen zweiten Controller verlagern und beide via SPI oder parallel verbinden, welche die 32K Videospeicher+Palettenregister zyklisch überträgt. Im Moment steht da noch nicht viel bis gar nichts fest, es geht erst mal nur um Konzepte, und da gehört der externe DMA-Trigger einfach mit dazu... Jörg
Ich verstehe garnichts! Marcus H. schrieb: > @ m.n. > Mein erster 260ST hatte 192kB ROM-TOS und 512kB RAM. > Das ist schon sehr nahe STM32H743. > Bis auf die Rechenleistung, da hinkt die 8MHZ 68k doch etwas hinterher. Atari, Amiga und Mac haben mich nicht interessiert - eher etwas für "Spieler". Aber 68k war natürlich auch angesagt. Der Vergleich der Rechenleistung ist etwas schwierig. Ich würde hier mindestens den Faktor 100 ansetzen, obwohl die Taktfrequenz ja nur Faktor 50 höher liegt ;-)
m.n. schrieb: ... > Atari, Amiga und Mac haben mich nicht interessiert - eher etwas für > "Spieler". ... Au ja, ich hätte nach fast dreißig Jahren mal wieder Lust darüber zu diskutieren, ob man mit einem Atari ST arbeiten kann. lol 68k Maschinensprache habe ich gelernt, um ein Speicheroszilloskop zu bauen. ADC am ROM-Port. Generell hat man mit GALs und PALs am ROM-Port schon viele Spiele treiben können. Joerg: Man muss halt überlegen, wie man den Shifter nachbaut. Grundsätzliche Varianten: - Mit Farbtabellen-LUT im externen CPLD. - zusätzlich zum eigentlichen 32kB Bildschirmspeicher schon fertig von der Emulatorfirmware aufgebaut im Speicher. Das sind dann aber 192kB (320*200*3 Byte RGB). Da man aber sowieso externen RAM setzen wird, warum denn nicht? - wie Du schon geschrieben hast: zweiter STM32 als Graka. Dadurch sind Emulation und Video weitgehend getrennt. Generell ist halt die Frage, wie gut man emulieren möchte. Softwareemulatoren sind ja schon sehr gut. Mit einem Hardwareemulator gewinnt man nichts, außer dass man es gekonnt hat. Wie auch immer, bin gespannt, ob wir von Deinem Projekt in der Zukunft was lesen werden.
> Au ja, ich hätte nach fast dreißig Jahren mal wieder Lust darüber zu > diskutieren, ob man mit einem Atari ST arbeiten kann. lol Ich hatte jahrelang einen MegaST mit Nova-Grafikkarte und später PAK68/3, danach einen TT und auch einen Zeit lang einen Falcon030, für den ich das erste Public Domain "Videoschnittprogramm" geschrieben hatte... Externen Speicher versuche ich zu vermeiden, weil sich das meist mit einseitigem Layout "beißt". > Mit einem Hardwareemulator > gewinnt man nichts, außer dass man es gekonnt hat. Das reicht doch, der Weg ist das Ziel... Und man lernt meist eine Menge, sowohl über das zu emulierende System als auch über den "Host-Controller". Danach verschwindet es irgendwo im "Archiv" oder wird "recycled", es ist halt ein Hobby. Für die "praktischen Dinge" haben bei mir hingegen meist weit kleinere Controller genügt. Jörg
Joerg W. schrieb: ... > erste Public Domain "Videoschnittprogramm" ... Coolest. Ich bin zwischenzeitlich auf Premiere umgestiegen. ;)
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.