mikrocontroller.net

Forum: FPGA, VHDL & Co. Universal LCD+Input Modul mit MachXO2


Autor: Markus W. (dl8mby)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/LCMXO...

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Duke,

was für ein Display und mit welcher Auflösung?
Ansteuerung über SPI oder parallel?

Markus

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Markus W. (dl8mby)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Upss, da ist ein falscher Link rein gerutscht, hier der Richtige:

Beitrag "MAX1000 Erfahrungen"

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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').

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt noch die FT800 Displays ( auch von Exacamera initiert, habe eine 
J1 drinn ):

https://www.mouser.de/new/ftdi/ftdi-FT800EVE/

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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-pro...

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-Sp...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder noch eine Kombination, wenn man Spaß mit FPGAs hat
https://www.mikrocontroller.net/attachment/346059/...

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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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-de...


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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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-Messkart...

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 ?"

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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
Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (dl8mby)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Martin S. (strubi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf Deinem Display steht "Papillo" und ich sehe die ZPU ... hast du es 
etwas mit der Arduino-IDE programmiert?

Autor: Markus W. (dl8mby)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Zpu hat 32 Bit.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Markus W. (dl8mby)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Einige meiner Fragen konnte ich mit dem nachfolgendem ST Doc
klären.

http://www.st.com/resource/en/application_note/cd0...

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.