Hallo Forum, ich möchte mir zwecks Übung und Spielerei, ein universal einsetzbare Platine machen, auf der ein LCMXO2-7000 sitzt und als Frambuffer Controller für ein LCD Display und Encoder und Push Button Input Frontend für einen STM32F7xx Controller dient. Da dieses Vorhaben wohl möglich mein jetziges Wissen etwas überfordert, wollte ich von Euch ein paar Anregungen haben, wie man das am besten bewerkstelligt und ob das nach Eurer Erfahrung mit dem o.g. MachXO2 (144 Pins) und knapp 7000 LUTs zu machen ist. Meine Grobe Vorstellung, wie ich es gerne hätte, habe ich in der angehängten Darstellung umrissen. Sinn und Zweck der Übung ist es den uC so zu entlasten und Ihn durch die Programmierung des FPGA's an verschiedene Displays anpassen zu können, ohne grundsätzlich die Programmierung des uC auf low Level Ebene ändern zu müssen. Für Anregungen und Hinweise schon meinen Dank im Voraus. Markus DL8MBY PS.: Möglicherweise reichen die 115 GPIO's für mein Vorhaben nicht aus und ich muss einen BGA Gehäuse nehmen oder das Breakout Board mit dem MachXO3, der hat an die 150 GPIO Pins.
Angehängte Dateien:
-
IO-Control-MW2.jpg
94 KB
:
Bearbeitet durch User
Ja, sollte eigentlich problemlos machbar sein. Ich würde für den Anfang das Evalboard von Lattice empfehlen [1]. Wenn doch irgendwas am Pinout nicht passt, läßt sich das mit einfachen Mitteln korrigieren. Duke P.S.: Die Idee kam hier letztens auch auf, aber inzwischen spielt das LCD am Memoryinterface vom STM32. [1] https://www.mouser.com/ProductDetail/Lattice/LCMXO2-7000HE-B-EVN/?qs=DBbQ3l7BldNJuSVNFnSpPw%3D%3D
Hallo Duke, was für ein Display und mit welcher Auflösung? Ansteuerung über SPI oder parallel? Markus
Markus W. schrieb: > was für ein Display und mit welcher Auflösung? beliebiges TFT 800x460 mit digitaler RGB-Schnittstelle (+ hysnc, vsync und pixelclock) > Ansteuerung über SPI oder parallel? Parallel. Wobei 16 Bit Farbtiefe m.E. ausreichend sind.
Hallo Duke, kannst Du das gesamte Bild im internen STM32F(X) RAM halten. Die haben ja in der 4xx bzw 7xx Variante nur um die 256k und das noch fragmentiert, wenn ich das richtig verstanden habe. Welchen uC nimmst Du für Deine Anwendung, wenn ich fragen darf? ich habe hier einige 4xx Varianten (429/439) und vom 7xx die (746) Variante. Verbaut auf den Disco Demo Boards, die man so auf den Messen bekommt. Markus
Markus W. schrieb: > kannst Du das gesamte Bild im internen STM32F(X) RAM halten. Nein. Wir haben hier Displaymodule mit dem "MD070SD". Da ist der RAM und ein Altera-FPGA mit drauf. So wie Du das geplant hast. Von den STM32 liegen hier vom 1er über den 4er bis zum 7er verschiedene da. Das TFT hängt gerade an einem 407. Die Variante mit eigenem FPGA fände ich aber auch flexibler... Duke
Moin, ich versteh nicht ganz, wo du hinwillst: - TFT mit eigenem RAM/Controller und 8080-'style' Interface (das suggeriert dein Schema) - Eigener Framebuffer (double buffer) im SRAM - dann würdest du optimalerweise mit dem entsprechenden Timing auf einen 'bare bone' TFT streamen Wenn du ersteren Typ TFT mit letzterer Logik immer refreshen musst, hast du ganz gehörig Overhead und ev. nicht die besten Refresh-Raten. Allenfalls kannst du dir auch Bus-Logik zwischen FPGA und uC sparen, wenn du nicht gerade riesige Bilder schickst oder Blöcke umkopierst. Du wirst ja irgend eine Art Charakter-Generator oder Grafik-API implementieren wollen, ne?
:
Bearbeitet durch User
Angehängte Dateien:
-
case_lcd.jpg
160 KB
Hallo Martin, meine Überlegung kommt daher, dass ich zwar ein 320x240 LCD Bild gerade noch in einem STM32F4xx halten kann, aber eben nicht mehr ein 480x320'er Bild. Da ein Entsprechend großer Dual Port RAM IC, z.B. von Cypress oder IDT schon an die 100€ kosten kann, wollte ich diese Funktion im Prinzip mit zwei konventionellen SRAM IC's unter Zuhilfenahme des MachXO2 od. -XO3 realisieren. Während ein SRAM Inhalt über den FPGA zum LDC geschickt wird, füllt der uC den zweiten SRAM mit Hilfe der Logik im FPGA. Wenn noch im FPGA Luft ist, soll er noch die Pushbuttons und die Encoder auswerten und als einfache Registerzelle die ermittelten Werte mittels Interrupt dem uC zur Verfügung stellen. So weit meine Vorstellung. Markus PS.: Im Anhang ein SDR vom Ortsverband I40, der gerade am Entstehen ist. Zuvor wurde das kleine 2.8" Display verwendet. Das 3.2" LCD hat die gleiche Anzahl von Pixeln (320x240). Das 3.5" LCD oder noch größere haben entsprechend mehr Pixel und da wird es im uC im internen RAM schon sehr knapp.
:
Bearbeitet durch User
ich denke, das 2. RAM kannst Du dir sparen. Ein ausreichend gross (tief) bemessenes FIFO sollte eigentlich ausreichen, um das Display zu versorgen. Der Zugriff auf das RAM braucht dann natürlich eine Prioritätensteuerung.
Hallo Markus F., ich bin gerade auf den Gameduino im Web gestoßen Siehe: http://excamera.com/sphinx/gameduino/ da kann man etwa sehen, wie die Macher einen Xilinx FPGA für eine ähnlichen Zweck ( SPI to VGA ) einsetzen. http://excamera.com/sphinx/gameduino/making.html Zum Fifo: Ohne ein Profi auf diesem Gebiet zu sein, würde ich rein aus dem Bauch sagen, dass man dabei nicht einen Bildinhalt in Hintergrund aufbauen kann, während das Fertige Bild aus den anderen RAM zum LCD geschickt wird. Somit kann man im Hintergrund z.B. eine GUI verändern, ohne das es störende Artefakte auf dem Display gibt. So hat man es zumindest früher gemacht, bevor es spezielle Graphic Controller gab, die darauf optimiert wurden und sogar VRAM angebunden hatten. In meinem Fall ist aber die Bildwiederholrate nicht so hoch, so daß man nicht so ein enges Timing beim Bildaufbau hat, das Signallaufzeiten schon kritisch werden. Markus
:
Bearbeitet durch User
Habe garade gelesen, dass die Gameduino im FPGA von Xilinx auch einen FIFO verwendet. Auch ein Processor "J0" ist im Verilog Code beinhaltet, um die Funktionalität des VGA Outputs zu gewährleisten. Siehe auch: http://excamera.com/files/gameduino/verilog/ Somit habe ich etwas Lesestoff um zu verstehen, wie dies bewerkstelligt wurde. Werde Deinen Vorschlag mit dem FIFO nochmals überdenken, auch wenn es im meiner Vorstellung ein gewisses Sträuben zu einer solchen Lösung gibt. Auszug aus dem Verilog Code: module fifo ( clk, datain, wr, dataout, rd, fullness); parameter WIDTH = 1; ... generate for (i = 0; i < WIDTH; i=i+1) begin : srl16 SRL16E fifo16( .CLK(clk), .CE(wr), .D(datain[i]), .A0(readaddr[0]), .A1(readaddr[1]), .A2(readaddr[2]), .A3(readaddr[3]), .Q(dataout[i])); end endgenerate ... endmodule module ring64( input clk, input i, output o); wire o0, o1, o2; SRL16E ring0( .CLK(clk), .CE(1), .D(i), .A0(1), .A1(1), .A2(1), .A3(1), .Q(o0)); SRL16E ring1( .CLK(clk), .CE(1), .D(o0), .A0(1), .A1(1), .A2(1), .A3(1), .Q(o1)); SRL16E ring2( .CLK(clk), .CE(1), .D(o1), .A0(1), .A1(1), .A2(1), .A3(1), .Q(o2)); SRL16E ring3( .CLK(clk), .CE(1), .D(o2), .A0(1), .A1(1), .A2(1), .A3(1), .Q(o)); endmodule module j0( input sys_clk_i, input sys_rst_i, output [6:0] insn_addr, input [15:0] insn, output mem_rd, output mem_wr, output [15:0] mem_addr, output [15:0] mem_dout, input [15:0] mem_din, input pause ); ... endmodule Markus
Du wirst sowieso ein FiFo brauchen, wenn Du deine RAMs nicht im Pixeltakt treiben willst (Taktdomänenübergang). Dann kannst Du's auch gleich so gross machen, dass dir genügend Zeit bleibt, den nächsten Frame vom µC ins Memory zu schreiben.
Markus W. schrieb >PS.: Im Anhang ein SDR vom Ortsverband I40, >der gerade am Entstehen ist. Zuvor wurde das >kleine 2.8" Display verwendet. Ich verwende ein STM32F746 Discovery http://www.st.com/en/evaluation-tools/32f746gdiscovery.html als Display und Controller in Kombination mit einem MAX10 Beitrag "Probleme mit USART-Interrupt's bei ATmega32 mit CodeVision" für die Signalverarbeitung. Das Display des Discovery ist mit 4.3 Zoll ausreichend groß und hat ein capacitve Touch, das sich ganz gut bedienen lässt. Man hat auch den Vorteil, dass man nicht groß das zusätzliche RAM und Peripherie dran löten muss. Das MAX10 ist gegenüber einem MACHX02 besser für SDR-Anwendungen geeignet, weil es Hardware-Muliplizierer hat.
Hallo Chris, bedeutet das, dass Du das RF-Board des SDRs an das 32f746gdiscovery dran gehängt hast, oder hast Du dir eine eigene Platine gemacht, mit dem MAX10, als Bindeglied zwischen dem RF-Board und dem ST Discovery? Markus
Ich nutze die Kombination für andere Zwecke und die beiden Baords sind per SPI verbunden. Die maximale Geschwindigkeit dürfte da so bei 20MBit/s liegen, ich nutze im Moment aber nur 2MBit/s. Der AD-Wandler des Discovery erlaubt meines Wissens nach 5MSPs. Damit könnte man schon SDR betreiben. Aber bei 200Mhz Clk bleiben da gerade mal 40 Zyklen für Filter, Downsampling und die Tasks der GUI. Da wären mir die "Handstände" zum Entwickeln der Software zu aufwendig um alles in die F7 CPU rein zu bringen. Der ADC des MAX10 ist ein wenig lahm für SDR. Die gerne verwendeten TV-Sticks haben meins Wissen nach 6MSPs IQ ADcs, da wäre der F7 nicht so weit weg. Welche Frequenzbereiche möchtest Du denn mit Deinem Aufbau abdecken? Ich würde den MAX10 und schnelle ADCs auf eine Platine setzen und die IF via SMA Buchsen von einem externen Mischer zuführen. Dann lässt sich der empfindlichere RF-Teil auch gut vom Digitalteil abschirmen.
Markus W. schrieb: > und knapp 7000 LUTs Das sollte ausreichen. Ich habe Bildschirm-Ansteuerungen mit einem 95144 gemacht und der hat auch ausgereicht. So und 800x480x2 ergibt 768k Byte, du hast 2x256x2Byte an RAM, reicht auch. 800x600 sollte auch grad noch so gehen. Normale Pixelraten sind bei 800x480 so etwa 30..35 MHz. Da du hoffentlich 32 bittig zugreifst, sollte das Ganze verträglich langsam werden. Dein Problem ist sicherlich was ganz anderes, nämlich das Synchronisieren zwischen dem Refresh-Ablauf und den Zugriffen des µC auf das RAM. Dafür sehe ich 2 Varianten: a) der µC hat nen Wait-Eingang, so daß er beim Lesen aus dem RAM für 1..2 Takte mal angehalten werden kann b) den µC kann man nicht anhalten, dann muß er so langsam zugreifen, daß man in der Zugriffszeit immer mehr als 2 RAM-Zugriffe machen kann: einer für den µC, der andere für den Refresh. Wird ein bissel knifflig. W.S.
@W.S. Ich habe mir das wie folgt gedacht: FPGA schreibt den Inhalt von SRAM-X so lange auf den Screen, bis der uC das SRAM-Y beschrieben hat und es zum Schreiben auf das Display frei gibt. X und Y sind jeweils 0 bzw. 1 und werden im Wechsel auf das Display gemapped. Timing und andere Feinheiten muss ich noch näher ausarbeiten. Dazu muss ich mich mit dem LCD Controller eingehend beschäftigen. Markus
Warum willst Du das TFT direkt an das FPGA hängen und nicht lieber an die MCU? Die wäre eigentlich schnell genug für Bewegtbilder.
@chris, aus zwei Gründen, die mir als wichtig erscheinen, Betonung auf erscheinen, möglicherweise liege ich auch verkehrt und lasse mich eines Besseren belehren: 1) die Größe des schnellen uC RAMS ist begrenzt, bis dato waren es meist weniger wie 256k. Erst jetzt kommen mit den STM32F/H/7xx Modelle auf den Markt, die mehr als diese üblichen 192kB haben und in Größen oberhalb von 512kB kommen. Zudem ist der Speicher nicht immer durchgehend, je nach embeddeten features im uC. 2) Um den internen schnellen RAM für DSP Aufgaben wie Filter, Koeffizienten-Tabellen etc frei zu haben. Ich hoffe das sind hinreichende Gründe. Dies Ansicht könnte für die neueren STM32 Familienmitglieder über- holt sein, die bereits einen CG für Displays auf dem Chip haben, wobei man dann aber die zugehörigen Libs diesbezüglich benötigt und auch verstehen muss. Ich hoffe mit der o.g. Methode etwas unabhängiger zu werden, zumal man als Hobbyist nicht auf die Tools der Profis zurückgreifen kann. Mir ist aber auch bewusst, dass eine solche Lösung einen mehr oder minder zum Einzelkämpfer macht und man weniger Gleichgesinnte für solch eine Vorgehensweise begeistern wird. So nun bin ich auf Deine/Eure Sicht gespannt. Markus PS.: Noch ein Grund ist mir in den Sinn gekommen. Die Schnittstelle vom FPGA zum uC ist für verschiedenen Displays immer gleich, da nur das Schreiben der Daten in den RAM des FB0/1 zu bewerkstelligen ist.
Ich versuche eigentlich immer, fertige MCU-Evaluation-Baords zu verwenden. Bis man alle Bauteile für ein Eigenes Design zusammen hat, ist man ewig unterwegs und die Bestückung kostet auch ziemlich viel Zeit, ganz zu schweigen von der Fehlersuche. Nur das Display auf dem Discovery würde wahrscheinlich einzeln schon um die 40Euro kosten. Aber es hängt natürlich von der Stückzahl ab und ob man ein Produkt daraus machen will. Wenn man nur 10 Stück macht, lohnt sich der Aufwand meiner Meinung nach nicht. Ab 1000 Stück und einem passenden Preis könnte es interessant werden. Deshalb verwende ich für meine Experimente das STM32F7 Discovery, das hat schon 8MB SDRAM drauf, was für das Display locker reicht. Wie und ob, das mit einer eventuell schnellen Signalverarbeitung auf der MCU in Konflikt kommt und das Ganze runter bremsen könnte, weiß ich aber nicht.
Ihr dreht euch da bisschen im Kreis...ich würde erst mal klären, was es für ein Display sein soll. Die Ilitek-Schwarten vom Chinesen (für wenige USD) haben meist eigenes Memory und einfache Blit-Befehle, da ist ein separater Framebuffer nicht nötig, da reicht für die Ansteuerung schon ein lahmer Minimal-Core. Das obige Schema zeigt zumindest ein Memory-Interface, kein Video-Interface, was den ganzen FB-Aufwasch nötig machen würde. Allerdings machen einem ab und an die schwer erhältlichen Datenblätter einen Strich durch die Rechnung, und dass ab einer gewissen Auflösung die Auswahl der TFT mit Videointerface doch wieder grösser ist.. Ansonsten finde ich die Lösung mit dem FPGA aber sinnvoll, insgesamt ist das womöglicher weniger Gefrickel als mit den zig verschiedenen Sitronix/Ilitek-Clones herumzuraten (BTDT, siehe auch 'dpf-ax').
@Martin Das Display hat einen ILI9481 drauf Siehe Link zum Datenblatt: https://www.crystalfontz.com/controllers/Ilitek/ILI9481/144/ Haben solche Displays einen Frambuffer drauf, der bereits zwei volle Bildinhalte puffern kann um einen im Hintergrund aufzu- bauen und den anderen derweil anzuzeigen oder wird nur ein Screenbuffer via OE (Output enable) auf den Screen durchgereicht. Markus
Soll das Projekt eine reine Display-Einheit werden oder soll auch richtige SDR-Signalverarbeitung durchgeführt werden? Hier mal ein SDR mit dem F7 Disco: https://www.youtube.com/watch?v=PoB8_zzgvlQ
Es gibt noch die FT800 Displays ( auch von Exacamera initiert, habe eine J1 drinn ): https://www.mouser.de/new/ftdi/ftdi-FT800EVE/
Noch einen kleinen Hinweis zu den Ili-Displays: Ich habe vor zwei Jahren mal eine Platine machen lassen, die so ein Display verwendet hatte. Leider gab es ein halbes Jahr später genau das Display mit dem Pinraster nicht mehr, sodass die Platine umdesigned werden musste. Mein Fazit: Keine Displays beim Billigversender kaufen, sondern welche, bei denen der Nachschub gesichert ist.
Hallo Chris, das SDR Processing wird im uC bewerkstelligt und damit dieser sich voll auf diese Aufgabe focusieren kann, die Idee mit der separaten Einheit aus FPGA, die das Display und das Tasten/ Encoder Frontend anbindet. Soll sozusagen ein Universal-Interface für kleinen Sende/Empfänger in der SDR Technologie darstellen. Mir ist klar, das man alles durch einen stärkeren uC bewerkstelligen kann, aber die Complexität steigt dabei zunehmend und die internen Abläufe im uC müssen, zumindest aus meiner Sicht, sehr genau verzahnt werden, was das Timing angeht und man braucht Werkzeuge, die ein RT-Debugging ermöglichen um Reibungspunkten auf die Schliche zu kommen. Wenn man die Anzeige und Ihr Timing entkoppeln kann, hat man doch einiges an internen Abläufen im uC, sozusagen ausgelagert und damit eine Vereinfachung geschaffen. Dieses Interface kann man dann immer wieder verwenden, ohne es durch den Wechsel des Controllers neu zu Programmieren. Ich habe somit vor die softwareseitige HAL von ST (nur was das Display angeht) durch eine "hardwareseitige HAL" eigener Bauart zu ersetzen. Markus
Markus W. schrieb: > Haben solche Displays einen Frambuffer drauf, der bereits zwei > volle Bildinhalte puffern kann um einen im Hintergrund aufzu- > bauen und den anderen derweil anzuzeigen oder wird nur ein > Screenbuffer via OE (Output enable) auf den Screen durchgereicht. Die haben Memory. Guck dir mal die Command-Liste an, wenn du das Datenblatt schon hast, kann nich mehr viel schiefgehen. Bei der Art TFTs von Crystalfontz gibt's kaum Probleme mit der Wiederbeschaffung. Fragt sich nur ob du über dieses Interface DMA mit dem STM machen kannst, damit deine CPU nicht arg ausbremst..
>Bei der Art TFTs >von Crystalfontz gibt's kaum Probleme Gibt es da welche mit Capacitive Touch und gutem Preis? Es gäbe ja auch noch die Möglichkeit, eine zwei MCUs zu verwenden. z.B. das F7 Disco als Displaycontroller und ein Nucleo F767 als Numbercruncher für den SDR-Teil: http://de.rs-online.com/web/p/entwicklungskits-prozessor-mikrocontroller/1231052/ damit fiele aber das schöne MACHX02 board weg. Aus Softwaresicht könnte man mit zwei MCUs den Aufwand schön trennen und die Programmierung wäre ähnlich. Es gib aber auch FPGAs mit SDRAM drauf Das MAX1000 hätte auch ein SDRAM, aber ziemlich wenig Anschlüsse. Es gibt aber auch andere wie z.B. das hier: https://www.aliexpress.com/item/New-XILINX-FPGA-Spartan6-Spartan-6-Development-Board-XC6SLX16-Core-Board-with-32MB-SDRAM-Micron-MT48LC16M16A2/32801899786.html?spm=2114.search0104.3.17.fTnVDJ&ws_ab_test=searchweb0_0,searchweb201602_3_10152_10065_10151_10068_10344_10345_10547_10342_10343_10340_10341_10548_10193_10194_10541_10304_10307_10060_10302_10155_10154_10056_10055_10539_10537_10536_10059_10534_10533_100031_10103_10102_5670015_10107_10142_10320_10321_5660015_10322_10562_10084_10083_10561_10177_10180_10312_10313_10314_10184_10319_5650015_10550_10073_10551_10552_10553_10554_10186_10557-10552,searchweb201603_30,ppcSwitch_5
Oder noch eine Kombination, wenn man Spaß mit FPGAs hat https://www.mikrocontroller.net/attachment/346059/IO-Control-MW2.jpg Das Eingangsschaltbild, aber statt mit einem mit zwei MCUs. Das FPGA dient dann nur als Glue-Logik. Eine MCU bearbeitet das Display, die zweite macht die SDR-Signalverarbeitung. Damit spart man sich auf viel FPGA-Programmierarbeit.
@Chris+Martin Die Idee mit der zweiten CPU hatte ich schon letztes Jahr, habe sie aber verworfen, weil ich beide über ein DP-RAM verbinden wollte, damit der FB für die GUI quasi transparent ist. Diese DP-RAMs sind aber bei Speichergrößen jenseits der 16kB Grenze schon sehr kostspielig. Das Model, von IDT mit 256k hat damals bei Mouser in Stückzahlen < 10 schon an die 100€ Netto gekostet. Deshalb grübele ich über die Variante mit dem FPGA, die zwei SRAM Bausteine als FB verwendet um den Schreibvorgang zum Display von dem Display-Protokoll abzukoppeln. Das wäre praktisch das, was der zweite Prozessor tun würde. Was die DMA Fähigkeit angeht, so weit habe ich noch gar nicht gedacht. Das wäre dann ein Sahnehäubchen als Addon. Ich bin heute ehe ins Grübeln gekommen, ob ich überhaupt mit dem MachXO2 Board mit den 115 GPIOs als Prototyp hinkomme, wenn ich 16Bit zum LCD und 2x 16Bit zu den SRAMs verwende und ob ich nicht das MachXO3 Board mit 150 GPIOs benötige. Alternativ könnte ich das Display und den FB im 8Bit breiten Daten beschreiben, was zwar die erforderliche Anzahl der IO-Pins reduziert aber die Zugriffszeiten verdoppelt. Und wenn alles klappen sollte, habe ich dann ehe nur 144-Pin Gehäuse zur Verfügung um die Platine zu layouten. Ich habe angefangen mir meine Signale zum Display und zum S-RAM in eine PPT-Folie einzuzeichnen und wenn diese fertig ist, werde ich mal hier das Ergebnis einstellen um Feedback von Euch zu erfragen. Markus
Wenn Dein Ziel die Trennung von Rechenprozessor und GUI-Prozessor ist, um die Software zu vereinfachen, würde ich keinen Grund für den Einsatz eines DualPortRam sehen. Die paar Daten zur Anzeige einer Kurve könnte man auch per SPI von einem zum anderen senden.
Hallo Chris, hallo Martin, und Mitleser, wenn Du Dir die Funktionalität des mcHF's und des neuen UHSDR's anschaust, siehe: https://www.amateurfunk-sulingen.de/mchf-projekt https://www.amateurfunk-sulingen.de/modifikationen#start https://www.amateurfunk-sulingen.de/forum/index.php?board=15 https://www.amateurfunk-sulingen.de/forum/index.php?board=18 https://github.com/df8oe/UHSDR https://github.com/df8oe/UHSDR/issues https://github.com/df8oe/UHSDR/issues/1089 dann wirst Du feststellen, das es z.B. einen gewissen Aufwand bedeutet das Wasserfall-Diagram in Echtzeit auf den Screen zu bringen und dabei die SDR Processe weiter abzuarbeiten. Bei den 405/407 512kB-Flasch und 429/439 2MB-Flasch Controllern der STM32F Reihe wird es mit dem 192kB bzw 256KB RAM und den 180 MHz CPU Takt schon knapp. Die STM32F7xx mit 216MHz und der STM32H7xx mit seinen 400MHz bieten da schon mehr Leistung, natürlich zu einem höheren Preis und man muss sich wieder intensiv mit den Libs auseinandersetzen um überhaupt die Möglichkeiten dieser uC Familien auszuschöpfen. Ich habe jetzt nicht den Anspruch die Beste Lösung zu finden. Wollte lediglich eine Variante schaffen, bei der ich schon den verwendeten Controller (bei mir den 429) weiterhin einsetzen kann, ohne schon am Anschlag der Leistungsfähigkeit des uC zu kommen und mit dem FPGA eine gewisse Reduzierung der benötigten Ressourcen (im uC) zu schaffen, indem ich den Anzeigevorgang vereinfache. Zudem sollte das Vorhaben als Übung für den Einstig in die MachXO2/3 Welt dienen, d.h. ein selbst gestecktes Ziel, auch wenn man es anders/besser machen kann. Man merkt ja dann an den Details, ob man sich auf den Holzweg befindet und sein Vorhaben revidieren muss. Markus
>dann wirst Du feststellen, das es z.B. einen gewissen Aufwand >bedeutet das Wasserfall-Diagram in Echtzeit auf den Screen zu >bringen und dabei die SDR Processe weiter abzuarbeiten. Schon klar, deshalb ja auch die Zweiteilung: Ein Prozessor macht die GUI ( Graphik ) und der zweite die "SDR-Prozesse" in Echtzeit und er wird nicht in seinem Rythmus durch Graphikausgaben gestört. Das das flüssig sogar in einer MCU z.B. mit dem F7 Disco geht, zeigt ja der Link weiter oben. Doublebuffering zur flimmerfreien Darstellung von Graphiken scheint mir ein gelöstes Problem zu sein, wobei ich aber nicht genau weiß, wie das beim F7 Disco gemacht wird. >Zudem sollte das Vorhaben als Übung für den Einstig in die MachXO2/3 >Welt dienen, d.h. ein selbst gestecktes Ziel, auch wenn man es >anders/besser machen kann. Man merkt ja dann an den Details, ob man >sich auf den Holzweg befindet und sein Vorhaben revidieren muss. Ich übe mich ja auch ein wenig in der FPGA Programmierung. Aber FPGAs sind sehr, sehr aufwändig zu programmieren. Gestern habe ich mal Testweise meinen Ein-Pin-ADC mit Digitalpin realisiert. Zum Test zuerst auf einem STM32: Dauer ca. 1 Stunde mit Test. Dann auf dem FPGA: Dauer ca. 6 Stunden mit Test.
@chris, ich habe schon in den anderen Threads gelesen, das Du Dich mit dem MAX1000 Dev Breakoutboard mit 8k bzw 16k CLB's und Quartus spielst. Lese auch immer wieder was so zu den FPGA's hier im Forum gepostet wird. Ich habe mir das DE10-Lite von TARIC bestellt, nachdem ich von Die den Hinweis mit den Multiplizieren bekommen habe. Der verbaute FPGA mit 50k CLB's hat 144 18x18 Mul Einheiten. Was ich damit anstelle muss ich noch sehen. Spiele mich erst einmal mit der Daimond SW von Lattice. Quartus habe ich zwar auch auf meinem Rechner aber noch nicht so viel damit gemacht. Muss mir mal wieder die aktuellen Version runter laden. Übrigens, bei Mouser gibt es auch ein FPGA Board, das interessant für SDR ist. (Mouser-Teilenr.:989-DK-DEV-10M50-A) http://www.mouser.com/ds/2/612/ug-max10m50-fpga-dev-kit-1099050.pdf Hat neben ADC/DAC mit SMA Anschluß auch einen Si570 in der 800MHz Variante drauf. Kostet aber ca. 165€ Netto. Preis hat mich noch etwas abgeschreckt, aber es kommt aber bald Weihnachten ;-) Markus
>Variante drauf. Kostet aber ca. 165€ Netto. Das geht dann aber kostenmäßig schon in Richtung des kleinsten RedPitaya https://www.reichelt.de/USB-Messlabor-A-D-Messkarten/STEMLAB-10-SK/3/index.html?ACTION=3&LA=517&ARTICLE=188113&GROUPID=4051&LANGUAGE=de&trstct=magaz_artlink Wobei man beim RedPitaya möglicherweise mehr mit der Entwicklungsumgebung als mit der Entwicklung beschäftigt sein könnte. Beitrag "Wer wird glücklich mit einem RED PITAYA ?"
Markus W. schrieb: > FPGA schreibt den Inhalt von SRAM-X > so lange auf den Screen, bis der uC > das SRAM-Y beschrieben hat und es > zum Schreiben auf das Display frei > gibt. X und Y sind jeweils 0 bzw. 1 > und werden im Wechsel auf das Display > gemapped. Huch? Also, ich versuche es mal so zu formulieren: Das gibt es einen RAM, und zwar ein durchgehendes Stück, das vom µC aus eben ein ganz normales Stück RAM ist, wo man also vom µC aus 8, 16 oder 32 bittig lesen und schreiben kann. Daneben wird dieser RAM aber auch von einer Display-Logik ausgelesen, die seine Inhalte in der nötigen Form pixel- und zeilenweise an das Display liefert, vor und nach dem HorizontalSync den jeweilig einstellbaren Freiraum einhält, selbiges auch in Vertilakrichtung tut - und dieses eben mit 40..60 Hz Bildwiederholrate. Damit hast du zu nicht vorhersagbaren Zeiten eben den Zugriff von zwei Instanzen (µC und Displaylogik) auf denselben RAM zu organisieren. Eben genau das ist der Knackpunkt. Wenn du genug Logik daür hast, dann kannst du dir einen FIFO für mehrere Pixel bauen und bei Zugriffen durch den µC ganz brutal den RAM exclusiv an den µC geben, solange der Zugriff dauert. Der FIFO muß dann diese Zeit überbrücken und danach schleunigst nachgeladen werden. Wenn du die Logik dafür nicht hast, mußt du pro Pixelzeit zwei Zugriffe einplanen: einer vom µC und der andere von der Pixel-Logik. Dann muß natürlich die Zugriffszeit beim µC entsprechend eingestellt sein, so daß in diese Zeit garantiert immer ein µC-Zugriff möglich ist. W.S.
@W.S. und die interessierten Foristen, schön erklärt und das ist auch eine Möglichkeit, wie man verfährt, aber ich habe etwas anderes im Sinn, ohne es aber verifiziert zu haben ob es so funktioniert. Werde ja dann beim Aufbau, bzw bei der Simulation sehen, ob es so klappt. Die zwei RAM's FB0 und FB1 sollen exklusiv für den uC und das Display verfügbar sein. Es soll niemals vorkommen, das der uC in das RAM schreibt, aus dem das Display gerade liest. Wenn der uC meint, dass er wieder einen neuen Bildinhalt ins RAM (FB0 oder FB1) schreiben will, führt das dazu, dass das Display seinen Lesevorgang auf das andere RAM (FB1 oder FB0) verlagert. Dies macht der FPGA, wenn der Schreibzugriff vom uC signalisiert wird. Egal von welcher Adresse das Display seinen Inhalt gerade bekommen hat, es liest jetzt bei der Adresse +1 des anderen FB's weiter. Das ist wie ein MUX, der nur die Adress- und Datenleitungen zwischen uC und Display vertauscht, wobei im FPGA noch der GC steckt, der das Timing V-Sync+H-Sync fürs Display erzeugt. Da es sich bei einer GUI für einen SDR nicht um laufende Bildinhalte wie bei einem Film handelt, ist der harte Wechsel zwischen den FB's wohl nicht so störend. Die einzelnen Elemente der GUI ändern sich nicht so schnell, wie der Bildrefresch-Takt von einigen Herz (10-30) am Display. So meine Überlegung. Ob ich damit Erfolg habe und nicht andere Unwegsamkeiten dabei auftreten muss sich noch zeigen. Damit ich für den Anfang das XO2 Board mit nur 115 GPIO's verwenden kann, werde ich erst einmal mit 8Bit Busbreite zum Display und uC spielen um zu sehen, ob das so generell funktioniert. Bis ich den nötigen VHDL Code dazu zusammen habe (abgeschaut, modifiziert, möglicherweise von Euch gereviewed) wird ehe etwas Zeit vergehen. Falls ich da einen Denkfehler habe, bitte ich um konstruktive Kritik. Markus PS.: DMA Transfer via uC ist dabei noch nicht im Spiel!
:
Bearbeitet durch User
Markus W. schrieb: > Falls ich da einen Denkfehler habe, bitte ich um konstruktive > Kritik. ich weiss nicht, ob das ein Denkfehler ist, aber hast Du berücksichtigt, dass mit double-buffering die Programmlogik eine andere sein muss, als wenn Du ein Display "normal" beschreibst? "Normal" bedeutet hier, dass Code üblicherweise davon ausgeht, dass alles, was aufs Display gezeichnet wird, zusätzlich zu dem erscheint, was schon dort ist (wie bei einem Pinselstrich, der über den vorherigen drübermalt). Mit double buffering ist das nicht der Fall (der letzte Pinselstrich fehlt, weil der nur im "anderen" RAM ist, das gerade angezeigt wird). Es sei denn, Du malst alles zweimal oder kopierst deine RAMs um.
@Markus F. Hallo Namensvetter, ganz kann ich Dir nicht folgen. Da ich ja zwei RAM Blöcke/Speicher habe, mappe ich den Inhalt des einen auf den internen Speicher des Displays, während der andere wohl möglich wieder vom uC beschrieben wird. Ich habe bei meinem Entwurf noch nicht die Optimierungs- Variante berücksichtigt, dass man nur die Änderungen überträgt und damit weniger Schreibvorgänge vom uC zum FB RAM hat. In einer weiteren Ausbaustufe haben dann die einzelnen GUI Elemente Positions- und Attribut-Werte, die dann gezielt an eine bestimmte Adresse im Speicher vom uC geschrieben werden. Dies ist aber nur ein SW Addon, das nur in der FW des uC berücksichtigt werden muss und nicht im FPGA. Ich hoffe mich nun etwas verständlicher ausgedrückt zu haben. Markus
Markus W. schrieb: > ganz kann ich Dir nicht folgen. Ich versuch's nochmal: wenn dein Programm bei einer "normalen" Displayanbindung Displayausgaben macht, wird das im einfachsten Fall (bei einem printf() z.B.) so aussehen, dass du was ausgibst und anschliessend nochmal was ausgibst. Beim printf() erwartest Du dann, dass die beiden Ausgaben direkt hintereinander auf dem Display erscheinen. Dasselbe mit Doublebuffering bewirkt u.U. (wenn zwischen den beiden Ausgaben eine Umschaltung stattfindet), dass Du etwas ausgibst und das Resultat des ersten printf()s auf dem einen, das zweite auf dem anderen Buffer landet. Effektiv musst Du also alle Ausgaben zweimal (in jedes RAM einzeln) machen oder dir in einem dritten Buffer den gesamten gewünschten Bildschirminhalt merken und immer den kompletten Framebuffer ausgeben. Jedenfalls ist die Programmlogik eine völlig andere als bei einer konventionellen Displayanbindung. Darauf wollte ich raus.
@Markus F. Entweder stehe ich auf dem Schlauch, oder wir reden aneinander vorbei. Um bei Deinem printf Beispiel zu bleiben nochmals meine Erklärung der gedachten Abläufe. Wenn der erste Schreibvorgang des uC auf den FB0 (SRAM0) ein printf ausgibt und der uC den FB0 frei gibt, fängt die Logi des FPGA's den komplette Inhalt dieses Speichers zu Display zu übertragen. (Bestenfalls schafft sie es ganz, d.h. alle Zeilen oder auch nur Teilweise.) Irgendwann erscheint dann an einer bestimmten Stelle die Ausgabe der Zeichen, die zu dem ersten printf gehören. Dieser Inhalt wird immer wieder ausgegeben, solange nicht die Aufforderung vom uC kommt den zweiten FB (FB1 alias SRAM1) zum Display zu senden. Fängt jetzt der uC den zweiten printf in den FB1 zu schreiben und gibt diesen wieder zur Übertragung ans Display frei, schaufelt die FPGA Logik den FB1 zum Display. Dabei wird der komplette alte Inhalt überschrieben. Ausgabe von printf #1 verschwindet und Ausgabe von printf #2 erscheint an irgend einer Position. Will ich printf #1 und printf #2 zusammen auf dem Display sehen, so muss ich sie auch zusammen in den FB hineinschreiben, der gerade zur Verfügung steht. D.h. der uC baut immer ein komplette Bildschirminhalt auf, gibt diesen zum Schreiben frei und fängt wieder an den anderen, noch im Hinter- grund verborgenen, zukünftigen Bildschirminhalt, aufzubauen. Habe ich da noch einen Denkfehler oder ist das jetzt klar, was ich will? Was ich noch überlege, ist ob ich am Display wieder bei Zeile #1 anfange, oder wie bereits vorher gesagt an der nächsten Zeile weiter schreibe, wo der Bildschirmzeiger stand und erst beim nächsten Bildaufbau der obere Teil des aktuellen SRAM's ins Display übertragen wird. Die Auswirkung auf den Bildschirminhalt kann man ja dann für beide Fälle betrachten und sehen, welche Methode besser ist. Wie ich schon zuvor schrieb, der Inhalt der Bildschirms ändert sich wesentlich langsamer, wohingegen der FB zig mal in der Sekunde zum Display geschaufelt wird (immer der selbe, z.B. FB0, bis dann irgendwann FB1 wieder zu übertragen ist). Markus
Markus W. schrieb: > D.h. der uC baut immer ein komplette Bildschirminhalt auf, gibt diesen > zum Schreiben frei und fängt wieder an den anderen, noch im Hinter- > grund verborgenen, zukünftigen Bildschirminhalt, aufzubauen. Der springende Punkt ist, welche Instanz dss Umschalten des Framebuffers vornimmt. Wenn das vom µC getriggert wird, sollte es funktionieren. Wenn der Videocontroller die Umschaltung selbständig durchführt (und beide Framebuffer auf der selben Adresse erreichbar sind), wird es haarig. Da würde ein FIFO zwischen den Framebuffern helfen: Ein Framebuffer dient nur zur Ausgabe des Bildes und der zweite nur für Schreib-/Lesezugriffe des externen Controllers. Ich denke aber, das die Speicher schnell genug sein sollten, um zwei Zugriffe pro Pixel machen zu können. Dann kommen sich Videoausgabe und Controller nicht in die Quere. Je nach Architektur wäre es auch denkbar den CPU-Zugriff zu verzögern, und den Schreibzugriff im Blanking-Interval zu machen. BTDT. Duke
Darauf will ich die ganze Zeit raus: Du hast potentiell einen Teil des gewünschten Bildschirminhalts im einen RAM und einen anderen im zweiten. Sinnvoll ist das nur, wenn Du immer den gesamten Framebuffer beschreibst. Also brauchst Du noch eine zusätzliche Instanz, die den gesamten Bildschirminhalt kennt. Wenn das Display dann noch eigenen Speicher hat, hältst Du den Framebuffer-Inhalt insgesamt vier mal ...
Hallo Duke, hallo Markus W. nur den uC weiss ja wann neuer Inhalt am Display zu zeigen ist. Deshalb schaltet der uC den FB0/FB1 um. Was mir noch nicht klar ist, ist die Frage, ob ein Display-Controler, wie er in den gängigen TFT Displays verbaut ist, in der Lage ist mitten im Ausgabevorgang auf irgend eine beliebige Zweile wieder bei Zeile #1 anzufangen. Hat der FPGA, der dem Display vorgeschaltet ist die volle Kontrolle über V- und H-Sync oder liefert er nur die Pixel für eine bestimmte Position am Display und muss das zügig innerhalb des Timings von V- und H-Sync machen gemacht werden, die intern vom Display vorgegeben sind. Ihr seht, das ich da noch gehörige Wissenslücken habe. Ich habe mir gestern von opencores den TFT controller heruntergeladen und sichte den Code um die Einzelheiten zu verstehen. https://opencores.org/project,lcd_controller Von meiner Vorgehensweise werde ich erst einmal ein statisches Bild vom uC ins RAM schreiben und am FPGA nur ein SRAM mit 8 oder 16 Bit breiten Datenbus anschließen, je nachdem welches ich schneller in meinem Bauteilfundus finde. Dann dieses Bild zum Display mit Hilfe des FPGA's übertragen und sehen, ob ich ein stabile Bildwiedergabe hin bekomme. Ich hoffe das klappt bei einer fliegenden Verdrahtung vom MachXO2 Breakoutboard zum Display, zur SRAM Lochrasterplatte und dem STM32F429 Discovery Board. Wenn der Aufbau steht werde ich ein Bild davon machen. Wenn das klappt, dann kommt der nächste Schritt mit dem zweiten RAM für den zweiten FB. Mit dieser Aufgabe habe ich schon genug zu tun und bin die nächsten Wochenenden ausgelastet. Markus
@Markus F. das hört sich so an, als wenn ich mir den ganzen Sims sparen könnte, wenn ich gleich ein ordentliches Display nehme - richtig? Gibt es somit Displays, bei denen der uC nicht sein Bild im eigenen internen RAM halten muss, sondern nur die Positionen/Attrbute der GUI Elemente im FLASH hält und diese einmalig ans Display überträgt und nur den Dynamischen Inhalt im RAM verwaltet und bei Bedarf zum Display schickt. Ich hab zwar auf Messen schon Display gesehen, die GUI Elemente bereits in ihrem internen Speicher halten, z.B. Tachometer, und die Übertragung eines Zahlenwertes zum Display setzt die Position/Winkel der Tachonadel. Diese Art von Displays war aber nicht geeignet um in einem Bereich z.B. eine Wasserfalldarstellung eines Spektrums zu zeigen, weil zu viel Daten übertragen werden müssten und das Display dafür zu Langsam ist. Markus
Markus W. schrieb: > Ich habe mir gestern von opencores den TFT controller > heruntergeladen und sichte den Code um die Einzelheiten > zu verstehen. > > https://opencores.org/project,lcd_controller wie hast Du das gemacht? In dem tar-Archiv, das man da runterladen kann, seh' ich keinen Code.
@Markus W. Du hast leider recht %-) Habe gestern noch nichts in TAR geschaut. Nun sehe ich das nur PDF's zum Display und zu der CPU im Archive enthalten sind, sowie eine PPT Datei im Unterarchive AP.zip. Also nur eine theoretische Betrachtung. Aufgrund der Filegröße von 4MB hatte ich gedacht, da wäre auch der VHDL Code drin. Wenn man aber genau hinsieht, steht beim Projekt Development status: Planning Siehe Anhang. Schade. Werde trotzdem die Doku genauer ansehen. Zum Trost: https://opencores.org/project,vga_lcd da könnte Code drin sein. Markus
Angehängte Dateien:
-
lcd.jpg
140 KB
Markus W. schrieb: > Gibt es somit Displays, bei denen der uC nicht sein Bild im eigenen > internen RAM halten muss, sondern nur die Positionen/Attrbute der GUI > Elemente im FLASH hält und diese einmalig ans Display überträgt und nur > den Dynamischen Inhalt im RAM verwaltet und bei Bedarf zum Display > schickt. Das wurde ja jetzt schon mehrmals betont. Hast du dir das Datenblatt zu deinem Controller mal angesehen? Und du hast es ja bereits schon entsprechend im Schema designt, da gibt's kein HSYNC/VSYNC oder Video-Interface. Pragmatisch gesehen kannst du dir also den ganzen Framebuffer und den FPGA Kram bei den Ilitek-Controllern sparen. Ich würde ihn mir sogar sparen, denn wenn das FPGA autonom die Ansteuerung der Blit-Engine machen muss, hast du einiges an Debug-Iterationen. So oder so macht ein Prototyping mit Direkt-Ansteuerung vom uC Sinn. Ich steuere die Art Displays auch direkt vom FPGA an, allerdings per Soft-Core. Das FPGA hat minimal RAM, die Charakter-Daten (und Bilder) sitzen im SPI-Flash. Ein printf() haut somit per popliges Blitting einzelner Charakter (4x8) eine Zeile an der Cursorposition raus. Scrolling wird dann kniffliger, geht nicht mit allen Displays, manche können intern Block-Copy, bei manchen muss man das RAM selber lesen/schreiben. Hab mal ein Beispielbild mit dem 128x128 angehängt, die Befehle sind aber für die grossen Displays meist identisch. Und du findest eine Menge Code für die Ansteuerung, wenn du nach "dpf-ax" googelst. P.S. Böse Stimmen würden sagen, dass man in der Zeit, in der man bei Opencores einen sinnvollen IP-Core gefunden hat, selbst was besseres geschrieben hat...
:
Bearbeitet durch User
Auf Deinem Display steht "Papillo" und ich sehe die ZPU ... hast du es etwas mit der Arduino-IDE programmiert?
Angehängte Dateien:
-
mchf.png
290 KB
@Martin S. es geht aber nicht nur um eine ASCII Ausgabe, sondern um eine Spektrum-Darstellung in der Art eines Wasserfallabbildes. Siehe Anhang! Optimal wäre ein Schreiben nur der Bereiche, die sich wirklich nur ändern. Für die ersten Versuche, werde ich aber den kompletten Bildinhalt transferieren. Das mit dem Mikrocore im FPGA ist bestimmt auch eine feine Sache. Was hast Du da für eine CPU gewählt? (8/16/18 Bit?) Markus
Markus W. schrieb: > @Martin S. > > es geht aber nicht nur um eine ASCII Ausgabe, sondern um eine > Spektrum-Darstellung in der Art eines Wasserfallabbildes. > Das ist schon klar. Ist aber technisch genau dasselbe, du kopierst einfach einen Bildbereich in einen Rechteck-Ausschnitt deines TFT-Memory. RTFM!!! Du brauchst den nicht mal gross zwischenpuffern, du schreibst einfach Zeile für Zeile deines Waterfall-Image direkt ins RAM des Controllers. Wenn du intern das Bild aufbaust und Bitmaps ins Memory kopierst, machst du in deinem Programm ja genau dasselbe. Keep it simple! chris schrieb: > Auf Deinem Display steht "Papillo" und ich sehe die ZPU ... hast du es > etwas mit der Arduino-IDE programmiert? Nein. Es ist auch nicht die ZPU, sondern die ZPUng :-)
:
Bearbeitet durch User
Angehängte Dateien:
Einige meiner Fragen konnte ich mit dem nachfolgendem ST Doc klären. http://www.st.com/resource/en/application_note/cd00201397.pdf Es ist also möglich die Displays nicht nur von der Busbreite SPI, 8, 9, 16 und 18 Bit mit unterschiedlichen Modes anzusteuern, es gibt auch die RGB- und VSYNC Interface Methode. Laut DB sind beim ILI9325 folgende Modes anwendbar, je nachdem was man für ein Displayverhalten fordert. Siehe angehängte Bilder. Markus
Angehängte Dateien:
-
MEM_FSM_STATE.png
57 KB -
TFT-Controller-Blockbild.JPG
79 KB -
CPU-Interface.JPG
62 KB -
TFT_Controller_640x480_a.jpg
220 KB -
TFT-Controller_640x480_b.jpg
230 KB
Schon ein bisschen älter jetzt hier der Treat.. Aber gab es denn irgendwann auch Ergebnisse daraus? Ich frage desshalb, da ich vor Jahren (2014? oder so) das Gleiche vor hatte. Habe hier nämlich noch mehrere 5,3" TFT Displays mit einer Auflösung von 320x240 und 640x480 am Start. Und ich habe es sogar fast geschafft diese mit einer Lattice FPGA XP2 anzusteuern. Also eigentlich funktioniert der TFT Controller. Es gibt halt irgendwo noch leichte Timing Probleme.. Als Speicher dient ein billiger SDRAM. Und um die verschiedenen Clock Übergänge (Einsyncronisierungen) zwischen Display Takt, SDRAM Takt und externer uC Schnittstelle zu schaffen, verwende ich dazu FiFo Zwischenspeicher. Also wie ist das Projekt von Markus hier denn nun ausgegangen?
Hier mal noch die beiden Bilder als pdf - damit man auch die Signale lesen kann ;)
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.