www.mikrocontroller.net

Forum: Projekte & Code High-Quality PAL-Grafikkarte für µCs


Autor: Thomas Pototschnig (pototschnig)
Datum:

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

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Spitze sache!
Kannst du sagen was ne Platine incl. aller Bauteile kosten würde und 
welche Lötfertigkeiten man mitbringen muß?

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Joerg Wolfram (joergwolfram)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Claude (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thomas

cooole sache. also das demo-bild ist echt beeindruckend.
klasse. weiter so !!

gruß
rene

Autor: Michael U. (Gast)
Datum:

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

Autor: Pototschnig Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Gargamel (Gast)
Datum:

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

Autor: Pototschnig Thomas (Gast)
Datum:

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

Autor: Claude (Gast)
Datum:
Angehängte Dateien:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Claude (Gast)
Datum:
Angehängte Dateien:

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

Autor: Claude (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:
Angehängte Dateien:

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

Autor: Claude (Gast)
Datum:
Angehängte Dateien:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Claude:
Danke für das PDF ... werde ich demnächst auch mal so probieren :-)

Mfg
Thomas Pototschnig

Autor: Claude (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Claude (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre es möglich den RAM im FGA zu integrieren?

Gruß

Manfred

Autor: Claude (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Claude (Gast)
Datum:

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

Autor: Claude (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:
Angehängte Dateien:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Claude (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch meine Notizen, vielleicht helfen die dir

Mfg
Thomas Pototschnig

Autor: Claude (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Kest (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Joachim (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei www.lulu.com ... ist eigentlich ein Self-Publisher-Service für 
selbstgeschriebene Bücher ... :-)

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey, cool.
Danke für den Tip. Das schaue ich mir mal genauer an.

Joachim

Autor: Thomas Pototschnig (pototschnig)
Datum:
Angehängte Dateien:

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

Autor: Claude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

für welchen Altera sind die Platinen denn? 2C5 im TQ144 ? Hast Du da 
noch Platinen übrig die Du verkaufen würdest?

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Marius S. (lupin) Benutzerseite
Datum:

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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das nenn ich doch mal nice.
Kannst du sagen wie die Kosten so sind?
Also:
Platine X €
FPGA Y €
RAM Z €
Sonstiges...

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Joachim (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Marius S. (lupin) Benutzerseite
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Lupin (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Lupin (Gast)
Datum:

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

Autor: Lupin (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Matthias (Gast)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hab den Rest heute testen können ...

Hier und in dem nächsten Posting 2 Result-Bilder ...

Autor: Thomas Pototschnig (pototschnig)
Datum:
Angehängte Dateien:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch ein Größenvergleich zwischen alt und neu ...

Mfg
Thomas Pototschnig

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Thomas Pototschnig (pototschnig)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch das Bild dazu ...

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas: Hat sich in letzter Zeit bei dem Projekt noch was getan?

Autor: Thomas Pototschnig (pototschnig)
Datum:

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

Autor: Gero (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
no life!!!

Autor: Mac (Gast)
Datum:

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

Autor: Mac (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kleiner Nachtrag :D

Ich meine natürlich einen Shop aus Deutschland.

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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