Mahlzeit! Mit einem STM32F407 möchte ich mehrere 16x16xRGB LED Panel ansteuern. Diese sind im Endeffekt nur Schieberegister ohne Multiplexing. (weil recht alte Panels von nem Dresdner Schrotti zum Kilopreis) Momentan missbrauche ich dafür die 3 SPI, aber ich brauche für das fertige Projekte davon 5 Datenströme. Also will ich 15Bit paralel über den GPIO Ausgeben per DMA. Das funktioniert auch schon ganz gut wenn ich ein statisches uint16_t Array aus dem SRAM2 Ausgebe und das bei 10MHz Ausgangstakt. Der STM32F407 läuft dabei auf 168MHz. Aufbau: TimerA enabled TimerB. Dabei Zählt er die Takte die Ausgegeben werden sollen um danach TimerB sofort stillzulegen. Der DMA End IRQ ist zu langsam, da würden dann noch ungewollte Takte kommen. TimerB läuft im PWM Mode mit 50/50 und gibt somit per GPIO den Takt aus und triggert beim Overflow den DMA. Der DMA ließt dann aus dem SRAM2 immer 16Bit und gibt die auf den GPIO aus. 1Bit ist dabei eben Beifang. Das geht auch schon ganz gut, aber wenn der ARM Kern selber mal auf den SRAM2 zugreifen muss, zum Updaten des Arrays, dann braucht der DMA zu lange um an die Daten zu kommen. Damit verschieben sich manche Ausgabewörter um eine Taktflanke -> doof fürs Schieberegister. Das ließe sich ja noch umschiffen indem nur nach einem "DMA fertig IRQ" geschieben wird vom ARM Kern aus. Aber für 12Bit Graustufen (Bit Angle Modulation, kein PWM!) und 120Hz Wiederholrate bräuchte ich so ~22MHz. Denn bei den jetzigen 60Hz Wiederholrate sieht mans noch leicht flimmern. Aber dann gibts direkt FIFO Errors vom DMA. Das bedeutet, dass er garnicht mehr schnell genug auf den RAM zugreifen kann. Nun die Fragen: Hier im Forum habe ich gelesen, dass die Busmatrix 12 Takte braucht um den DMA Zugriff zum SRAM zu routen? Gibts dazu irgendeine Quelle? Gibt es noch andere Möglichkeiten schnell Daten aus dem STM32 rauszupusten? Das muss nicht auf den F407 beschränkt sein. Ist die Busmatrix eines STM32H7 schneller? Der ARM Kern hat zwar 400MHz, aber das Bussystem nur 200MHz. Ich würde ja gerne nen FPGA nehmen, aber dann fehlts an BlockRAM von den hier rumliegenden Xilinxen. Von Lattice hab ich hiern dickes FPGA Brett mal geschenkt bekommen (da veraltet), der ist aber so groß, dass der nicht mehr mit der kostenlosen Toolchain läuft.
Zum Vermeiden von Missverständnissen: - du hast eine Art Framebuffer im SRAM, in dem deine Daten liegen - jedes Bit (0-14) in diesen 16-Bit-Worten entspricht einem SPI-Datenstrom - Wie viele Pixel bzw. Datenbits hast du? - Wie machst du deine BAM? Der Vorteil an der BAM ist doch, dass du teilweise Zeiten mit hoher Transferrate hast und dafür andere Zeiten in denen nichts los ist. Wäre es möglich, in der Zeit in denen du deine niedrigen Bits überträgst (= wenig Zeit zwischen den Transfers) die CPU einfach schlafen zu legen (oder sonstwie nicht auf den SRAM zuzugreifen)? - Woher kommt deine SPI-Clock, das ist der Timer B-Output? Ich vermute, das Latch machst du in Software? Eine Möglichkeit, das "Überspringen" der Daten zu vermeiden wäre die Clock zusammen mit den Daten auszugeben, z.B. in dem das aktuell ungenutzte 16. Bit einfach alterniert und eine externe Analogschaltung jede Flanke in einen Clockpuls verwandelt. Wenn dein DMA kurzzeitig hängt, würde dann zumindest auch die Clock hängen. Ist natürlich doof, weil dieser Jitter bei der BAM natürlich 1:1 in Helligkeitsschwankungen eingeht. Eine Sache die evtl auch gehen könnte wäre evtl. die Daten im CCM-RAM abzulegen und versuchen was mit dem FSMC zu machen. Da kenne ich mich aber nicht aus, vielleicht geht das gar nicht, vielleicht geht das gar nicht mit deiner Package etc. Bzgl. FPGA: Wie viel BRAM brauchst du denn? Das Lattice UP5K hat 1 MBit SRAM eingebaut, was bei 12 Bit RGB immerhin 29kpixel, oder 113 deiner 16x16-Panels. Kostet außerdem erbärmlich wenig.
Ich habe das gleiche Problem mal mit dem F407 für eine 64x64 Matrix mit 4 RGB Kanälen mit jeweils 16 Zeilen gelöst. Das Vorgehen ist das selbe wie du beschreibst. Ich takte auch mit 10,5 MHz und komme so bei 6-Bit BAM auf ca. 150Hz Bildrate. Entscheidend für das Timing war, die Daten für das GPIO-DMA und das Prescaler-DMA in das SRAM2 zu verlegen. SRAM2 ist über einen eigenen Bus an die Matrix angebunden und kommt daher nicht mit der CPU in Gehege. Das ist im Reference-Manual ganz gut beschrieben. pitschu
Hast du dir den LTDC angeschaut, den es in einigen F4 und H7 gibt? https://www.st.com/resource/en/application_note/dm00287603.pdf Interessant finde ich da folgende Aussage: "All other STM32 MCUs with no LTDC peripheral can directly drive LCD-TFT panels using FSMC and DMA. Refer to application note QVGA TFT-LCD direct drive using the STM32F10xx FSMC peripheral (AN3241)" - scheinbar kann der das selbe wie FSMC und DMA, aber eben besser. Außerdem das Bild auf Seite 17 - scheinbar ist nur ein Transfer über die Busmatrix nötig (Speicher -> LTDC und dann direkt raus) statt zwei Transfers mit DMA (Speicher -> DMA -> GPIO/FSMC) Ich bin in dem Thema aber kein Experte, hoffe aber dir trotzdem weitergeholfen zu haben. Wie kommst du eigentlich auf die 22MHz? 22MHz / 120Hz * 1/4096 Zeitauflösung = 44 Bit pro Frame? Und muss es ein ganzzahliges Vielfaches von 60Hz sein (weil du vorgefertigtes Video abspielst) oder gehen z.B. auch 90Hz (wenn du die Videodaten in Echtzeit erzeugst)? pitschu schrieb: > Entscheidend für das Timing war, die Daten für das GPIO-DMA und das > Prescaler-DMA in das SRAM2 zu verlegen. Bingo! Der ist auch nicht am IBUS und DBUS angeschlossen, kann also gar nicht um Buszeit konkurrieren.
:
Bearbeitet durch User
Der SPI war nur eine Vorgeschichte zur ersten Inbetriebnahme der Panels. Mit dem SPI wird garnichts mehr gemacht, das läuft jetzt alles über den DMA. Der STM32F407 hat 2 getrennte SRAM. In SRAM1 arbeitet der ARM Kern sein Programm ab (Stack und Daten). In SRAM2 liegt bisher ausschließlich der Framebuffer. Dieser Framebuffer ist schon "vorgekaut", also er enhält 12 Subarrays für die BAM Phasen und dann genug uint16_t für die Datenstromausgabe. Dank der Busmatrix können 2 getrennte Busmaster auf 2 getrennte Slaves zugreifen. > Wie viele Pixel bzw. Datenbits hast du? Im Endeffekt möchte ich 9x5 der Panels verschalten, also 144x80 Pixel. Das sind somit 11520xRGB Pixel. Das wird also ne Videowall mit >1m Breite. > Wie machst du deine BAM? Noch ein Timer zählt die Abstände die zwischen 2 "BAM Bursts" eingehalten werden müssen und der IRQ Handler dieses Timers stößt das oben genannte Timer/DMA Konstrukt an. Durch ein geschicktes Interleaving der großen BAM Pausenzeiten kann ich 9 Panels pro RGB Datenstrom speisen. Trotzdem wäre noch genug Zeit um Daten von SRAM1 nach SRAM2 zu kopieren. Aber dann bleib ich auf die 10MHz CLK festgenagelt, ich will ja 20MHz ;) > Ich vermute, das Latch machst du in Software? Das Latchen und Enablen der Schieberegister geschieht über IRQ Handler und darin weitere angestoßene Timer. Da ist es ja nicht ganz so kritisch ob das nach 5 oder 100 CPU Takten kommt. Glücklicherweise haben die STM32 Timer "ohne Ende". Ich hatte schon drüber nachgedacht die CLK als das übrige Bit auszugeben. Statt als HW Ausgang des TimerB. ABER! (So dachte ich bisher) Dann brauch ich ja den doppelten DMA Takt, weils ja 2 Taktflanken pro Takt braucht. Dann müsste ich 40MHz auf dem DMA erreichen und es gehen ja nichtmal 20MHz. Im Endeffekt tritt der FIFO Fehler so ab 12MHz auf. Dass das Bit toggelt mit dem halben Takt und eine Flankenerkennung macht nen Impulse draus is natürlich ne Idee kopfkratz. Der FSMC wär noch ne Idee, der haut doch aber zwischendurch immermal Adressen raus? > Wie viel BRAM brauchst du denn? Das Umwandeln eines Inputstreams könnt ich "on the fly" erledigen zum Buffer füllen. Eine Zeile hat 144 Pixel zu 16 Pixelbits. Das Ganze zu 12 BAM Phasen. und Double Buffering wär nicht schlecht. -> 144*12*16*2 = 55296 Bits. + Alphawerttabelle der Augenkennlinie. Hmm Moment, vorn paar Wochen hatte ich da noch was größeres ausgerechnet. Aber wenn man mal bedenkt, dass 10MHzx2Byte schon 20MByte/s sind, dann ist da wohl einfach das Ende der Fahnenstange der STM32 erreicht? @pitschu: Das liegt ja schon getrennt im SRAM2 und reicht für 10MHz. Aber ich will ja MEHR! (20MHz)
Da tippt man und es meldet sich noch wer ;) Den LCD Controller hab ich mir schon angesehen, aber der braucht mindestens eine Leerzeile (auch wenn man 0 in das passende Register packt). Womit sich die benötgte Datenratte verdoppeln würde. Ja, ich will 60Hz Videos abspielen können, daher ein Vielfaches. Aber auch die 90Hz als Notlösung schaffe ich bisher nicht. Die AppNote klingt interessant, die lese ich mir heute Abend mal durch. Die Frequenz muss so verdammt hoch sen, weil eben die kleinste Bit Angle Modulationsphase den Takt vorgibt. Dabei arbeite ich schon mit den Enables, weil der Takt auch so schon zu gering wäre. Wenn ich aber mit noch mehr Display aus Phasen arbeite wirds langsam recht dunkel. Bis runter zu 1/512 ist der Takt noch hoch genug, dass wärend der Bit Anzeige Zeit neue Daten reinkommen, danach arbeite ich mit dem OutputEnable Pin es Schieberegisters. Es hängen eben 3 Panels in Reihe.
Moin, das Problem hatte ich auch mal, und hab's mit nem Spartan6-LX9 erschlagen. Allerdings habe ich das Problem mit dem fehlenden BRAM recht aufwendig per SPI-Cache umschifft, dass genügend 'scratch pad' memory für die LED-Arrays übrigbleiben. Ist auch bei mir ne etwas andere Geschichte (Neopixel/WS2812). Für ne Einzel-Frickellösung greifst du wohl besser zum grösseren FPGA.
Mw E. schrieb: > Der FSMC wär noch ne Idee, der haut doch aber zwischendurch immermal > Adressen raus? So wie ich das verstehe ja, aber nur auf den Adresspins, nicht auf den Datenpins. Könnte natürlich sein dass durch die dadurch notwendigen Delays die Datenrate zu gering wird. Wie gesagt, kein Experte. Mw E. schrieb: > Aber wenn man mal bedenkt, dass 10MHzx2Byte schon 20MByte/s sind, dann > ist da wohl einfach das Ende der Fahnenstange der STM32 erreicht? Blöde Frage, aber - schon mal überlegt zu übertakten? 240MHz sind wohl drin (+43% ggü 168MHz), laut dem hier: http://sigalrm.blogspot.com/2014/01/overclocking-stm32f4.html und dem hier: https://stm32f4-discovery.net/2014/11/overclock-stm32f4-device-up-to-250mhz/ Oder soll das ein Serienprodukt werden das in-spec sein muss? Mw E. schrieb: > Im Endeffekt möchte ich 9x5 der Panels verschalten, also 144x80 Pixel. > Das sind somit 11520xRGB Pixel. > Das wird also ne Videowall mit >1m Breite. Warum nimmst du nicht zwei identische Controller und steuerst jeweils nur die Hälfte der Panels an? Dann hast du für ein paar Euros mehr die doppelte Datenrate. Musst halt ein Sync-Signal per Kabel weiterleiten und in Software vorsehen dass nur eine der beiden Bildhälften ausgegeben werden soll.
Deine Beschreibung habe ich nur überflogen; auf den 1. Blick erschließen sich mir die Anforderungen nicht so richtig. Aber ... Mw E. schrieb: > Nun die Fragen: > > Hier im Forum habe ich gelesen, dass die Busmatrix 12 Takte braucht um > den DMA Zugriff zum SRAM zu routen? > ... Ohne nachzusehen: 12 Takte sind absoluter Unsinn! Am schnellsten geht die Ausgabe auf den Datenbus. Seit Jahr und Tag erledige ich damit die Ansteuerung von TFT-Displays. http://mino-elektronik.de/TFT-direct-drive/TFT-direct-drive.htm#tft-4 Timer werden keine benötigt. Das Timing wird über die Einstellungen des Buszyklus eingestellt. Da die DMA-Ausgabe immer auf den gebremsten Buszugriff warten muß, gibt es auch keine Lücken bei der Ausgabe. Neuerdings verwende ich STM32F765, die höhere Geschwindigkeit und mehr RAM bieten. Der Bildspeicher paßt bequem in SRAM1, wobei SRAM2 und DTCM RAM für die CPU im ungestörten Zugriff bleiben.
Die Appnote mit dem LCD am FSMC hab ich jetzt mal durchgelesen. Da werden jetzt erstmal 3,6MHz Pixeltakt erwähnt. Weit weg von den anvisierten 20MHz, da wird die Busmatrix sicherlich auch wieder rumzicken. Noch was zum Hardware TFT/LCD Controller: Der muss zwar nur einmal durch die Busmatrix, aber das muss der DMA2 auch nur so oft. Der DMA2 hat ja 2 Busmaster eingebaut, somit kann er gleichzeitig auf den Slave Bus der GPIO Register zugreifen (AHB1) und auf den SRAM2. Die Busmatrix routet das ja paralel durch. @Philipp M. Übertakten wär natürlich auch ne Idee für das Hobbyprojekt. Halbes Display geht ja schlecht wenn die Panelanzahl der Spalten/Zeilen von 9 oder 5 /2 geteilt werden müssen. Dritteln ginge hingegen schon, wird dann aber aufwändig. Dann hab ich aber auch nur ein Panel pro Strang (mit dem 3x Interleaving) und komme locker mit 10MHz aus, ja. Die Pixeldaten sollten per Artnet angeflogen kommen, das bietet ja sogar ein SYNC Paket. Aber ob das für 120Hz Wiederholrate genau genug ist müsst ich erstmal herausfinden. Oder ein Master empfängt per Artnet und schiebt das wieder mit diesem 3x SPI für RGB weiter zu den Slaves. Der /CS ist dann der SYNC. Bei Elecrow bekomme ich eh mindestens 5 Platinen ;) @m.n. Welche ANforderung erschließt sich dir nicht? Da erklär ich gerne noch was. Die 12 Takte kommen durchaus hin. 168MHz/12 = 14MHz. Bei 10MHz funktioniert meine Ausgabe ja noch und so ab 12MHz gehts kaputt. Von euch weis jetzt aber wirklich keiner wo man die Info herbekommt wieviel Takte denn nun der Busmaster vom F4 und H7 braucht zum arbitrieren? Nachlesen würd ich das schon gerne. Kann aber auch, wie von dir gemeint, völliger Unsinn sein. (Der DMA brauch ja auch etwas Zeit zum Reagieren nachdem er vom Timer getriggert wurde) Deine TFT Ansteuerung per FSMC läuft mit 50MHz? Das klingt nach der gesuchten Lösung, da muss ich mal den Code durchstöbern. Guck dir mal den STM32H750 an. Kostet 5€, weil er nur 128k Flash hat. Ist aber sonst wie die großen ujnd teuren 20€ H7.
Die LPC4300-Serie von NXP (so ähnlich wie die STM32F4 von der Größe her) hat so ein "Serial GPIO"-Modul, mit dem man so etwas evtl. machen kann. 12 MB/s Datenrate habe ich damit jedenfalls schon umgesetzt, das war kein Problem.
Mw E. schrieb: > Mahlzeit! Moin! Was du schreibst, erscheint mir doch recht wirr. Du hast also eine Art Anzeigematrix für bunte Bilder, bestehend aus Moduln mit je 16x16 Pixeln RGB. Und nun versuchst du, sowas ohne jegliche externe Logik anzusteuern. Ich nehme mal an, daß dein Gesamtbild nicht allzu riesig ist, vielleicht 4x6 Moduln, macht zusammen 128x64. Wie kommst du bei so wenigen Pixeln auf Pixeltakte von 20 MHz? Ich sag's mal so: Du MUSST darauf achten, daß bei ungepufferten Schieberegistern die Schiebezeit, also die Zeit für's Update der gesamten Anzeige klein bleibt im vergleich zu der anschließenden Anzeigezeit. Also wenn du 50 Hz Wiederholrate haben willst, dann sollte die Schiebezeit etwa 1 ms dauern, dann 19 ms Anzeigezeit. Dann flackert auch nichts mehr. Also nicht besinnungslos die Taktrate hochtreiben, sondern das Verhältnis von Einstellen/Anzeigen richtig hinkriegen. So. Und warum soll es dann nun unbedingt ein STM32 sein? Guck dir lieber einen µC aus, der eine dedizierte TFT-Ansteuerung drin hat, z.B. LPC4088 oder so. So eine TFT-Ansteuerung geht auch per DMA, aber deren DMA ist in den Peripherie-Core eingebaut und (ganz wichtig) der Core puffert die Daten, so daß der DMA die Anzeigedaten paketweise und asynchron aus dem RAM holen kann und die Anzeige-Ausgabedaten an den Pins sind trotzdem taktsynchron und gleichmäßig. An deiner Stelle würde ich schlichtweg eine kleine externe Logik bauen, die das klassische TFT-Interface auf deine Anzeigematrix umsetzt. Dafür ist kein FPGA nötig, wahrscheinlich tut es bereits eine Prise gewöhnliche TTL-Chips. Du hast da ja RGB-Daten, Pixelclock, DE, HSynch, VSynch - das sollte ausreichen, zumal sich das timing in weiten Grenzen programmieren läßt. W.S.
Mw E. schrieb: > Die 12 Takte kommen durchaus hin. > 168MHz/12 = 14MHz. > Bei 10MHz funktioniert meine Ausgabe ja noch und so ab 12MHz gehts > kaputt. Bei GPIO würden sich 12 MHz eher aus 48 MHz / 4 ergeben. FMC hängt direkt an der AH-Busmatrix, hat zudem noch einen Schreibpuffer von 16 x 32 und ist damit affenschnell. > Deine TFT Ansteuerung per FSMC läuft mit 50MHz? Das dürfte etwas zu hoch sein und habe ich nie getestet. Bei QVGA oder WQVGA ist bei 20 MHz Schluß mit lustig, einfach zu schnell. > Guck dir mal den STM32H750 an. > Kostet 5€, weil er nur 128k Flash hat. Das mache ich! Mal sehen, wer die im TQFP100 günstig in kleineren Stückzahlen im Angebot und ab Lager lieferbar hat.
> Bei GPIO würden sich 12 MHz eher aus 48 MHz / 4 ergeben. Meinste ich hab die RCC/PLL Einstellungen vergeigt? Wenn der AHB nicht 168MHz hätte dann wäre die Baudrate vom UART aber komplett daneben. Die Debugausgaben kann ich aber wunderbar lesen, also wird das nicht das Problem sein. >> Deine TFT Ansteuerung per FSMC läuft mit 50MHz? > Das dürfte etwas zu hoch sein und habe ich nie getestet. Bei QVGA oder > WQVGA ist bei 20 MHz Schluß mit lustig, einfach zu schnell. Weil bei einem der TFT Bilder was von 50MHz stand, aber das war dann wohl der Takt dieses R210. Bei den STM32 TFT Bildern standen dann nurnoch die fps auf dem TFT. Die 20MHz wären dann knapp erreicht ohne Luft nach oben, probieren kann mans ja mal. Die H750 in TQFP100 gibts bei Mouser, verkaufen dir die Trumps aber nicht wegen dem AES Kern. Bei AVNET gibts den auch, sogar direkt ohne nervige Nachricht einer Exportbestimmung. In den Warenkorb legen geht schonmal, aber ich hab noch nicht bestellt. @WS: Also ich hab hier doch schon mehrmals geschrieben, dass ich 9x5 Panels verschalte. > Wie kommst du bei so wenigen Pixeln auf Pixeltakte von 20 MHz? Hatte ich auch schon geschrieben. Ich nutze Bit Angle Modulation, also ich muss 12Bit Graustufen in Software machen, weil diese Panels nur Schieberegister mit LEDs sind. Nichtmal Multiplexing gibts. Bitangle lässt die LEDs immer kürzer aufleuchten je tiefer es in die LSB reingeht. Also beim MSB ist die LED 1/2 Framezeit an, ein Bit niederwertiger dann 1/4 der Zeit. Bei 12Bit geht das also runter bis auf 1/4096 der Framezeit. Aber selbst da sind 20MHz schon zu wenig und ich muss daher schon mit dem OutputEnable der SRegister spielen (was übrigens auch im Original so gemacht wird). Soll heißen: währen der Anzeigezeit kann ich auch mit 20MHz schnell genug die Daten ranschaufeln ab dem Bit8. Noch weniger Takt würde aber noch größer OFF Zeiten bedeuten und das Panel würde dunkler. Ein panel will 12A bei 5V wenn alles an ist, mit meier Ansteuerung ist das schon bei "alles an" laut Bildpixeln bei nurnoch 8,3A angelangt. Hat aber den Vorteil, dass ich nur 12x Pixel reinschieben muss, bei 12Bit PWM Wärs 4096x. Warum nicht noch mehr Takt? Laut DB können die SReg nur bis 25MHz. Die Sreg sind gelatcht, also gepuffert. Du hast oben das Problem überlesen: Der DMA kann die Daten nicht mehr Taktsynchron raushauen. Es flackert also, weil dann die Daten falsch im SReg landen. Zudem will ich 120Hz, bei 60Hz sieht man noch flimmern. Privat nutze ich nunmal STM32, weil die Peripherie bis zum Abwinken haben. Die LPC sind da etwas spartanischer ausgerüstet. zB was die Anzahl der Timer angeht und von denne nutze ich grade ne Menge.
Mw E. schrieb: > Von euch weis jetzt aber wirklich keiner wo man die Info herbekommt > wieviel Takte denn nun der Busmaster vom F4 und H7 braucht zum > arbitrieren? Schau dir mal die AN4031 zum STM32 DMA controller an. Da wird detailliert gezeigt, wie viele Takte der DMA braucht.
Mw E. schrieb: >> Bei GPIO würden sich 12 MHz eher aus 48 MHz / 4 ergeben. > Meinste ich hab die RCC/PLL Einstellungen vergeigt? Nein, ich habe es vergeigt, weil die Zahlen so schön passten ;-) GPIO läuft über den AHB1 mit typ. 42 MHz. Da dort noch synchronisiert werden muß, war meine Annahme, daß 1/4 des Bustaktes ein plausibler Wert wäre. Mw E. schrieb: > Du hast oben das Problem überlesen: Der DMA kann die Daten nicht mehr > Taktsynchron raushauen. Mein Ansatz dabei ist, den DMA nicht zu einem Timer zu synchronisieren, sondern asynchron laufen zu lassen und anhand einer Daten- oder Adressleitung einen synchronen Impuls auszugeben. Die Datenausgabe synchronisiert sich damit selbst. Da Du 15 Bit benötigst, wäre das 16. Datenbit dafür frei. Ich erzeuge den Impuls (jeweils für Vsync und Hsync) über je eine Adressleitung. Vielleicht ist das für Dich machbar.
@m.n. Das überlesen Zitat galt WS ;) Dank der AppNote von pitschu blick ich jetzt wos knarzt: Dass die Busmatrix so lange braucht ist Murks, ja. Das SReg sampled bei einer LO->HI Taktflanke aus dem Timer (wenn der PWM Wert erreicht ist). Der Timer gibt das Overflow Event an den DMA zurück und dabei wird das Taktsignal wieder von HI->LO geändert. Der DMA hat jetzt also nur die halbe Taktzeit um getriggert zu werden und dann die Daten über die Busmatrix zum AHB1 zu den GPIO zu schreiben. Was 4 AHB Zyklen braucht, nicht Takte. Ein Zyklus besteht aus einer Adressphase und einer Datenphase also 2 Takten, weil es ein pipelined Bus ist. Das wird zu viel. +- Jitterkrams und wielange das interne antriggern von Timer->DMA baucht hab ich jetzt nicht lesen können in der AppNote. Da hilft auch mein FIFO trigger auf FULL mit nem BURST nicht mehr, der ist ja zum Daten nachschieben aus dem SRAM2 da. Nen übler Hack wärs jetzt auf das PWM Event zu triggern und auf die DMA Latenz zu hoffen, aber ne zu viel Hack ;) Ich werdmal im urlaub nach den Weihnachtsfeiertagen mit dem FSMC spielen, aber die Idee mit einem Controller pro drittel Display wär auch nicht schlecht. HSYNC/VSYNC brauchts nicht. Es müssen immer 16*16*3 uint16_t ausgegeben werden. (Eine drittel Zeile aus 3 Panels eben*) (Die Panels selber sind nicht zeilenweise steuerbar) Danach gibts den "fertig" IRQ. In diesem wird das Latch der Sreg gepulsed und danach ein Timer gestartet der das Output Enable in hardware ansteuert um die Bit Angle Leuchtzeit genaustens einzuhalten. Die Übertragung darf gerne etwas IRQ Jitter haben, aber eben keine Bits fressen. *die anderen beiden 3er Gruppen der Zeile aus Panels werden in den Übertragungspausen des ersten drittels bespielt. Bisher hab ich einen Testaufbau, der schon mithilfe eines mplayer Plugins Video auf 32x16 abspielen kann mit 60Hz und 12Bit Graustufen pro Farbe. Dank nicht gesyncten Kamerashutter flackert das aber wie s** https://www.youtube.com/watch?v=h9qx7ENijSQ
Wie oben schon geschrieben, aber vermutlich untergegangen, warum nicht das 16. freie bit als Taktsignal nutzen? Braucht dann halt doppelt so viel RAM. Der DMA müsste auch 32 Bit Worte aus dem RAM lesen und auf zwei 16 Bit Peripheriezugriffe mappen können. Dann spart man sich einen AHB Zyklus auf den RAM. Außerdem meine ich mich zu erinnern, das man irgendwo in der Busmatrix die Priorität der Master einstellen kann.
Andreas M. schrieb: > Außerdem meine ich mich zu erinnern, das man irgendwo in der Busmatrix > die Priorität der Master einstellen kann. Nicht beim F4, der hat fest Round Robin. Bei anderen ARM SoCs musste ich aber an sowas schonmal rumspielen ja. Andreas M. schrieb: > Wie oben schon geschrieben, aber vermutlich untergegangen, warum nicht > das 16. freie bit als Taktsignal nutzen? Braucht dann halt doppelt so > viel RAM. Der DMA muss dann aber doppelt so schnell sein, schafft er aber nicht. Die Idee war zudem nur zu toggeln und aus den FLanken den eigentlichen CLK zu extrahieren. Andreas M. schrieb: > Der DMA müsste auch 32 Bit Worte aus dem RAM lesen und auf zwei 16 Bit > Peripheriezugriffe mappen können. Dann spart man sich einen AHB Zyklus > auf den RAM. Es scheint ja eher DMA->GPIO Register das Problem zu sein. Das hatte ich zudem schonmal versucht, aber irgendwie war dann ein Dreher drinne und es kam totaler Datenmüll raus, da müsst ich nochmal nachforschen.
Mw E. schrieb: > Andreas M. schrieb: >> Wie oben schon geschrieben, aber vermutlich untergegangen, warum nicht >> das 16. freie bit als Taktsignal nutzen? Braucht dann halt doppelt so >> viel RAM. > Der DMA muss dann aber doppelt so schnell sein, schafft er aber nicht. > Die Idee war zudem nur zu toggeln und aus den FLanken den eigentlichen > CLK zu extrahieren. Hast Du vielleicht einen Schaltplan? Mir fehlt immer noch die Vorstellung, wie es genau ablaufen soll. Als Taktsignal bietet sich /WR an!
Uff, Schaltplan. Den müsst ich erst Zeichnen, das ist momentan ein fliegender Testaufbau bestehend aus einem F407 Discovery und einem 74ABT245 als 3.3V -> 5V Wandler. Hier das DB des SRegs mit den LED Treiber Ausgängen: http://www.siti.com.tw/product/spec/LED/SP-ST2221C-A.004.pdf SERIN: - STM32 GPIO Pin per DMA - PORTA CLOCK: - STM32 Timer Output Compare Ausgang - Timer triggert intern den DMA - PWM Mode mit 50/50 DC - Timer8 OCR1 PC6 LATCH: - GPIO Bitbongo im DMA fertig IRQ - PC0 nENABLE: - STM32 Timer Output Compare Ausgang zur genauen Einhaltung der BAM Zeiten - One Pulse Mode - Timer9 OCR1 PE5 Reicht das schon? Is ja eigentlich nur nen Schieberegister ;)
Mw E. schrieb: > Reicht das schon? Nee. Wie ein Schieberegister aussieht ist bekannt. Aber wieviel davon sind wie angeordnet und wie sieht das Muster aus, das ausgegeben werden soll? Wie wird das Tastverhältnis für eine einzelne LED erzeugt? Vielleicht bin ich auch schon zu alt für "blinkende Weihnachtsbäume" ;-)
Eigentlich war ja nur die Frage wie ich den DMA schneller auf den GPIO trommeln lassen kann. Wie man diese Panels ansteuert, da klär ich auch gern auf. Da muss ich aber mal in ein anderes Forum verweisen. In dem hab ich dokumentiert (als Fritzler) wie bisher die Ansteuerung läuft. Nicht verwirren lassen, dass da noch von SPI gesprochen wird. Diese SPI Ausgabemuster sollen ja paralelisiert werden damit 5 Panelzeilen statt einer am STM32 hängen. Bitte hier klicken: https://www.fingers-welt.de/phpBB/viewtopic.php?f=14&t=11610 Rückfragen dann wieder hier schreiben ;)
Mw E. schrieb: > Nen übler Hack wärs jetzt auf das PWM Event zu triggern und auf die DMA > Latenz zu hoffen, aber ne zu viel Hack ;) Nix Hack, so funktioniert synchrone Logik ^^ Da du aber eh dein Clock-Signal mit nem Timer erzeugst hast du doch den Luxus es beliebig verzögern zu können. Verzögere dein Latch-Enable-Signal doch einfach einige Takte, dann hat der DMA mehr Zeit. Sollte das Schieberegister 50:50 Tastverhältnis am Latch-Pin fordern oder du würdest die minimale High-Zeit unterschreiten könntest du zur Not einen weiteren Timer verwenden.
Hmm, ja, also doch, kommt auf die Experimentierliste. Als Hack versteh ichs, weil der DMA->GPIO Zugriff dann vllt zu früh kommen KÖNNTE. Aber lieber probieren statt zu labern. Das CLK zu verzögern wär auch ne Idee, dazu muss ich nur den DC Wert der "PWM" ändern, dann kommt die LO->HI Flanke später. Das Latch muss nichtmal aktiv verzögert werden, die IRQ Latenz ist da schon mein Freund. Der Latch Pin brauch eh kein 50/50. Dem SReg ist selbst der DC des CLK Wumpe, da gibts nur eine Mindestzeit die das Teil HI bleiben muss.
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.