Hallo, ich möchte euch meine High-Quality PAL-Grafikkarte für µCs vorstellen. Das ganze Projekt basiert auf einem XC3S200 FPGA mit 1MB Bildspeicher und hat folgende Features: - PAL Encoder Core ist geschrieben 100% in VHDL - 100% voll digital erzeugtes Video - 780x576 Bildpunkte mit 16Bit Farbtiefe - 1MByte asynchrones video RAM (Zwei Standard 512k*8 SRAM organisiert als 512k*16, Zugriffszeit 15ns) - "Cycle shared memory interface" performance: 60MByte/sec (30MByte/sec pro Bus, schreiben von >25 Vollbildern pro Sekunde sollte möglich sein) - RGB nach YUV Umwandlung - FIR-Tiefpassfilter für U und V Farbsignale - SPI-Interface - Farbbalken Testbild - Kleine Platinengröße: 86x53mm Der Source-Code (VHDL) + Board und Schematic Files (Eagle4.1) gibts hier auf OpenCores zum Download: http://www.opencores.org/projects.cgi/web/graphiti/overview Eine Projektseite mit zusätzlichen Result-Bildern gibts hier noch: http://www.pcb-dev.com/showsite.php?open=9b06c88f60ba370f0907df291db8826a Mein Lieblingsresult-Picture (per TV-Capture-Karte aufgenommen) gibts hier: http://www.pcb-dev.com/content/palenc/gallery/korean1.jpg Zum SPI: Das SPI Interface muss ich demnächst mal neu schreiben. Das läuft noch viel zu langsam, weils vom Konzept her falsch ist. Das werde ich demnächst mal erledigen. Ich arbeite an einer neuen Platinenversion die dann günstiger und kleiner werden soll. Ich will dann einen EP2C5 verwenden. Das dauert aber noch etwas ...
Ich habe das ganze schon seit längerem verfolgt: Respekt ! Die Bilder sehen echt wunderbar aus ! Ich wollte das ganze auch schon nachbauen, aber leider scheitert es an der Platine. (Selber machen geht nur schwer bis garnicht.) Falls es also mal eine Sammelbestellung Platinen hierfür geben wird: Ich hätte interesse. Wo bekommt man eigentlich die SRAMs ? Mir ist aufgefallen, dass asynchrone SRAMs in letzter Zeit ziemlich am Aussterben sind.
Spitze sache! Kannst du sagen was ne Platine incl. aller Bauteile kosten würde und welche Lötfertigkeiten man mitbringen muß?
@benedikt: > Ich wollte das ganze auch schon nachbauen, aber leider scheitert es an > der Platine. (Selber machen geht nur schwer bis garnicht.) > Falls es also mal eine Sammelbestellung Platinen hierfür geben wird: Ich > hätte interesse. Wenn die Umstellung auf Altera-FPGA klappt, sollte das Ganze kleiner und günstiger werden. Ich denke dann könnte man auch drüber nachdenken ein paar Platinen machen zu lassen. > Wo bekommt man eigentlich die SRAMs ? Mir ist aufgefallen, dass > asynchrone SRAMs in letzter Zeit ziemlich am Aussterben sind. Bei Schukat gibt es die. Da kostet ein 512k*8 mit 15ns rund 3EUR. @Läubi: > Kannst du sagen was ne Platine incl. aller Bauteile kosten würde und > welche Lötfertigkeiten man mitbringen muß? Ich hatte die neue Version mit rund 40EUR (inkl Platine bei 10Stück) überschlagen. Die aktuelle Version dürfte sowas um die 60EUR kosten. Die Lötfertigkeiten die man benötigt: Den FPGA gibts leider als QFP nur mit 0,5mm Pitch. Ein Haufen Flussmittel und eine Hohl-Lötspitze müsste das Problem aber lösen. Ich glaub Ulrich Radig (www.ulrichradig.de) hat da ein Video wie man SMD lötet. Mfg Thomas
Tolles Projekt! ABER: 1. Die Pixelfrequenz ist meiner Meinung nach zu hoch für FBAS, da die Bandbreite für das Y-Signal nur 5MHz beträgt. Das lässt sich aber relativ einfach ändern. Ein optionaler RGB-Anschluß wäre bei der hohen Auflösung sinnvoll. Bei Bildern mag das noch egal sein, aber bei Text und Liniengrafik ist dann womöglich nicht mehr viel von Farbe zu sehen. 2. Für etwas anderes als Bilderanzeigen halte ich hochauflösende farbgrafik am uC für zu langsam. Das hat nix mit dem vorgestellten Projekt zu tun sondern ist prinzipieller Natur. Ein AVR kann maximal 8MHz SPI bei 16MHz Taktfrequenz. Bei einer Auflösung von 700x500 und 16 Bit braucht es bestenfalls 0,7 Sekunden um das Bild zu löschen und 1,4 Sekunden um z.B. einen Text um eine Zeile nach oben zu scrollen. Hier bin ich auch schon seit langem am überlegen, wie ich so einer Grafikkarte ein bisschen "Eigenintelligenz" verpassen kann. Gruß Jörg
Joerg Wolfram wrote: > Tolles Projekt! > ABER: > 1. Die Pixelfrequenz ist meiner Meinung nach zu hoch für FBAS, da die > Bandbreite für das Y-Signal nur 5MHz beträgt. Das lässt sich aber > relativ einfach ändern. Ein optionaler RGB-Anschluß wäre bei der hohen > Auflösung sinnvoll. Bei Bildern mag das noch egal sein, aber bei Text > und Liniengrafik ist dann womöglich nicht mehr viel von Farbe zu sehen. Soweit ich weiß ist es erstmal nur wichtig die U und V Kompontenten auf 1,5MHz zu begrenzen. Das mit den 5MHz für Y ist mir bei meinen Recherchen wohl entgangen. Aber falls notwendig kann man noch einen 3ten FIR Tiefpass einbauen und das Y auch noch begrenzen. Sollte kein Problem sein. Wär aber interessant wie sich das wirklich auswirkt ... > 2. Für etwas anderes als Bilderanzeigen halte ich hochauflösende > farbgrafik am uC für zu langsam. Das hat nix mit dem vorgestellten > Projekt zu tun sondern ist prinzipieller Natur. Ein AVR kann maximal > 8MHz SPI bei 16MHz Taktfrequenz. Bei einer Auflösung von 700x500 und 16 > Bit braucht es bestenfalls 0,7 Sekunden um das Bild zu löschen und 1,4 > Sekunden um z.B. einen Text um eine Zeile nach oben zu scrollen. Hier > bin ich auch schon seit langem am überlegen, wie ich so einer > Grafikkarte ein bisschen "Eigenintelligenz" verpassen kann. Ja wenn es um komplette Bilder geht, geb ich dir sofort Recht. Sogar der SAM7 mit 20MBit SPI schaft nur knappe 3 Bilder/sec, vorausgesetzt er bringt die Daten schnell genug her. Wenn man nur kleinere Bereiche updaten will ist man natürlich wesentlich schneller, weil man den Adresspointer auf beliebige Adressen setzen kann. Man kann aber statt dem SPI-Interface auch ein Paralleles dranbaun. Das Memory-Interface schaft pro Bus 30MB/sec und das reicht für >25fps. In dem Projekt, für das ich den PAL-Encoder gebaut habe, wird es ein paralleles Interface geben. Aber für die ersten Tests war es so einfacher, weil dann ein Parallelport so tun konnte als wäre es ein SPI Interface :-) Mfg Thomas
Wäre es für die nächste Version dann möglich das parallele Interface vorzusehen (auch auf der Platine) ? Es wäre gut wenn es 8bit Daten, RD\, WR\ und dann noch 1-2 Adressleitungen (zur Umschaltung Daten/Adresspointer) geben würde. Damit könnte man dann theoretisch etwa 5MByte/s mit einem mega8515 oder noch mehr mit einem schnelleren uC erreichen. Das optimalste wäre Umschaltbar 8/16bit Bus, denn 16bit wäre ja warscheinlich das beste, da der Speicher auch als 16bit organisiert ist, und 16bit pro Pixel verwendet werden. Wie sieht das dann aus, beim Lesen der Daten ? Geht das, ohne dass Waitstates eingefügt werden müssen ? Der mega8515 erwartet nämlich wenige 10ns nach Anlegen von RD\ die Daten auf dem Bus. Man müsste also die Daten bereits im Voraus aus dem SRAM laden und im FPGA puffern, damit diese ohne Verzögerung direkt ausgegeben wird (was ja geht, da die Adresse vom Adresspointer bekannt ist).
Die 5MHz Tiefassfilterung sind nur wichtig, wenn bei 5,5MHz ein Tonträger sitzt, oder das ganze in einen 7 oder 8 MHz breiten TV-Kanal passen muß ohne den Nachbarkanal zu stören.
Benedikt K. wrote: > Wäre es für die nächste Version dann möglich das parallele Interface > vorzusehen (auch auf der Platine) ? Auf der aktuellen Version gibt es ihn ja auch, er ist aber nur für SPI verwendet worden. Auf der neuen Platine wird es die Stiftleisten dann wohl auch wieder geben. > Es wäre gut wenn es 8bit Daten, RD\, WR\ und dann noch 1-2 > Adressleitungen (zur Umschaltung Daten/Adresspointer) geben würde. Damit > könnte man dann theoretisch etwa 5MByte/s mit einem mega8515 oder noch > mehr mit einem schnelleren uC erreichen. Das optimalste wäre Umschaltbar > 8/16bit Bus, denn 16bit wäre ja warscheinlich das beste, da der Speicher > auch als 16bit organisiert ist, und 16bit pro Pixel verwendet werden. Speicherzugriffe mit 8Bit sind noch nicht vorgesehen, ist aber nicht so schwierig. Da kann man mal drüber nachdenken. Die Platform auf der ich den verwenden wollte geht eher so richtung ARM7, ARM9. Bei denen gibts ja 16Bit Interfaces. > Wie sieht das dann aus, beim Lesen der Daten ? Geht das, ohne dass > Waitstates eingefügt werden müssen ? Lesen? :-) Das Memory-Interface kann auch lesen, aber das kann momentan der SPI nicht und ich weiß auch garnicht ob das funktioniert. Müsste man mal ausprobieren. > Der mega8515 erwartet nämlich > wenige 10ns nach Anlegen von RD\ die Daten auf dem Bus. Man müsste also > die Daten bereits im Voraus aus dem SRAM laden und im FPGA puffern, > damit diese ohne Verzögerung direkt ausgegeben wird (was ja geht, da die > Adresse vom Adresspointer bekannt ist). Da bin ich mir noch nicht sicher wie ich das dann umsetzen will. Asynchrone Speicherinterfaces sind nicht so das Gelbe vom Ei. Momentan funktionierts halt so, dass synchron zu einem 15MHz Takt (ist auch der Pixeltakt) gelesen, bzw geschrieben wird. Man müsste sich das mal anschauen wie man ein asynchrones Interface dranbauen kann und was man für ein Timing im worst-case bekommt. Das mit dem im Voraus Puffern ist glaub ich garnicht so einfach. Wenn der Puffer leergelesen ist, müsste der Controller dann etwas warten bis Daten wieder verfügbar sind. Blockweise lesen/schreiben mit einer "Data-Available"-Leitung oder so wär schon was, macht aber alles wieder komplexer. Ich denk auch mal in die Richtung SDRAM-Interface ... zur Zeit hab ich ein Studienprojekt in dem ich ein SDRAM monitoren soll und da hab ich das Interface so gut wie fertig. Das würde dann auch richtig Gas geben bei Burst Zugriffen. Mfg Thomas
OK, wenn das Lesen noch nicht drin ist, dann kann man das auch weglassen. Das wäre nur das Optimale. Ein Asynchrones Interface zu synchronisieren ist echt schwer, daran bin ich auch schon gescheitert. Vor allem wenn das ganze schnell sein soll, und die Datenrate in Richtung Speicherbandbreite geht. Dann kommt man um ein FIFO meist nicht mehr herum.
Benedikt K. wrote: > OK, wenn das Lesen noch nicht drin ist, dann kann man das auch > weglassen. Das wäre nur das Optimale. Der PAL-Encoder ziehlte halt auch auf Systeme ab, die schon einen großen und schnellen SDRAM als Speicher verwenden - da fehlt 1MB als Puffer nicht unbedingt. Ich wollte daher eigentlich nichts zurücklesen. > Ein Asynchrones Interface zu synchronisieren ist echt schwer, daran bin > ich auch schon gescheitert. Vor allem wenn das ganze schnell sein soll, > und die Datenrate in Richtung Speicherbandbreite geht. Dann kommt man um > ein FIFO meist nicht mehr herum. Jo das ist nicht gerade Trivial. Schreiben würde noch gehen - da kann man die Signale einsynchronisieren und zwischenspeichern, bis die dann endgültig geschrieben werden. Aber für den Worst-Case-Fall kann es so ungünstig kommen, dass man ein haufen Waitstates einfügen muss und das Interface unangenehm langsam wird. Fifo wär eine idee - da müsste man aber noch ein Commando oder sowas einbauen, das dann zurückgibt, ob das Fifo Daten aufnehmen kann. Evtl kann man auch Interrupts erzeugen, wenn das Fifo leer ist. Ich denke das wäre die sinnvollste Lösung ... Mfg Thomas
Die Bilder sind echt beeindruckend!! Wie weit bist Du denn mit den mit dem Altera Design? Würde der PAL Encoder auch mit mit einem R2R DAC funktionieren? /OT Ich würde gerne einen Teil Deines VHDL Sourcecodes für ein eigenes Projekt verwenden. Ich bastel gerade an einem NIOS System und suche für einen VGA Core noch ein "Quasi Dual Port SRAM". Das CSR Modul würde gut passen :-) Ich hab aber eine Frage: Für was ist das Signal clk in diesem Modul? Die Statemachine läuft ja mit dem Signal clk4x und ich nehme an das Sync Signal ist 15MHz vom PAL Encoder. OT/
Claude wrote: > Die Bilder sind echt beeindruckend!! > Wie weit bist Du denn mit den mit dem Altera Design? Das Design ist schon auf einem EP1C12-Board gelaufen. Die einzige Komponente die ersetzt werden musste, ist die für die Erzeugung der Frequenzen. Statt DCM nimmt man dann dem PLL. Der Rest geht normal ohne Änderungen. > Würde der PAL Encoder auch mit mit einem R2R DAC funktionieren? Hmm ... wäre mal auszuprobieren. Aber bei den R2R-DACs ist doch meist der Frequenzgang nicht so besonders, oder? > /OT > Ich würde gerne einen Teil Deines VHDL Sourcecodes für ein eigenes > Projekt verwenden. Ich bastel gerade an einem NIOS System und suche für > einen VGA Core noch ein "Quasi Dual Port SRAM". > Das CSR Modul würde gut passen :-) > Ich hab aber eine Frage: Für was ist das Signal clk in diesem Modul? > Die Statemachine läuft ja mit dem Signal clk4x und ich nehme an das Sync > Signal ist 15MHz vom PAL Encoder. > OT/ Wenn dein Projekt non-commercial ist, kannst du das gerne tun. Bitte beachte aber die Lizenz: http://creativecommons.org/licenses/by-nc-sa/2.0/de/ Das Signal clk ist der 15MHz Pixeltakt. Die clkx4 ist der 4fache Takt. 4fach deshalb, weil das SRAM unter anderem Wartezeiten von Schreib- nach Lesezugriff braucht und die mit dem 2fachen Takt nicht eingehalten werden konnten. Wenn dazu noch jemand eine Idee hat bin ich ganz Ohr. Das Sync kommt aus der Komponente clk, in der 15MHz, 60MHz und 45MHz erzeugt werden. Ein DCM erzeugt aus 45MHz Oszilltortakt 180MHz und der treibt eine Statemaschine an, der die Frequenzen erzeugt. Bei der Altera-Version ist das etwas anders gelöst. Da muss ich mal kurz nachkucken ... Das Sync-Signal ist dazu da um die Statemaschine des Cycle-Shared-RAMs mit den 15Mhz (ist auch der Pixeltakt) der beiden Busse zu synchronisieren. Das erscheint etwas "von hinten durch die Brust ins Auge", aber ich hab keine andere Möglichkeit gesehen. Mfg Thomas
@thomas cooole sache. also das demo-bild ist echt beeindruckend. klasse. weiter so !! gruß rene
Hallo, ohne Dich ärgern zu wollen: mit solchen Bildern konnte man selbst schlechte DDR-Farbfernseher wunderbar verkaufen. ;-))) Teste doch mal mit kritischen Strukturen. s/w-Bild mit feinen Strukturen sollte kein Farbübersprechen erzeugen (der Dekoder muß das aber auch können...) Farben mit groen Kontrastunterschieden, verschieden Text-/Hintergrundkombinationen usw. sollten möglichst kein Kantenflimmern und keine falschen Farbkanten ergeben. Prinzipbedingt sind grün/magenta-Übergänge mit steigender Sättigung immer unsauber (ist bei PAL Absicht, weil diese Kombination in der Natur (fast) nie gesättigt vorkommt. Gesättigtes Rot/Blau macht auch Probleme, beides ist im Testbild auch gut zu erkennen. Kritisch auch senkrechte/schräge s/w-gestreifte Objekte in einem Farbbild (gestreifte Hemden machen sich da gut ;). Vieles davon wird heute durch passende Vorverarbeitung und bessere PAL-Dekoder vermieden, wäre mal interessant, was Dein Encoder da schafft. Gruß aus Berlin Michael
Hier hab ich zwei Testbilder: http://www.pcb-dev.com/content/palenc/gallery/graphiti.jpg und http://www.pcb-dev.com/content/palenc/gallery/testbild.jpg Mfg Thomas Pototschnig
> Würde der PAL Encoder auch mit mit einem R2R DAC funktionieren?
So ein Zufall ... ich muss jetzt für eine andere Video-Applikation eh
einen R2R-DAC basteln. Da werde ich dann sehen ob man damit leben kann.
Wäre jedenfalls günstiger ...
Mfg
Thomas
An sich sollte ein R2R DAC kein Problem sein. Wichtig ist nur, dass er ausreichend niederohmig ist, und keine große kapazitive Last angeschlossen ist. Mit einem schnellen OP dahinter sollten >10MHz Bandbreite kein Problem sein.
Hallo Benedikt, wie ausreichend niederohmig sollte er sein? Ich dachte R2R mit R=10k sollte funktionieren, wenn dahinter ein hochohmiger Video-Amp kommt. Oder ist das zu hochohmig? Oder wieso überhaupt soll er niederohmiger sein? Mfg Thomas Pototschnig
Ich hatte glaube ich 5,1k + 10k verwendet und dann über einen simplen Emitterfolger ein SW Videosignal erzeugt. Das sollte dann etwa 10MHz Bandbreite ergeben, wenn es keine großen Kapazitäten gibt. Höher als 10k würde ich aber nicht gehen. Man muss einen Kompromiss zwischen Strom und Frequenz eingehen (Widerstände zu klein -> Innenwiderstand des Digitalausgang wird relevant -> DAC nicht linear)
Okay alles klar, mit niederohmig stellte ich mir 100Ohm vor, das hätte mich dann aber gewundert g Bei der Gelegenheit kann ich auch ein diskret aufgebautes Rekonstruktionsfilter ausprobieren. Dann spar ich mir vielleicht noch den MAX9502. Der kostet zwar sogut wie nichts aber besorgen muss man ihn auch erstmal. Hab schon mal gegoogelt und bei diversen Applikation-Notes von AD und anderen ein paar einfache Filter gesehen. In der allerersten Version hatte ich einen simplen Tiefpass, der war aber natürlich murx. Die empfohlenen Filter sind aber nicht besonders aufwändig. Wenn man jetzt noch den OP hinterm R2R-DAC weglassen könnte - und das kann man bestimmt irgendwie mit einer einfachen Transistorstufe - hätte man auch das letzte Spezialteil entsorgt. Dann wäre nur noch interessant wieviel von "HighQuality" noch übrig ist :-) Mfg Thomas Pototschnig
Ich weiß nicht wie stark die FPGA Ausgänge sind, aber je niederohmiger desto besser. Falls möglich wären 1kOhm oder geringer optimal. Dahinter dann ein mehrstufiges LC-Filter. Damit kann man auch aus 44kHz Samplerate noch etwas sinusähnliches mit 20kHz erzeugen: http://www.wa4dsy.net/filter/hp_lp_filter.html Ich nutze meist 5 pole, Chebyshev 0.1 DB, C-L-C-L-C http://www.wa4dsy.net/cgi-bin/lc_filter?FilterResponse=Lowpass&poles=5&cutoff=8&funits=MHZ&Z=1000
> Damit kann man auch aus 44kHz > Samplerate noch etwas sinusähnliches mit 20kHz erzeugen Das Problem hab ich nicht, da bei mir maximal 7,5MHz Frequenzen mit 45MHz Samplerate erzeugt werden und da dann eh ein schöner Sinus rauskommt. Mir schwebte eher so ein Filter vor wie es hier beschrieben wird: http://www.chrontel.com/pdf/TB45.pdf Wenn sie schon empfohlen werden, sollten sie ziemlich gut bezüglich den Anforderungen (Group Delay,...) sein. Mfg Thomas Pototschnig
Das Posting da oben ist von mir - an meinem Firmenrechner hab ich wieder mal die mc.net Zugangsdaten nicht und so spiel ich mich ständig mit irgendwelchen kreativen NickNames :-) Mfg Thomas Pototschnig
Wegen dem R2R DAC, bin vor einiger Zeit mal über diese Seite gestolpert : http://members.at.infoseek.co.jp/x1resource/xilinx/fpgapac/ Leider find ich den direkten Link nicht mehr, deshalb der R2R DAC für einen NTSC Encoder ,inkl. Verilog Source, als Anhang.
@Claude: Der R2R-DAC ist ja wirklich ganz schön niederohmig ... R=75Ohm ... evtl probier ich es aber gleich mal so aus ... Vorhin hab ich mal meinen PAL-Encoder für einen EP2C5 synthetisieren lassen und erstaunlich, der Generationswechsel von Cyclone auf Cyclone2 hat gleich einen Unterschied von 1000LE ausgemacht! Er braucht da nur noch 2300LE und lastet den kleinsten Cyclone2 nur zu 50% aus. Das ist doch mal erfreulich :-) Mfg Thomas Pototschnig
Angehängte Dateien:
-
eb2_r2r.jpg
90 KB
Hab mich jetzt auch mal an den PAL Encoder rangemacht. Ich hab den R2R DA Wandler von dem Link den ich weiter oben gepostet hab aufgebaut. Hinter den DA einen kleinen L-C Filter. Das Signal scheint mir soweit in Ordnung zu sein. Falls jemand auch ein Altium Live Design Board mit Cyclone hat und das ganze mal versuchen will kann ich gerne mein Quartus Snapshot hier posten. SPI und RAM sind bisher aber nicht getestet!
Noch eine Frage zum SPI , geh ich recht in der Annahme das ich zuerst 16 Bit RGB Daten dann das Address Lowbyte 9..0 (cmd 01) und danach das Address Highbyte 18..10(cmd 02) schreiben muss?
Angehängte Dateien:
-
spi.jpg
130 KB
Hallo Claude, ich hab dir ein Bild vom SPI-Timing angehängt. Du musst zunächst einen Adresspointer setzen, dann kannst du nacheinander einfach die Daten schicken, der Adresspointer wird dann automatisch nach jedem 16Bit-Datum um eins erhöht. Der Auszug aus der Dokumentation stimmt so nicht ganz ... das SPI-Interface ist immer noch ziemlich mies. Wenn du Daten verlierst, versuch mal langsamer zu übertragen. Ich bin noch nicht dazugekommen das SPI-Interface nochmal gescheit zu bauen. Konzeptfehler ... Kannst du mal deinen Schaltplan posten? Insbesondere die Dimensionierung des LC-Filters würde mich interessieren ... Mfg Thomas
Hi Thomas, danke für die Erklärung. Im Anhang mein R2R-DAC , die Filter hab ich aus dem Chrontel PDF , hatte aber nicht die passenden Werte zur Hand. Beim R2R-DAC ebenso , hatte nur noch 68 Ohm Widerstände rumliegen.
@Claude: Danke für das PDF ... werde ich demnächst auch mal so probieren :-) Mfg Thomas Pototschnig
So, die SPI Schnitstelle und der SRAM läuft jetzt auf dem Altium EB2 Board. Blos hab ich so meine Probleme 16 Bit RAW Bilder zu erzeugen, kennt jemand ein Tool um z.b. von JPG nach RAW 16 Bit zu konvertieren?
Ich hatte mein Testprogramm damals beigebracht 24Bit .BMP-Files zu lesen (da unkomprimiert) und dann aus RGB 8:8:8 einfach RGB 5:6:5 zu berechnen. Wo hängt denn die SPI-Schnittstelle dran?
Momentan an einem Atmega32. Ich Empfange über den Uart jeweils 2 Byte die ich zu einem Int verknuddel und per SPI Unit zum FPGA schicke. Also mit 7,5MHz SPI Takt läuft es eigentlich ziemlich zuverlässig. Schick wäre das ganze an ein Memory Interface zu hängen, aber leider fehlt mir da etwas das FPGA KnowHow um ein Asynchrones Interface zum uC herzustellen (Async wg. mangels Wait Leitung an den meisten uCs). Aber an einem Nios könnte ich mich mal Versuchen , da läuft Dein CSR Modul schon in einer anderen/ähnlichen Anwendung. Das mit dem konvertieren hat sich auch erledigt ,hab ein Tool gefunden : Image2LCD V1.1 , leider Japanisch aber selbsterklärend. Gruß Claude
> Also mit 7,5MHz SPI Takt läuft es eigentlich ziemlich zuverlässig.
Das Problem an meinem SPI-Interface ist die notwendige Wartezeit
zwischen dem letzten empfangen und dem ersten Empfangenen Bit. Ich
glaube es braucht 2-3 Takte des 15MHz Takts, bis wieder was neues
empfangen werden kann. Ein normales SPI-Interface sollte schon was neues
empfangen können, während die letzten Daten gerade verarbeitet werden.
Das geht leider noch nicht.
d.h. du kannst die Daten beliebig schnell reintakten, aber zwischen den
Words muss eine mindest-Wartezeit eingehalten werden, die ich glaub
sowas um die 200ns lang sein muss.
Richtig implementiert, könnte man die Daten mit >20Mbit Vollgas
reintakten und bräuchte garnicht warten.
Mfg
Thomas
Wäre es möglich den RAM im FGA zu integrieren? Gruß Manfred
Kommt auf den FPGA , oder besser dessen Größe des Blockrams, an. Für den PAL Framebuffer benötigt man ca. 800kByte RAM. Der Größte Altera Stratix 3 hat ca. 2Mbyte Blockram aber ob sich das in anbetracht des Preises eines Stratix 3 lohnt?
@Claude: Hast du schon irgendwelche Bilder darstellen können? Mich würde die Qualität vor allem an einem richtigen Fernseher interessieren ... Kannst du auch mal mit'm Oszi nachmessen, was du da am Ausgang für Pegel kriegst (mit und ohne 75Ohm am Ausgang)? Mfg Thomas Pototschnig
Moin Thomas, hab es an einem 70cm , 50hz billigst TV probiert. Die Qualtität war 1A! Als Testbild hatte ich u.a. einen Farbverlauf mit Text (relativ kleiner Font,mit schön harten Kanten) es war weder Zeilenflimmern,Moiree oder Kammflimmern zu erkennen. Den Pegel müsste ich nochmal nachmessen, war aber soweit ich mich erinnern kann um die 0.8-0.9Vpp mit 75R Eingangswiderstand am TV. Was macht dein Altera? Bist Du schon weiter gekommen mit dem Parallen/Wishbone Interface? Bei mir liegt gerade ein Atmel AT91R40008 neben dem FPGA Board der darauf brennt den SRAM zu Stressen :-) Mal schauen wann ich Zeit finde da weiter zu Basteln.
Ach was mir noch einfällt : Im SRAM sind ja noch ca. 200kByte frei. Wie wäre es mit einer kleinen Font/Sprite Engine im FPGA? Die Engine könnte den freien SRAM als Font ROM benutzen , der per uC ladbar ist. Wenn das ganze "On thy Fly" geht , also die Pixel im Pixelstrom gesetzt werden, hätte man schon beinahe einen 2. Layer. Z.b. mit einen Line Fifo der im Horizontalen Retrace die Fontdaten aus dem Font ROM holt. Welchen uC benutzt Du mit der Grafikkarte? Ich sammel gerade ideen für einen kleinen "Polygon Rasterizer" der mal von einer reinen Nios Software Lösung in ARM C / VHDL portiert werden soll.
Angehängte Dateien:
-
microga.jpg
68 KB
Claude wrote: > Moin Thomas, > hab es an einem 70cm , 50hz billigst TV probiert. Die Qualtität war 1A! > Als Testbild hatte ich u.a. einen Farbverlauf mit Text > (relativ kleiner Font,mit schön harten Kanten) es war weder > Zeilenflimmern,Moiree oder Kammflimmern zu erkennen. > Den Pegel müsste ich nochmal nachmessen, > war aber soweit ich mich erinnern kann um die > 0.8-0.9Vpp mit 75R Eingangswiderstand am TV. Das hört sich gut an! Vorgestern hab ich den R2R-DAC mal mit LTSpice simuliert und der hat auch gesagt, dass die Pegel mit 75R Abschluss ungefähr 1Vss sein sollten. > Was macht dein Altera? Bist Du schon weiter gekommen mit dem > Parallen/Wishbone Interface? Hab gestern eine Ultra-Low-Cost-Version mit halb so großer Platine und mit Cyclone2 gelayoutet ... Da ist der R2R-DAC auch drauf ... Die Ultra-Low-Cost-Version hat aber auch garkeine Pins mehr für ein paralleles Interface, sondern nur noch SPI und es gibt auch nur noch ein einziges RAM, d.h. 390*576 mit 16Bit ist möglich (geht aufgrund des Timings mit einem RAM nicht anders), oder mehrere Bildschirm-Seiten mit 390*288; Will auch noch einen 780*576 @ 8Bit indiziert (16Bit Farbtabelle) einbauen. Material ist halb so teuer, die Platine halb so groß (53*38mm) usw... Ist nur so eine Spielerei um mit dem Cyclone2 a bisserl vertrauter zu werden ... und vor allem, muss ich eine neue Version von meinem LED-Touch-Panel ätzen lassen und da war ein Streifen Platine noch übrig, die irgendwie sinnvoll genutzt werden müssen :-) ... Das Parallele Interface mit vollem Speicherausbau ist aber noch lang nicht vom Tisch, weil ich das bald auch selber brauche > Bei mir liegt gerade ein Atmel AT91R40008 neben dem FPGA Board > der darauf brennt den SRAM zu Stressen :-) > Mal schauen wann ich Zeit finde da weiter zu Basteln. AT91R40008? hmm ... Ich hab noch das AT91R40400 Board EB-1 bei mir rumliegen - damals mal für 600DM gekauft, aber dann doch nie was damit gemacht :-( Jetzt hab ich das SAM9260-EK, aber das hat einen so bescheuerten Stecker für das Bus-Interface ... Mfg Thomas Pototschnig
Claude wrote: > Ach was mir noch einfällt : Im SRAM sind ja noch ca. 200kByte frei. > Wie wäre es mit einer kleinen Font/Sprite Engine im FPGA? > Die Engine könnte den freien SRAM als Font ROM benutzen , > der per uC ladbar ist. Ja das könnte man machen - wenn man einen 10*12 Pixel-Font verwendet, dann kriegt man 78*48 zeichen (nicht-2er-potenz ist bisserl blöd...) ... Man könnte das Font-ROM in ein Block-RAM quetschen - 256*1,25*12 sind ja nur knappe 4kb ... Oder man quetscht den Text-Bildschirmspeicher in ein Block-RAM und macht ein Font-RAM im SRAM. Aber das Font-ROM würde mir eher gefallen und 4kb ist ja kein Problem ... Oder mach quetsche Text-Speicher und Font-RAM ins Block-RAM, dann kann man vielleicht Text und Grafik gleichzeitig darstellen ... > Welchen uC benutzt Du mit der Grafikkarte? > Ich sammel gerade ideen für einen kleinen "Polygon Rasterizer" > der mal von einer reinen Nios Software Lösung > in ARM C / VHDL portiert werden soll. Ich bin mitten dabei fast komplett auf ARM7 umzusteigen; Das Zeugs von mir gibts also in erster Linie für die SAM7S64 oder evtl auch mal für den SAM7S256. Hab mir dazu auch schon das Datenblatt der SAM7-Familie drucken und binden lassen, weil ich PDFs so unübersichtlich finde :-) http://home.in.tum.de/~pototsch/buch1.jpg http://home.in.tum.de/~pototsch/buch2.jpg Mfg Thomas Pototschnig
Wo bekommst du den Cyclone her? Hab noch 2 EP2C8 im PQ208 rumliegen die ich wie Gold behandel da ich bis jetzt noch keine Quelle in D gefunden habe die an Privat liefert. Digikey scheidet bei mir aus Prinzip aus. /OT Brauchste noch ein Unbenuztes EB42 ? :-) Spass! Aber bei mir stapeln sich so langsam auch die Boards. Meine neuste Errungenschaft ist ein SAM9261-EK. Ist beim SAM9260 auch dieses Timesys Linux dabei? Hast Du da eine Alternative zu Timesys?
Claude wrote: > Wo bekommst du den Cyclone her? Hab noch 2 EP2C8 im PQ208 rumliegen die > ich wie Gold behandel da ich bis jetzt noch keine Quelle in D gefunden > habe die an Privat liefert. Digikey scheidet bei mir aus Prinzip aus. Digikey :-( Die Firma bei der ich arbeite, hat einmal bei Digikey Xilinx-Zeugs bestellt, weil wir da noch keinen deutschen Distributor hatten, da hab ich mir ein Paar [sic!] Cyclone2 mitbestellt. > /OT > Brauchste noch ein Unbenuztes EB42 ? :-) Spass! > Aber bei mir stapeln sich so langsam auch die Boards. > Meine neuste Errungenschaft ist ein SAM9261-EK. > Ist beim SAM9260 auch dieses Timesys Linux dabei? > Hast Du da eine Alternative zu Timesys? Ja, ich hab das Timesys-Zeugs komplett gekickt ... Es gibt doch das Atmel-Linux Demo. Dort gibts einmal ein Kernel-Image und dann das Root-Image. Kernel ist schrott, weil da fast alles (vorallem Netzwerk-support) nicht aktiviert ist; Ich hab mir daher einen Standard-Kernel mit SAM9260-config kompiliert, alles was ich sonst noch brauch angeschaltet und verwende weiterhin das Root-Image aus dem Atmel-Demo. Das klappt ganz gut eigentlich und ich bin das Timesys-Zeugs los :-) Mittlerweile hab ich das Linux auf einer 1GB SD-Karte und die erste Hello-World-Linux-App hab ich mit einer Cross-Compiler-Umgebung auch zum Laufen gekriegt ... Mfg Thomas Pototschnig
Hier noch meine Notizen, vielleicht helfen die dir Mfg Thomas Pototschnig
Super, vielen dank! Wegen den Cyclones. Ich könnte über meine Firma welche bestellen, sobald wir das nächste Fertigungslos haben kann ich mich mit ranhängen. Bekommen könnte ich EP2C8T144C8N , der sollte Pinkompatibel zum EP2C5T144 sein , und EP2C8??208C8N. Die Preis so um die 13-15€. Die M25er SPI Flashes (Config Prom Ersatz) sollte ich auch bekommen , M25P64 ~ 5€ . Bei Interesse ne Email an claude punkt schwarz ät gmail punkt com
Der EP2C8 würde mich wirklich interessieren ... die 5000LE für den PAL-Encoder-Core sind schon recht knapp bemessen und wenn man den dann mit Font-ROM usw aufmotzt, kanns dann zuwenig sein ... Ich schreib dir Nachmittag mal 'ne Mail :-) Mfg Thomas Pototschnig
OT: @ Thomas Pototschnig (pototschnig): was? 5000LE für PAL-Encoder sind kanpp bemessen? :-o :-o :-o Ich komme aus dem Staunen nicht mehr heraus ;-) Was hast du da schönes implementiert? Wie hoch groß ist die Auslastung des FPGAs? Grüße, Kest
Kest wrote: > OT: @ Thomas Pototschnig (pototschnig): > > was? 5000LE für PAL-Encoder sind kanpp bemessen? :-o :-o :-o Ich komme > aus dem Staunen nicht mehr heraus ;-) Was hast du da schönes > implementiert? Wie hoch groß ist die Auslastung des FPGAs? Wie meinst du das? Sind 5000LE zuviel? Oder zuwenig? :-) Bisher hat der in einem XC2S200 (200kGates) gewerkelt (sowas um die 150k Gates Auslastung). Die Altera-Version kommt im Cyclone 1 (EP1C12) mit rund 4000LE aus, im Cyclone 2 (EP2C5) braucht er nur 2300LE rum ... Mfg Thomas Pototschnig
Ich meinte, dass 5K eine ganz schöne Menge ist :-) Aber stimmt schon, es kann nie genug sein ;-) Ich habe hier ein 2c70: bei der Spezifikation dachte ich, unter 2c70 wird es sehr kapp. Und jetzt sind es gerade mal 7K geworden :-o Na gut, Block Rams waren wichtig (die sind bei 80% oder so belegt) Das Projekt ist aber sehr interessant :-) Grüße, Kest
Kest wrote: > Ich meinte, dass 5K eine ganz schöne Menge ist :-) Aber stimmt schon, es > kann nie genug sein ;-) Ja, das ist schon irgendwie richtig ... Aber der 2C5 ist immerhin der kleinste Cyclon2 den es gibt ... Der PAL-Encoder macht aber auch relativ viel, also auch Sachen wie Speichersteuerung mit Cycle-Shared-RAM, FIR-Tiefpassfilter für die Farb-Komponenten-Signale usw ... Vermutlich kriegt man den noch um einiges kleiner, wenn man für z.B: FIR irgendwelche IPs von Altera oder Xilinx verwenden würde - aber so ist das Ding voll portierbar (bis auf die Takterzeugung) ... > Ich habe hier ein 2c70: bei der Spezifikation dachte ich, unter 2c70 > wird es sehr kapp. Und jetzt sind es gerade mal 7K geworden :-o Na gut, > Block Rams waren wichtig (die sind bei 80% oder so belegt) Uff! Wow ... was machst du denn mit so einem Monster? G Mfg Thomas Pototschnig
Ist eine Videoanwendung. NIOS ist drin, SRAM-Ansteuerung (mehrere Bänke), Videoprocssing, RGB->YUV, Videoencoder, DVI-IN/OUT und weitere "Kleinigkeiten". Der Vorteil ist, dass es schnell geroutet wird -> 10 Minuten (weil eben viel Platz). Mit kleinen Cyclones habe ich auch meine Erfahrungen gemacht, die sind auch nicht ohne und man glaub kaum, was man unterbringen könnte, wenn man nur wollte :-) Grüße, Kest
Kest wrote: > Ist eine Videoanwendung. NIOS ist drin, SRAM-Ansteuerung (mehrere > Bänke), Videoprocssing, RGB->YUV, Videoencoder, DVI-IN/OUT und weitere > "Kleinigkeiten". Der Vorteil ist, dass es schnell geroutet wird -> 10 > Minuten (weil eben viel Platz). Das ist eine kommerzielle Anwendung, oder? Gibts die IP-Cores zu einer Nios-II Lizenz gleich dazu oder wie läuft das? > Mit kleinen Cyclones habe ich auch meine Erfahrungen gemacht, die sind > auch nicht ohne und man glaub kaum, was man unterbringen könnte, wenn > man nur wollte :-) Jo das stimmt ... hab vor vor 2 Jahren das erste mal was mit dem XC2S50 (50kGates) gemacht und hatte Angst, dass mein Zeugs überhaupt reinpasst ... Zum Schluss hatte ich dann alles drin und noch 2 Quadraturdecoder und es sind immer noch 80% frei ... Irgendwie sind ja FPGAs wirklich das geilste womit man sich zur Zeit beschäftigen kann :-) Mfg Thomas Pototschnig
Yep, ist eine kommerzielle Anwendung. NIOS ist gekauft, alles andere self made. Es gibt ganze Menge IP-Cores von Altera, die free sind. Richtige Videoprocessing-Cores aber sind teuer und leisten nicht das, was wir gebraucht haben. So habe ich alles selber gemacht -- war auch besser so :-) Die (Altera) FPGAs sind echt geil. Schade, dass sie nicht so breite Verwendung in Hobbykreisen finden Grüße, Kest
Kest wrote: > Yep, ist eine kommerzielle Anwendung. NIOS ist gekauft, alles andere > self made. > > Es gibt ganze Menge IP-Cores von Altera, die free sind. Richtige > Videoprocessing-Cores aber sind teuer und leisten nicht das, was wir > gebraucht haben. So habe ich alles selber gemacht -- war auch besser so > :-) Nice :-) > Die (Altera) FPGAs sind echt geil. Schade, dass sie nicht so breite > Verwendung in Hobbykreisen finden Mir kommts so vor, als würde man bei Altera mehr für sein Geld kriegen ... z.B. kostet der EP2C5 viel weniger als z.B. ein XC3S200, aber es passt mehr rein ... Schade ist nur, dass Altera immer einen Schritt hinterherhinkt ... Wenns die Webedition von Quartus für Linux geben würde, würden die sich wohl besser durchsetzen können, das scheint aber ein Lizenzproblem zu sein, weil die die Tools zugekauft haben oder so ... Mfg Thomas Pototschnig
Kann man den Quartus nicht mit WINE laufen lassen? Ich kenne mich mit der (Linux)Materie nicht aus. Aber dass Altera hinterherhinkt würde ich nicht behaupten -- die sind eher einen Schrit voraus! :-) Wenn ich mir nur die Tools anschaue, dann weiß ich ganz genau, wieso ich Xilinx nicht unbedngt mag ;-) Oder z.B. irgendwelche Buffer-Instanzen unter Xilinx... Bei Altera ist es einfacher. Genauso mit DCM/PLL -- wenn ich nur überlege, wieviele Probleme ich bei xilinxen mit DCM hatte, kommt die die Schauer über den Rücken. Aber okay, es soll ja nicht zum Flame werden ;-) Grüße, Kest
Kest wrote: > Kann man den Quartus nicht mit WINE laufen lassen? Das soll schon gehen irgendwie ... Aber ich glaub support für'n Programmer gibts glaub ich keinen. > Ich kenne mich mit > der (Linux)Materie nicht aus. Aber dass Altera hinterherhinkt würde ich > nicht behaupten -- die sind eher einen Schrit voraus! :-) Wenn ich mir > nur die Tools anschaue, dann weiß ich ganz genau, wieso ich Xilinx nicht > unbedngt mag ;-) Da hab ich dann wohl noch nicht soviel gemacht um den Unterschied im Detail sehen zu können. Hatte den PAL-Encoder unter Webpack geschrieben und dann nachträglich mit Quartus II Webedition auf ein Alter-Board portiert. Ich fand zumindest beide Entwicklungsumgebungen relativ gleichwertig. Das mit dem Hinterherhinken bezog sich z.B. auf den ModelSim, den es ja jetzt endlich bei Altera auch gibt. > Oder z.B. irgendwelche Buffer-Instanzen unter Xilinx... Bei Altera ist > es einfacher. Genauso mit DCM/PLL -- wenn ich nur überlege, wieviele > Probleme ich bei xilinxen mit DCM hatte, kommt die die Schauer über den > Rücken. DCM hab ich bisher nur einmal hergenommen ... 45MHz -> 90MHz und da hat alles geklappt. Was hattest du damit für Probleme? > Aber okay, es soll ja nicht zum Flame werden ;-) In meinem Thread dulde ich kein Flamen ;-) Mfg Thomas Pototschnig
Soweit ich es verstanden habe, kann man mit DCMs nicht so viel anstellen, wie mit PLL bei Altera. Zunächst ist man bei den Teilern beschränkt, dann noch bei den Phasen für einzelne Clocks. Okay, DCMs und PLLs sind prinzipiell anders aufgebaut, deshalb ist es so. Probleme bei den DCMs hatte ich z.B. beim Einschwingen, oder es kamen schlichtweg falsche Frequenzen aus dem DCM, die Phasen haben nicht gestimmt... Halt undefinierbares Verhalten -- nach jedem Reset kam irgendwas anderes raus. Im Anflug von Haß und Verzweiflung ;-) habe ich FAE angerufen. Der meinte nur "das Problem ist uns bekannt". Als Lösung sollte ich dann genaueren Quarz nehmen und nicht versuchen aus 50 Mhz 54 MHz zu machen :-/ Ich weiß nicht genau, was das genau war (ein Jahr ist es her), aber ich hoffe sehr, dass die da was gemacht haben. Solange man den Takt nur verdoppelt oder halbiert mag es ja noch gehen. Aber wenn man 8 clocks mit unterschiedlichen Phasen im Design hat, dann bin ich froh, dass ich den MegaWizzard von Altera verwende -- egal was ich angebe, wenn der Wizzard nicht meckert und synthetisiert, dann funktioniert es auch. zu Xilinx: habe letztens 1.9 GB WebPack heruntergeladen... einfach toll, sage ich :-/ zu Altera: gefühlsmäßig würde ich sagen, dass die Tools seit 6.1. Version langsamer geworden sind (Umstellung auf Java). Ist aber halb so schlim, solange es funktioniert ;-) ModelSIM ist in der Tat ein Argument für Xilinx. Meins habe ich auch auf Altera "portiert" und fasse es seit dem nicht an ;-) Grüße, Kest
Danke für die ausführliche Erklärung ... Das was mich noch etwas stört ist das Nios-II Lizenzmodel ... Mit dem Xilinx EDK kriegt man gleich den Microblaze dazu und nicht nur als Testversion oder PC-gebunden oder so. > ModelSIM ist in der Tat ein Argument für Xilinx. Meins habe ich auch auf > Altera "portiert" und fasse es seit dem nicht an ;-) Naja, nicht mehr - aber das war der primäre Grund, wieso ich mich damals für Xilinx entschieden hatte. Altera hat's mittlerweile auch geschaft eine Modelsim-Altera-Editor anzubieten. Mfg Thomas Pototschnig
Lizenzmodel ist bei Xilinx anders? Bei Altera kommt mit jedem NIOS II-board eine Jahreslizenz. Danach muss man sie sich kaufen (400€). Bei Xilinx, soweit ich weiß, bekommt man acuh EDK, welches nur 60 Tage läuft oder? Ich habe mehrere Xilinx Boards und mehrere Altera Boards hier stehen. Die Xilinx Lizenzen sind alle abgelaufen (hab' mal installiert, Code eingegeben und 2 Monate später, wenn man wirklich Zeit hat alles anzuschauen ;-) laufen die Dinge nicht mehr. Grüße, Kest
Ich glaub die 60Tage Version ist für die ISE-Version von der Entwicklungsumgebung - aber das EDK selbst ist davon meines Wissens nicht betroffen, das funktioniert weiterhin und wenn man nicht gerade einen Virtex5 oder so verwendet, kommt man mit EDK + Webpack gut aus und braucht ISE nicht. Nios-II kostet "nur" 400EUR? Dachte das wäre 1kEUR und aufwärts ... Trotzdem blöd ... als Student hab ich eigentlich keine Kohle für sowas und wenn ich damit was entwickle - in der Regel weiß ich vor dem Kauf von irgendeinem Dev-Board, was ich damit machen will - dann nutzt es mir nichts, wenn das nur am PC läuft :-/ Mfg Thomas Pototschnig
@Thomas: WO hast Du denn Deine PDF-Handbücher drucken und binden lassen. Ich hasse das ewige Rumscrollen in PDFs und blättere lieber im gebundenen Papier ;-) Joachim
Bei www.lulu.com ... ist eigentlich ein Self-Publisher-Service für selbstgeschriebene Bücher ... :-)
Hey, cool. Danke für den Tip. Das schaue ich mir mal genauer an. Joachim
Angehängte Dateien:
-
miniga3.jpg
140 KB
Hallo, soeben hab ich meine neue Platinen auf Altera-Basis bekommen ... Hab ein Bild davon angehängt ... Halb so groß und halb so teuer, kann aber auch nur die Häflte ;-) Die Auflösung wird auf 390*576 Pixel @ 16Bit reduziert, weil ich jetzt nur noch einen 8Bit-Bus zum RAM habe und keine 16Bit mehr wie vorher. Außerdem sinds nur noch 512kB RAM statt 1MB. Die Entscheidung war, dass das Ding kleiner und günstiger werden soll. Es gibt auch kein Paralleles Interface mehr, nur noch einen R2R-DAC usw ... Bin mal gespannt ob das Ding jemals funktionieren wird ... Wünscht mir glück g MFg Thoms Pototschnig
Hi Thomas, für welchen Altera sind die Platinen denn? 2C5 im TQ144 ? Hast Du da noch Platinen übrig die Du verkaufen würdest?
Jo, für den 2C5 im TQ144. Insgesamt hab ich 3 Platinen, aber ist halt alles noch ungetestet und das VHDL-Zeugs ist auch noch nicht fertig. Mfg Thomas Pototschnig
Claude: Wieviel hat die gebundene Version des Datenblatts denn gekostet und wo hast das machen lassen? Wenn's nicht so teuer ist würde ich mir das glatt auch machen lassen, schaut echt cool (und nützlich) aus :)
Das nenn ich doch mal nice. Kannst du sagen wie die Kosten so sind? Also: Platine X € FPGA Y € RAM Z € Sonstiges...
Läubi Mail@laeubi.de wrote: > Das nenn ich doch mal nice. > Kannst du sagen wie die Kosten so sind? > Also: Platine: ~10EUR FPGA: EP2C5 ~15EUR Flash-Prom: ~2EUR RAM: ~4EUR Sonstiges...: ~5EUR Hmm ... also sowas um die 36EUR wirds schon werden ... Sind aber mehr als 20EUR weniger als die vorherige Version. Aber noch funktioniert das Ding ja nicht :-) Mfg Thomas Pototschnig
lupin wrote: > Wieviel hat die gebundene Version des Datenblatts denn gekostet > und wo hast das machen lassen? Wenn's nicht so teuer ist würde ich mir > das glatt auch machen lassen, schaut echt cool (und nützlich) aus :) Ich habe das auch machen lassen (AT91SAM7S). Ist super. Allerdings braucht das nicht jeder extra machen zu lassen. Man kann die auch nachbestellen, glaube ich. Außerdem muss man die PDFs erst noch bearbeiten ;-) damit sie akzeptiert werden. Denn es müssen alle Fonts eingebettet sein. Und das war hier nicht der Fall. Und PDFs sind meist Passwortgeschützt ;-) Also wenn Du willst, kann ich Dir ein Buch AT91SAM7S nachbestellen. Kostet 20,- Euro + Versand. Dauert 1-2 Wochen. Schreib mir an info<ät>jmlaser<dot>com Joachim
Joachim wrote: > lupin wrote: >> Wieviel hat die gebundene Version des Datenblatts denn gekostet >> und wo hast das machen lassen? Wenn's nicht so teuer ist würde ich mir >> das glatt auch machen lassen, schaut echt cool (und nützlich) aus :) > > Ich habe das auch machen lassen (AT91SAM7S). Ist super. > Allerdings braucht das nicht jeder extra machen zu lassen. > Man kann die auch nachbestellen, glaube ich. > Außerdem muss man die PDFs erst noch bearbeiten ;-) damit sie akzeptiert > werden. Denn es müssen alle Fonts eingebettet sein. Und das war hier > nicht der Fall. Und PDFs sind meist Passwortgeschützt ;-) > > Also wenn Du willst, kann ich Dir ein Buch AT91SAM7S nachbestellen. > Kostet 20,- Euro + Versand. Dauert 1-2 Wochen. > > Schreib mir an info<ät>jmlaser<dot>com Da will also jemand 5EUR pro Buch verdienen ... Frechheit ;-) Pass nur auf, dass dich da niemand abmahnt ... Mfg Thomas Pototschnig
Thomas: Gibt es schon was neues von der neuen Graka? Warum hast du eigentlich kein DRAM verwendet? Durch den ständigen Speicherzugriff kann man doch bei jedem screen refresh auch einen RAM refresh machen oder? Dann hätte man auch mehr und günstigeren Speicher als mit SRAM.
Marius Schmidt wrote: > Thomas: Gibt es schon was neues von der neuen Graka? Warum hast du > eigentlich kein DRAM verwendet? Durch den ständigen Speicherzugriff kann > man doch bei jedem screen refresh auch einen RAM refresh machen oder? > Dann hätte man auch mehr und günstigeren Speicher als mit SRAM. Das Ding ist fast zusammengebaut ... der erste Versuch scheiterte leider daran, dass Altera ihren Aufdruck auf den FPGAs um 90° verdreht hat und ich das Ding erstmal geschossen habe ... Hatte es mir angewohnt, dass links unten Pin 1 ist, wenn man die Schrift lesen kann ... gemein sowas ;-) Was haben denn DRAMs für Zugriffszeiten? Ich hab mal geschaut, wie es mit SDRAMs aussieht, aber da ist garkein Land in Sicht. Also nur zum Bild darstellen ist es natürlich schnell genug, aber mit meinem SRAM kann ich auch gleichzeitig Daten in den Speicher schreiben. Das SDRAM wär dann ständig mit Bankumschaltungen beschäftigt und die kosten zuviel Zeit ... Mfg Thomas Pototschnig
Hallo, es gibt jetzt endlich mal Neuigkeiten ... Ich hatte heute Zeit die Platine In-Betrieb zu nehmen und erstaunlicherweise funktioniert die sogar. Aber natürlich nicht auf anhieb ... es gibt nichts schöneres als Drähte an ein 0,5mm-QFP zu löten ... ;-) Hier mal 3 Bilder: Die Platine selber (mittlerweile ist noch was dazugekommen): http://home.in.tum.de/~pototsch/microga/microga.jpg Ein Bild, wie es auf dem Oszi aussieht: http://home.in.tum.de/~pototsch/microga/oszi.jpg Und ein Foto vom Fernseher (erscheint mir subjektiv am Fernseher wesentlich besser, als mit der Digicam geknippst): http://home.in.tum.de/~pototsch/microga/testbild.jpg Schaut bisher - auch trotz R2R-Wandlers - nicht übel aus ... SPI-Interface und richtige Bilder wird noch etwas dauern bis da was geht ... Mfg Thomas Pototschnig
Das Bild korean1.jpg würde ich ja gerne sehen (also mit R2R). Bei modernen Grafikkarten kommt doch auch DRAM als Bildspeicher zum Einsatz, kann mir gar nicht vorstellen, dass das zu langsam sein soll... Ist schon ziemlich klein das Teil (der FPGA schaut sehr gross aus, ist der rand voll oder wirst du später auf was kleineres umsteigen?), echt nettes Projekt... wenn's fertig ist wäre ich auch an einer Karte interessiert.
Lupin wrote: > Das Bild korean1.jpg würde ich ja gerne sehen (also mit R2R). Kommt noch :-) > Bei modernen Grafikkarten kommt doch auch DRAM als Bildspeicher zum > Einsatz, kann mir gar nicht vorstellen, dass das zu langsam sein soll... Ich hab z.B. mal bei Digikey geschaut, aber da keine passende DRAMs gefunden ... alles irgendwie langsamer als mein SRAM. Müsste man mal schauen was Grafikkarten für RAMs haben ... > Ist schon ziemlich klein das Teil (der FPGA schaut sehr gross aus, ist > der rand voll oder wirst du später auf was kleineres umsteigen?), echt > nettes Projekt... wenn's fertig ist wäre ich auch an einer Karte > interessiert. Der EP2C5 ist momentan zu 50% voll. Ich wär auf was kleineres umgestiegen, wenn es was kleineres geben würde ... TQ144 ist wohl die kleinste Bauform die man kriegt :-( Mfg Thomas Pototschnig
Und was war nochmal der grund für altera? Xilinx hat doch kleine FPGAs oder? Bei DRAMs dachte ich eigentlich an die alten PC DIMMs (100/133 MHz), die man ja mit ein bischen Glück ausschlachten könnte. Mit wieviel bit hast du den R2R ausgelegt und wieviel erwartest du (realistisch gesehen)?
Hab gerade mal bei xilinx geschaut, die auswahl an kleinen FPGAs ist echt nicht gross... schade. Es gibt auch FPGAs mit integrierten Flash speicher, vlt wären die was (hab leider vergessen wie die heissen). Oder sogar ein CPLD. Die VGA Grafikkarte von Ulrich radig hat ja auch in ein kleines CPLD gepasst (aber VGA->PAL ist ja noch ein kleiner Unterschied ;)).
Lupin wrote: > Und was war nochmal der grund für altera? Xilinx hat doch kleine FPGAs > oder? Der Schaltungsaufwand ist bei Altera einfacher, man braucht weniger Spannungen, sie sind billiger (Logikeinheiten/Preis) usw ... Der PAL-Encoder passt in einen EP2C5 mit 50%, der XC3S200 war mit 85% ausgelastet - der Altera ist aber günstiger vom Preis. Scheint so als wäre die "Logikdichte" bei den Altera besser ... > > Bei DRAMs dachte ich eigentlich an die alten PC DIMMs (100/133 MHz), die > man ja mit ein bischen Glück ausschlachten könnte. Das sind dann SDRAMs ... Ich hab das Timing mit den SDRAMs schonmal durchgespielt, aber das hat dann gerade nicht mehr funktioniert, dass man wirklich ein Dual-Port-RAM nachbildet, weil man im worst-case zuviele Bankumschaltungen hat und die zuviel Zeit kosten. Mit dem SRAM kann man ja Vollgas wahlfrei irgendwo was hinschreiben ohne dass man warten muss. > > Mit wieviel bit hast du den R2R ausgelegt und wieviel erwartest du > (realistisch gesehen)? Sind jetzt nur 8Bit ... Was da genau rauskommt? Keine Ahnung :-) > Hab gerade mal bei xilinx geschaut, die auswahl an kleinen FPGAs ist > echt nicht gross... schade. Es gibt auch FPGAs mit integrierten Flash > speicher, vlt wären die was (hab leider vergessen wie die heissen). Oder > sogar ein CPLD. Die VGA Grafikkarte von Ulrich radig hat ja auch in ein > kleines CPLD gepasst (aber VGA->PAL ist ja noch ein kleiner Unterschied > ;)). Jo ... aber nur ein Klitzekleiner ;-)) Hmm ... Gab neue Spartan3 die Flash hatten ... Flash wäre schon was feines ... Mfg Thomas Pototschnig
DRAMs sind schneller im sequentiellen Zugriff (Burst), aber wahlfreier Zugriff ist ziemlich langsam wegen t_RAS und t_CAS. Eine Nutzung ist aber sicher denkbar, man müsste halt FPGA Block Ram als Cache verwenden. Z.b. eine komplette Bildzeile aus dem SDRAM in einen 1024x32 Block kopieren, und dann von dort die PAL/VGA Generierung vornehmen. Während die Zeile gezeichnet wird, kann eine neue aus dem DRAM geladen werden. Aber das ist schon wesentlich aufwendiger, und für einen DRAM Controller brauchts wieder ein größeres FPGA. "Moderne Grafikkarten" nutzen übrigens GDDR2 bis GDDR4, d.h. für Graphikanwendung optimierte Double Data Rate DRAMs bei extrem hohen Taktfrequenzen (bis ca. 1GHz). Diese sind aber mit nem FPGA vermutlich nicht ansteuerbar. Für maximale Bandbreite mit FPGA würde ich entweder DDR2 verwenden oder QDR, aber auch das wird schon nicht einfach.
Angehängte Dateien:
-
korean1.jpg
93 KB
Hallo, hab den Rest heute testen können ... Hier und in dem nächsten Posting 2 Result-Bilder ...
Angehängte Dateien:
-
flasche.jpg
50 KB
Ich hab wieder mal das Problem, dass das Bild versetzt ist ... hatte ich hin und wieder bei der V1 auch, habs aber noch nicht gefunden ... Irgendwas mit'm Reset vermutlich ... Die Farbverläufe sehen ziemlich ungut aus ... da könnte ich noch einen Fehler drin haben, dass die unteren 8Bit von einem 16Bit-Pixel vom falschen Pixel daneben verwendet werden oder so ... das muss ich mir noch genauer anschauen ... Für einen 8Bit R2R-Wandler ists aber garnicht mal soooo schlecht ... Man sollte den Titel jetzt auf Mid- bis Low-Qualitity ändern ... ;-) Aber dafür hat das Ding nur Materialkosten von a bisserl weniger als 30eur :-)
Angehängte Dateien:
-
vergleich.jpg
230 KB
Hier noch ein Größenvergleich zwischen alt und neu ... Mfg Thomas Pototschnig
Wieder mal ein Update ... Mittlerweile hab ich etwas Zeit um einen Zeichengenerator einzubauen ... Anbei sieht man ein Foto von den ersten Tests auf einem 4" TFT ... Momentan wird ein 640*480 Bereich für die Zeichendarstellung mit einem 8x16-Font, der aber aufgeblasen auf 16x32 wird, damit man was lesen kann, verwendet. Es gibt daher eine Textauflösung von 40*15 Zeichen (ändert sich sicher noch ...). Voller ASCII-Zeichensatz ist schon vorhanden, und die VGA-Attribute sollen auch unterstützt werden. Also Blinken + 16 Vordergrundfarben + 8 Hintergrundfarben. Der Text-Bildschirmspeicher wurde als Dual-Port-Memory im Cylcone II realisiert und der Font wird noch ins Blockram als ROM ausgelagert. Ich finde es immer erstaunlicher was alles in so einen popligen EP2C5 reinpasst ... Mfg Thomas Pototschnig PS: Es wär echt mal eine Rubrik "Elektronik-Blogs" interessant ...
Hallo, ich hab beschlossen meine Homepage umzubauen und eine kleine Blog-Rubrik einzuführen in der man die aktuellen Entwicklungen meiner Projekte verfolgen kann. Ist per RSS-Feed abonnierbar, was vielleicht einfacher ist um auf dem Laufenden zu bleiben ... Mfg Thomas Pototschnig http://www.pcb-dev.com/
@Thomas: Hat sich in letzter Zeit bei dem Projekt noch was getan?
Hallo :) äh, hatte das Posting ganz übersehen ... Also zur Zeit gibts keine Neuheiten zu berichten. Das Projekt ist definitiv nicht tot, da ich es für andere geplante Projekte noch brauche ... Zur Zeit bin ich aber in meiner Diplom-Haupt-Prüfungs-Phase und brauch ungefähr 150% meiner Freizeit zum Lernen g Spätestens in der 3. oder 4. Oktoberwoche wirds wieder was geben :) Da hab ich dann alles hinter mir ... MfG Thomas Pototschnig
Hi alle Zusammen, ich würde gerne diese Platine nachbauen beim überprüfen der Stückliste habe ich leider keinen Shop im Internet gefunden der den Video Amplifier MAX9502 anbietet. Kennt jemand einen Shop der dies tut oder hat vielleicht einen übrig den er mir verkaufen könnte?
kleiner Nachtrag :D Ich meine natürlich einen Shop aus Deutschland.
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.