Hallo, ich suche mal einen Denkanstoss zu folgendem Problem: Ich will mir eine Schaltung bauen bei der ein Mikrocontroller eine Bildausgabe aus einem SRAM Speicher erzeugt währenddessen ein zweiter in einem separaten Speicher den Bildaufbau für das nachfolgende Bild erzeugt. Im Grunde genommen so eine Art Hardware Double Buffering. Damit der Bildaufbau beim FBAS zügig läuft dachte ich dass ich von nem Atmega2560 das XMEM Interface nehme. Wie würdet ihr sowas Schaltungstechnisch realisieren? Gibt's vielleicht einfachere Wege so etwas umzusetzen. Der Mikrocontroller der mit dem Bildaufbau (FBAS) beschäftigt ist ist bereits ziemlich zu und so kann ich keine Routinen neben dem Bildaufbau separat laufen lassen, deshalb dachte ich wäre eine Trennung Bild zeichenen / FBAS generieren angebracht...
Normal nimmt man ein FPGA dafür, zB ein Spartan 3A. Das hat bereits RAM-Blöcke, von denen Du einen für die anzuzeigenden Zeichen, einen für Attribute (falls erforderlich) und den Rest für den Zeichengenerator nimmst. Die RAM-Blöcke können wahlweise auch als Dual-Port RAM ausgeführt sein, das kannst Du im VHDL-Code konfigurieren. Vorteil des ganzen: es braucht 0 Rechenleistung. Dein AVR schreibt einfach seine Zeichen rein, und das FPGA macht den Rest. Alternative Möglichkeit: Du nimmst einen Microcontroller mit eingebautem TFT-Interface. Der hat eine ähnliche Mimik eingebaut. Beispiel wäre ein PIC24FJ128DA210. Da hast Du eine Grafik-Bitmap, die Du beschreiben kannst, und wenn ich da was von FBAS lese, dann sollten die 96k an internem RAM vom PIC24 reichen. Solche TFT-Steuerungen gibts auch als externe Chips, z.B. von Epson. Manche haben auch schon ihren Bildspeicher eingebaut. Für Analog RGB braucht Ihr dann nur noch drei DACs (notfalls auch diskret mit Widerständen aufbaubar), und für RGB-FBAS gibts auch Chips, die das erzeugen, z.B. MC1377. fchk
An nen FPGA hab ich auch schon gedacht. Vor allen Dingen müsste doch dann auch locker Farbe machbar sein oder? Ich will auf alle Fälle etwas mehr als nur Textzeichen generieren. Am liebsten wäre mir ein Speicherbereich im FPGA den ich per uC extern beschreiben kann, so dass ich die einzelnen Pixel selbst setzen kann. Wie genau funktioniert das mit dem RAM. Ist der mit auf dem FPGA drauf oder muss ich per VHDL Code selbst RAM erzeugen? Wie viel ist da maximal möglich? Kommt vermutlich auf die Gatteranzahl an oder? Ist denn der Spartan 3A mit normalem Handwerkszeug Lötbar? Welche Gehäuseformen gibt es da? Ich möchte mir die Platine nämlich selbst ätzen und da denke ich stosse ich an die Grenze des machbaren für den Hobbybereich oder? Den PIC werde ich mir als Alternativlösung auch mal genauer ansehen.
Wolfgang M. schrieb: > Im Grunde genommen so eine Art Hardware Double Buffering. Warum eigentlich? Es ist bei Grafikausgaben schon immer üblich, dass der Inhalt während der entsprechenden Zeiten (also während des aktiven Teils einer Zeile, ohne Rücklauf und Sync) rausgetaktet wird und während der nicht aktiven Zeiten schreibt der Grafikcontroller neue Daten rein, also sozusagen zeitlich verschachteltes Dual Port. Auf der Anzeige erscheinen immer die neuesten Daten, ein zweiter Speicher ist dafür nicht nötig. Gruss Reinhard
Hm, da bin ich mir nicht sicher ob ich dich verstehe. Ich dachte ich brauche auf alle Fälle den zweiten Ram damit der erste Prozessor in Ruhe im Hintergrund das Bild aufbauen kann. Könnte ja sein dass man eine Linie blöderweise so zeichnet dass sie teils noch im Aktiv gezeichneten Bild dargestellt wird, teils aber erst im nächsten Bild erscheint. Zum Beispiel im Fall das man von unten nach oben zeichnet. Ausserdem war ich mir bezüglich des Timings nicht ganz sicher. Ich will z.B. Daten von Sensoren usw. auf dem Bildschirm ausgeben und so ne Sensorfusion kostet seine Zeit. Kannst du vielleicht ein wenig näher beschreiben wie du das meinst? Hab das DB von dem PIC mal überflogen. Der sieht recht vielversprechend aus. Hab nur mit Atmels bisher halt leider Erfahrung....
Zum Selbstätzen: Lass es! Das kleinste Gehäuse beim Spartan 3A ist 100 oder 144 Pin TQFP in 0.5mm Raster. Mit dem passenden Flussmittel problemlos lötbar, aber ich weiß nicht, ob Du die passenden Leiterplatten für 6 mil Leiterbahnen selber so gut gefertigt bekommst. Und 4 Lagen sind für so ein Projekt nicht übertrieben. Den Spartan3 gibts auch noch eine Nummer kleiner, wenn ich mich recht entsinne, aber der braucht 3 Versorgungsspannungen. Die RAM-Blöcke musst Du über bausteinspezifische Bibliotheken konfigurieren und als VHDL Entity aufrufen. Für Pixelgrafik reichts nicht, da musst Du externes SRAM anschließen. Den PIC24 gibts entweder im 121 Ball BGA oder im TQFP100 mit 0.4mm Pitch. Beides ein Ausschlusskriterium für heimgefertigte Leiterplatten. Aber so teuer sind die Leiterplattendienste nun auch nicht. fchk
Hm, da muss halt dann alles mit dem ersten Wurf beim Layouten sitzen wenn ich's fertigen lasse. Oder ich lass mir ein Breakout vom Leiterplattendienst machen damit ich experimentieren kann und wenn's dann nicht mehr raucht und stinkt kann ich das finale Layout machen... Und dann kommt dann noch die Wartezeit dazu. Werde mich kommendes Wochenende mal dransetzen ein TQFP-100 zu machen. Hab hier einen 2560er rumfliegen zu dem ich mir ein Breakout Board machen wollte weil die Hersteller vom Arduino Board zu dämlich waren die XMEM Pins rauszurouten. Ganz schön schwach für ein Experimentierboard zu diesem Preis, aber naja, macht mans halt selber. Welches Flussmittel würdest du empfehlen?
Wolfgang M. schrieb: > Könnte ja sein dass man eine Linie blöderweise so zeichnet dass sie > teils noch im Aktiv gezeichneten Bild dargestellt wird, teils aber erst > im nächsten Bild erscheint. Ja und? Das fällt einem Menschen vor dem Display garnicht auf, und für den ist das Bild ja da. Wichtig wird das u.U. bei schnellen Darstellungen, z.B. Fussballspiele. Aber brauchst du das? Für normale Computergrafik wie eine Datenausgabe ist das nicht relevant. Gruss Reinhard
Gut aber dann stellt sich dennoch die Frage wie ich den einen Mikrocontroller dazu bringe ständig das FBAS zu generieren während der andere den Aufbau macht. Die Aufgabe muss ich aufteilen, mache ich das nicht ist mein FBAS hin. Und da brauche ich spätestens die Möglichkeit zwei gleichzeitige Speicherzugriffe auf verschiedene Adressen machen zu müssen, womit wir wieder bei 2 SRAMs wären oder nem Dual Port SRAM oder nicht?
Reinhard Kern schrieb: > Ja und? Das fällt einem Menschen vor dem Display garnicht auf, und für > > den ist das Bild ja da. Wichtig wird das u.U. bei schnellen > > Darstellungen, z.B. Fussballspiele. Aber brauchst du das? Für normale > > Computergrafik wie eine Datenausgabe ist das nicht relevant. > > > > Gruss Reinhard LOL, du willst so einen Kack verzapfen, wo schon der C64 vor 30 Jahren effektiv Dual Port zugriff aufs RAM hatte? Stell dir vor, du brauchst gar kein Dual Port RAM ... wenn das RAM schnell genug ist, dann kannst du den Bus einfach multiplexen. Aber vielleicht hast du ja auch noch nie was vom 74HC257 gehört.
Da müsste aber auch der uc schnell genug sein um das ram zu bechreiben, und das isser nicht wenn ich hohe Auflösungen generieren will.
Ausserdem wie stelle ich sicher dass sich beide uc nicht ins gehege kommen und der uc der die Bildausgabe macht immer priorität vor dem anderen bekomment. Vielleicht kannst du ja mal genauer schildern wie du dir sowas Schaltungstechnisch vorstellst.
Brauchst Du wirklich FBAS (Röhrenmonitor?) oder geht auch ein TFT-Display? Eventuell hilft Dir dieses weiter. http://www.mino-elektronik.de/TFT-direct-drive/TFT-direct-drive.htm Beachte dabei die Ausgabegeschwindigkeit/Zeichen beim STM32F4. Der ist richtig schnell! Ein AVR schafft "direct-drive" allerdings nicht.
Ich habe sowas mit AVRs realisiert. Je nach Auflösung, benötigter Rechenleistung, Timing etc. gäbe es da verschiedene Möglichkeiten. Wenn du einfach eine schnelle Lösung suchst, nehme ggf. ein FPGA oder einen µC mit HW-Video. Ansonsten ist es fraglich, ob du wirklich zwei Controller benötigst. Die Videoausgabe auf dem AVR benötigt ca. 60%-max. 70% und darin sind oft noch Takte frei für Berechnungen. Bei 20MHz sind das ca. 240-320MIPs je Seite über für die Grafik, ein C64 hatte dafür max 20MIPS. Wenn's dann doch 2 AVRs sein sollen, kann ich dir später gerne Tipps geben, wie ich das hier hinbekommen habe. Grüße Mark
Wolfgang M. schrieb: > Welches Flussmittel würdest du empfehlen? Gelförmiges aus der Spritze funktioniert bei mir am Besten. PS: Schau Dir auch mal den Epson S1D13781 an. Das ist ein Standalone-TFT-Controller mit 384k internem Video-RAM. fchk
Wolfgang M. schrieb: > Ausserdem wie stelle ich sicher dass sich beide uc nicht ins gehege > kommen Es ist viel einfacher als du denkst. Sieh dir mal das Timing von z.B. VGA an - während der aktiven Zeit innerhalb der Zeilen werden 640 Pixel ausgegeben, während Sync und Retrace kann der Controller ins RAM schreiben. Bei einem von mir schon vor Jahrzehnten eingesetzten Grafikcontroller muss auch nicht das ganze RAM immer wieder vollgeschrieben werden - der Bildspeicher ist da eben der Bildspeicher und was immer darin steht sieht man, der Controller bekommt nur den Auftrag z.B. eine Linie zu zeichnen von X1Y1 nach X2Y2 und schreibt nur die Pixel für genau diese Linie in den Bildspeicher (Bresenham in Hardware und daher sehr schnell). Wenn der Prozessor nicht der schnellsten einer ist, heisst das ja nicht, dass die Anzeige nicht funktioniert, man sieht nur einen langsamen Bildaufbau. Ein ganzes neues Bild pro vertikalem Durchlauf braucht man nur für Video. Übrigens steht bei Standard-Vga ca 25% der Zeit für den Controller zur Verfügung. Gruss Reinhard
> Und da brauche ich spätestens die Möglichkeit zwei gleichzeitige > Speicherzugriffe auf verschiedene Adressen machen zu müssen, womit wir > wieder bei 2 SRAMs wären oder nem Dual Port SRAM oder nicht? Ich wuerde ja einfach einen Microcontoller nehmen der bereits Dualportram integriert hat. Oder ist das jetzt zu einfach? Olaf
Ich hab mir das mal angesehen. Sieht gar nicht so schlecht aus. An die Möglichkeit HSNYCs und VSYNCs direkt ins Memory zu packen habe ich auch schon gedacht. Momentan läuft nur ein BAS Signal vom AVR raus das ich aber später aufbohren will und die Ausgabe soll farbig werden. Schön wäre es halt wenn ich auf der AVR Platform bleiben könnte wobei mir die PIC Lösung auch nicht schlecht gefällt. Bei mir muss es definitiv FBAS werden da ich von einer Kamera Daten per Composite zugeschoben bekomme und die Übertragung später vom Transmitter auch wieder Composite erwartet.
Momentan generiere ich das alles aber per Software, dass heisst ich habe keine Zeit im uC irgendwas zu tun, da HSYNC und VSYNC vom Code ausgegeben werden, genauso wie der Bresenham, den hab ich auch per Software implementiert. Hab auch bereits darüber nachgedacht ob nicht ein separater OSD Chip reichen würde, bin aber dann zu dem Schluss gekommen dass ich mehr als nur reinen Text ausgeben möchte, selbst wenn man sich beim OSD evtl durch einen eigenen Zeichensatz etwas mehr an Grafik selbst definieren könnte.
Habs mir gerade angesehen der Konverter von RGB auf Composite ist genau das was ich gebrauchen könnte. Wie die das allerdings mit den 4Kbyte vom Atmega 644 machen ist mir bis jetzt noch ein Rätsel. Das ganze Bild können sie da jedenfalls nicht speichern. Evtl werden da Sprites genutzt um das Bild live zusammen zu setzen.
Gibts da was von Atmel das Hobbytechnisch handhabbar ist bei dem man Dual Port SRAM verbaut hat?
@Reinhard: Was brauche ich denn noch zusätzlich zum uC selbst (Chip + Schaltungstechnisch) wenn ich die Lösung so angehen würde wie von dir vorgeschlagen? @Mark: Die Lösung deiner Schaltung würde mich auch interessieren. Dual Port kommt definitiv nachdem ich die Preise mal dafür gesehen habe nicht in Frage. RSOnline will für nen 55ns Dual Port SRAM mit 64K +ber 70 Euronen... Haben wir eigentlich hier im Forum irgendwo ne Minimalbeschaltung für nen Spartan3? Wäre ganz nett sowas mal zu sehen.
@ Wolfgang M. (procrash) >das was ich gebrauchen könnte. Wie die das allerdings mit den 4Kbyte vom >Atmega 644 machen ist mir bis jetzt noch ein Rätsel. Es gibt keinen vollen Bildspeicher, nur einen Zeichenspeicher ala 20x40 und eine farbige Zeichentabelle, wobei die im Flash liegt. > Das ganze Bild >können sie da jedenfalls nicht speichern. Evtl werden da Sprites genutzt >um das Bild live zusammen zu setzen. Das zusätzlich.
@ Wolfgang M. (procrash) >Gibts da was von Atmel das Hobbytechnisch handhabbar ist bei dem man >Dual Port SRAM verbaut hat? Nein. Dual Port RAM ist eher selten, Cypress baut welche, in FPGAs gibts die auch.
@ Wolfgang M. (procrash) >Haben wir eigentlich hier im Forum irgendwo ne Minimalbeschaltung für >nen Spartan3? Wäre ganz nett sowas mal zu sehen. Den gibt es als DIP-Modul! http://shop.trenz-electronic.de/catalog/product_info.php?products_id=636
Hab mich vielleicht falsch ausgedrückt. Ich meinte einen Schaltplan wo man den Spartan 3A mit minimaler externer Beschaltung sieht. Das Board von Trenz sieht gut aus. Kann man so bestimmt aufs Breadboard stecken...
Ich schau mir jetzt mal die Links die gepostet wurden näher durch. Vielleicht finde ich ja noch den einen oder anderen Denkanstoss. Danke jedenfalls schon mal für den Input Das was ich bisher mache ist nur ein SW Bild per BAS generieren. Da ist noch viel Luft im Code um zu optimieren. Könnte mir evtl auch Taktzeit erkaufen indem ich die Bits per Schieberegister rausschiebe und nicht per lsl und dann per output an den Port, somit müsste ich ne Doppelte Taktrate erreichen können und somit eine etwas höhere Auflösung. Zum Schluss sollte 640x480 rauskommen. Ob das erstmal SW oder in Farbe ist ist mir erstmal egal. Weiss leider aber nicht ob das zu erreichen ist und welche zusätzliche HW man da evtl noch braucht. Mal sehen.
> Gibts da was von Atmel das Hobbytechnisch handhabbar ist bei dem man > Dual Port SRAM verbaut hat? Nein, da musst du deinen Horizont auf Renesas erweitern. Da gibt es dann 64kByte Dualportram und 1Mbyte normales Ram im Prozessor. Olaf
Wolfgang M. schrieb: > Hab mich vielleicht falsch ausgedrückt. Ich meinte einen Schaltplan wo > man den Spartan 3A mit minimaler externer Beschaltung sieht. Das Board > von Trenz sieht gut aus. Kann man so bestimmt aufs Breadboard stecken... Anbei ein Projekt, was es nie zur Realisierung schaffte - das zugehörige LCD war nicht gut genug, es lohnte nicht. Ist also nicht getestet und damit ohne Gewähr. Stromversorgung: Das FPGA braucht 1.2V V_Core. V_aux ist fürs JTAG/Config-Interface und kann entweder 2.5V oder 3.3V sein. Beim Spartan 3 ohne A war V_aux auf 2.5V festgelegt. Das FPGA hat 4 IO-Bänke, jede mit ihrer eigenen Spannungsversorgung zwischen 1.2V und 3.3V. So kann man verschiedene IO-Standards implementieren. Das FPGA ist RAM-basiert und nach dem Einschalten leer. Die Konfiguration kann es entweder seriell oder Parallel als Slave von einem Controller bekommen, oder es kann sich die Daten als Master aus einem seriellen oder parallelen Flash holen. Beim Spartan 3 ohne A musste man Xilinx-Spezial-Flashes verwenden, die das spezielle serielle Konfigurationsprotokoll konnten. Die sind natürlich sauteuer. Der Spartan 3A kann auch normale SPI-Flashes wie ST25M80 (Flashes, keine EEPROMs, die wären eh zu klein) benutzen, die natürlich viel billiger sind. Der Spartan 3A XC3S200A braucht 149516 Bytes an Konfigurationsdaten, also für einen normalen AVR zu viel. Der XC3S200A (das größte, was Du löten kannst) hat 288kBits an Block-RAM, das sind 32kWorte zu je 9 Bit. Für Text plus Zeichengenerator reicht das, für Grafik nicht. Das Block-Ram ist echtes Dual-Port RAM. Wie gesagt: so kompliziert isses nicht, nur Fleißarbeit. Immer hübsch 0402 100n Abblockkondensatoren verteilen, dann passt das. Und denk an den Taktoszillator (hier 50 MHz). Per PLLs kannst Du Dir intern noch andere Takte generieren, aber einen Oszillator brauchst Du. 50 MHz sind nichts, was Du über mehr als ein paar mm Leiterbahn transportieren möchtest. Ich empfehle Dir: Schau Dir den vorgeschlagenen Epson Controller an. Der ist für Dich einfacher zu handhaben, auch weil er seinen Grafikspeicher eingebaut hat. Für ein normales FBAS-Signal reicht QCIF mit 352*288 Pixel (viertel Vollbild zu 704*576 Pixel) aus, und das müsste noch ins interne RAM des Controllers reinpassen. Wenn Du mehr brauchst: es gibt zig verschiedene Typen, auch welche mit mehr Speicher drin. fchk
Danke schonmal. Werde mal genauer drüber schaun. Ist jedenfalls schonmal ganz gut ne FPGA Beschaltung hier im Board zu sehen. Ich sehe mal was der Epson Controller so her gibt. Der PIC wäre ja evtl auch noch ne Alternative oder der Renesas, wobei mich VHDL schon auch reizen würde. Ich schau mal. Eins würde mich aber immer noch interessieren: Nur mal so theoretisch wenn sich jetzt ja auch herausgestellt hat dass es auch anders geht. Wie beschalte ich zwei single Port SRAMs so, sodass ich auf ein Dual Port SRAM verzichten könnte.
@Olaf: Werde ich machen. Die Website von oben sieht ja ganz vielversprechend aus.
Frank K. schrieb: > Das Block-Ram ist echtes Dual-Port RAM. Das Lesen ist nur in der Weise möglich, dass die Daten mit einer Taktflanke in ein nachgeschaltetes Register eingelesen werden. Und die Auslese-Logik scheint nur einfach ausgeführt zu sein, weil es für das Lesen beider Ports einen Mindest-Abstand der Taktflanken gibt. Allerdings: für die vorliegende Anwendung ist das wohl unwichtig, weil anscheinend nur ein Leseport benötigt wird und es nur auf die Unabhängigkeit von Lesen und Schreiben ankommt.
Wolfgang M. schrieb: > RSOnline will für nen 55ns Dual Port SRAM mit 64K +ber 70 > Euronen... Ich hab' für mein 12ns Soft-quadPort-SRAM nur 3,78 für 64kB bezahlt. :-) Meine aktuelle Version ist 'einfach' die Software so schreiben, dass beide AVRs sich einen gemeinsamen RAM (über 245er-Bustreiber) und Takt teilen. Geht aber nur in Assembler und die nötige Taktzählerei nervt manchmal. Die Software muss halt vollständig so geschrieben sein, dass jeder Speicherzugriff in einem festen Raster liegt. Wenn der Videoproz nur ausgeben soll ist das recht einfach, die Pixelausgabe sollte ja genauso exakt sein nur ggf. in einem anderen Rhythmus. Zumindest bei mehr als zwei AVRs dürfte man nur so die höchstmögliche parallele Zugriffsrate herausholen (ich schaffe hier 4x2MB/s@24MHz). Eine andere Möglichkeit ist, beide an einen RAM anschließen, Speicherzugriffe möglichst in Blöcke aufteilen und der Videoprozessor kann den anderen warten lassen. Ist so ähnlich wie in den 80ern. Je nachdem, wie man interne Berechnungen und Speicherzugriffe aufteilt lässt sich eine gute Rechenleistung herausholen. Kostet aber auch immer wieder Zeit auf dem Grafikprozessor. Nicht selber ausprobiert, aber mal konzeptioniert, ginge auch 2 RAMs zu verwenden und über 74x157er anbinden(jeden RAM an die Ausgänge eines Satzes 157er, Eingänge an die AVRs, und die gegeneinander umschalten). Der Videoproz. gibt einfach die Daten von 'seinem' RAM aus und der Grafikproz schaltet die um, wenn er eine Seite fertig berechnet hat, evtl. synchronisiert im nicht-sichtbarem Bereich. Die HW ist 'etwas' aufwendig(12 157er bei 2x32kB), dafür hat der Grafikprozessor die Kontrolle, und beide haben unabhängig die schnellste Anbindung an den Speicher. Die Uzebox verwendet, soweit ich weiß, Flash-Tiles (+RAM-Tiles???) und die Tilemap im RAM. Du kannst für die Pixelausgabe auch den SPI verwenden (am Besten USART als SPI wg. Doublebuffer). Wenn du dann noch die Ausgabe (2x4bit) eines Ports über einen 157er leitest gehen über den SPI auch 2von16 Farbena alle 8-bit. Je nach Takt gehen da auch 80-Zeichen bzw. 480(512) Pixel. Grüße Mark
Sorry, ich hatte eben etwas vergessen bzw. falsch beschrieben, für die Datenpins waren es keine 157er sondern bidirektionale, 40?? (hab die Notizen nicht griffbereit).
Das ist ausgefuchst. Die Beschreibung für zwei SRAMs gefällt mir. Zumindest war der Denkanstoss der selbe. Nur der Schaltungsaufwand ist ziemlich hoch. Ich brächte da mehr als nur 32KB externen SRAM. Ich dachte da eher so 128K oder so. Naja mal sehen es gibt ja noch alternativen. Was mir an dieser Lösung halt schön gefällt ist dass ich auf dem einen uC so ziemlich machen kann was ich will während der andere sich um die reine Ausgabe kümmert. Ich hab da noch vor Sensoren auszulesen und da wäre es schon schön wenn die Samplerate nicht durch irgendwelche Bildgenerierungsprozesse zerhackt wird. So jetzt kommt der Fleiß. Dann werd ich mich mal einlesen.
Eins noch. Kannst du mal näher schildern wie du dir das mit dem USART gedacht hattest? Das versteh ich leider nicht ganz.
Wolfgang M. schrieb: > @Reinhard: Was brauche ich denn noch zusätzlich zum uC selbst (Chip + > Schaltungstechnisch) wenn ich die Lösung so angehen würde wie von dir > vorgeschlagen? Ist zwar ein Rücksturz in die Steinzeit, aber mach dich schlau über den Video Controller 6845, darauf beruhen die Urväter und -Mütter der meisten PC-Grafikkarten. Der 6845 sorgt für die Ausgabeseite, mit entsprechend gesetzten Parametern erzeugt er das Video-Timing und erzeugt die zum Auslesen der Pixeldaten nötigen Adressen. M.a.W. wenn sich am Bild nix ändert, hat der Prozessor auch nix zu tun. Diese und ähnliche ICs ebenso wie der von mir verwendete 7220 sind heute nur noch schwer zu bekommen, weil diese Funktionen heute alle in komplexe Chips gewandert sind. 6845 sollte es aber noch geben. Ob SW oder Farbe ist eine Frage der Memory-Organisation und der Schieberegister zur Ausgabe. Für n Bit Farben benötigt man parallel n Bits an Ausgabe, das ist heute immer noch so. Einstieg: http://en.wikipedia.org/wiki/Motorola_6845 http://www.6502.org/users/andre/csa/vdc/index.html (Blockschaltbild am Ende) Gruss Reinhard
Klar sehe ich mir mal an, danke für den Link. Gibts denn den Chip in ähnlicher form noch irgendwo zu erwerben? Mein Ziel ist es möglichst mit wenig Hardware auszukommen. Das ganze soll später mal in nen Quadrocopter und deshalb auf ein kleines Layout.
@Reinhard: Das wäre quasi dann der Ansatz Adressgenerierung + HSYNC / VSYNC Erzeugung vom Chip. In der Tat dachte ich auch schon an sowas ähnliches. Die Grundidee war warum nicht einfach einen externen Counter als Baustein verwenden der die Adressleitungen immer schön hochzählt und das Byte für Byte. Das Byte würde dann in ein Schieberegister wandern und dann per DAC Wiederstandsnetzwerk die Signale erzeugen. HSYNC und VSYNC hätte ich dabei bereits im Speicher an den richtigen Timing Slots vorab beschrieben. Die Sache ist nur die. Der Memory wäre dauerhaft für nen Lesezugriff belegt und ich müsste den Takt irgendwie geschickt teilen. Wobei ich immer wieder auf das RAM Zugriffsproblem stosse. Besser wäre es einfach nen fetten Speicher direkt auf dem uC zu haben so wie das auf den anderen oben beschriebenen der Fall ist, mit ner Hardware die sich dediziert darum kümmert. Momentan tendiere ich ja zu dem PIC was ich gesehen habe. Aber das ist jetzt nur ein Bauchgefühl. Muss mir die Epson Lösung auch noch genauer ansehen. Aber je weniger Hardware desto besser da das Board klein werden soll.
Wolfgang M. schrieb: > Die Grundidee war warum nicht einfach einen externen Counter > als Baustein verwenden der die Adressleitungen immer schön hochzählt und > das Byte für Byte. Das Byte würde dann in ein Schieberegister wandern > und dann per DAC Wiederstandsnetzwerk die Signale erzeugen. So isses, das macht der 6845 und er macht auch HSYC und VSYNC. Es bleibt aber noch eine Menge Hardware übrig - vor allem brauchst du eben für jedes Bit ein Schieberegister. Anbei der Memory-Teil meiner Grafikkarte von vor etwa 40 Jahren, da wird jeweils ein 16bit-Wort ausgelesen und über die 2 HCT166 rausgeschoben. Bei 24bit-Farbe bräuchtest du das 24mal, da sollte man schon an ein FPGA denken. Zur Erläuterung: beim 7220 erfolgen alle Zugriffe vom Prozessor aus über den Datenbus DBx. Das Schreiben ins Videoram wird intern geregelt. Gruss Reinhard
Nachtrag: das mit den Schieberegistern kann auch leider nicht einem Prozessor übertragen werden, der Pixeltakt, mit dem die Schieberegister laufen, beträgt bei VGA 25 MHz, bei höher auflösenden Karten bis über 100 MHz. Gruss Reinhard
Sieht nett aus. Eagle ist dass sicher nicht oder ;-) Hab mir nochmals die Epson Lösung durch den Kopf gehen lassen. Das sieht eigentlich ziemlich genau nach dem aus was ich brauche. Zusätzlicher Chip mit integriertem RAM und jeder Menge Schnickschnack um verschiedene Auflösungen usw. zu konfigurieren. Da bräuche ich aber vermutlich noch die Konvertierung zum FBAS oder? VOm Projekt oben hab ich mir mal abgekupfert dass man dazu den AD725 nimmt oder? Somit hätte ich dann auf dem Board den Atmel, den Epson und den Konverter. Hm eine Frage stellt sich dann aber noch. Wie mache ich das mit dem Bild mischen?
Nachtrag 2: Er lebt noch: 6845 gibts gebraucht bei ebay für 5 Euro, oder auch als Open Source VHDL Modell für Xilinx FPGA. Wolfgang M. schrieb: > Sieht nett aus. Eagle ist dass sicher nicht oder ;-) Das Original war noch mit Kugelschreiber auf kariertem Papier. Die Schöpfer von Eagle waren da vermutlich noch nicht geboren. Gruss Reinhard
Wolfgang M. schrieb: > ich mir mal abgekupfert dass man dazu den AD725 nimmt oder? Somit hätte > ich dann auf dem Board den Atmel, den Epson und den Konverter. Hm eine > Frage stellt sich dann aber noch. Wie mache ich das mit dem Bild > mischen? Autsch. Das geht mit den Epson Controllern und dem PIC24 so nicht. Vorgehensweise: aus dem Eingangs-FBAS-Signal die Sync-Signale gewinnen (LM1881), per PLL den Pixeltakt aus dem HSYNC gewinnen. Für den Videocontroller sind Pixeltakt und HSYNC/VSYNC jetzt Eingänge und nicht mehr Ausgänge. Der Videocontroller gibt jetzt seine Daten raus und ein Umschaltsignal, das einen Analogswitch ansteuert, der zwischen Video-Eingang und Overlay umschaltet. Das Schlüsselwort heißt "Genlock-Fähigkeit". Das können die meisten Controller nicht. Der Commodore Amiga vor 25 Jahren konnte es und war damit eine Ausnahme. Für den Rest sind die Synchron- und Clocksignale nur Ausgänge, die sie treiben. Ein Videobild müsste hier erst digitalisiert und dann synchron zum Computerbild wieder ausgegeben werden. Solche Kisten nennt man Time Base Correctors TBC, und in den Dingern wird einiges an Aufwand getrieben, damit die sich auch nicht durch instabile Synchronsignale, wie sie bei schlechten VHS-Aufnahmen auftreten, aus dem Sync bringen lassen. Wenn Du das wirklich machen willst bzw musst, dann bleibt Dir nur die FPGA-Lösung. Nur hier kannst Du die Synchronsignale als Eingänge definieren. Oder Du pfeifst doch auf Grafik und nimmst einen OSD-Chip, der diese Mimik nämlich schon eingebaut hat. fchk
OSD wär halt die Billiglösung aber damit will ich mich nicht zufrieden geben. Ich schau mir mal deine Verschaltung nochmal genauer an. Im Grunde genommen sieht das schon recht minimal aus. Bestücken die Leiterplattendienste eventuell auch schon? Wo lasst ihr denn eure Boards so fertigen und mit was muss man für ne Eurokarte im Schnitt rechnen? Wenn ich mir die FPGA Lösung im Ansatz mal ansehe, dann wäre dass der FPGA, ein Mikrocontroller der den FPGA mit der Konfiguration belädt und später die Sensordaten auswertet und das Videobild definiert, der LM1881 fürs Signaltrennen (wobei ich gesehen habe dass meine Kamera HSYNC und VSYNC bereits auf nen Pin Breakoutet), und einen externen SRAM der vom FPGA und vom Mikrocontroller geshared wird, da er selbst nicht genug Speicher hat um das vollständige Bild darzustellen. Aber dann bin ich ja wieder bei meinem Problem von oben, dass ich konkurrierende Speicherzugriffe habe oder nicht? Könnte ich nicht automatisch den HSYNC / VSYNC nutzen um in dieser Zeit das Bild im Speicher aufzubauen. Das wäre doch noch ne Möglichkeit oder? Dann könnte ich evtl sogar auf den FPGA verzichten. Während der Bildaufbauphase würde der uC selbst aktiv sein und das Signal entweder von der Kamera oder von sich selbst multiplexen. Wird hingegen gerade von der Kamera das HSYNC oder VSYNC Signal generiert kümmere ich mich ums Sensorlesen bzw um den Bildspeicher z.B. zum Linien zeichnen. Wenn ich das ganze noch irgendwie RLE encodiert ablege, so könnte ich einerseits Speicher, und andererseits CPU Last sparen, weil die CPU weiss wann sie in den Bildausgabeprozess wieder selbst aktiv werden muss und somit sich mehr um den Bildaufbau als um die Ausgabe kümmern kann.
Was mir noch dazu einfällt: Könnte es sein das die Kommunikation des uController dann über den FPGA mit dem SRAM laufen kann. Der hat doch Dual Port Ram was man als Buffer verwenden könnte oder? Ausserdem könnte ich mir auf dem FPGA selbst doch einen uC synthetisieren der Bidlaufbau usw machen könnte oder?
Keine Panik. Bei PAL und QCIF Bildformat 352*288 Pixel dauert ein Pixel etwa 140 ns. Wenn Du SRAM mit 10ns oder 15ns verwendest, passen einige Schreib/Lesezyklen in eine Pixelzeit hinein. Das sollte für beide reichen. fchk
Gut gut. Danke für die Hilfe. Waren echt viele Kommentare und Anmerkungen bis jetzt.
Josef G. schrieb: > Frank K. schrieb: >> Das Block-Ram ist echtes Dual-Port RAM. > ... > Und die Auslese-Logik scheint nur einfach ausgeführt zu sein, > weil es für das Lesen beider Ports einen Mindest-Abstand > der Taktflanken gibt. Korrektur: Ich kann die Stelle in der Dokumentation nicht mehr finden, wo ich glaubte, das gelesen zu haben. Mein Beitrag war Mist.
Man kann den SPI beim AVR als Schieberegister verwenden und so bspw. 8 Pixel in SW automatisch ausgeben. Der normale SPI hat den Nachteil, dass es zwischen den Bytes immer eine kurze Lücke gibt, USART als SPI auf einigen AVRs hat einen Puffer und und kann dadurch einen durchgängigen Bit-Stream ausgeben. Man kann dann auch den SPI-Ausgang nutzen um einen Multiplexer umzuschalten, high- und low-nibble eines AVR-Ausgangs für Vorder- und Hintergrundfarbe. So typische 80er-Grafik mit 8x8 Pixel-Farbraster in 16 Farben lassen sich so halt auch noch in höheren Auflösungen (512pixel@24MHz hor. geht, mehr habe ich nicht ausprobiert) einfach realisieren. Für die eigentliche Ausgabe ist dann nur noch alle 8 Pixel ein 'out/sts UDR' und ggf. ein 'out PORT,Farbe' nötig. Anders dürfte das gar nicht gehen. Würde man 512 Pixel manuell ausgeben, bleiben nichtmal genügend Takte um die Daten aus dem internen SRAM überhaupt zu lesen. Mir ist noch eingefallen, dass ich hier VRAM liegen habe aus einer uralten Hercules-Karte: MT42C4256, die waren billig und hatten dual-port-Funktionalität speziell für Pixelausgabe. Weiß aber nicht, ob es heute sowas noch gibt. Reinhard Kern schrieb: > Die > Schöpfer von Eagle waren da vermutlich noch nicht geboren. Eagle stammt aus den 80ern, die Schöpfer müssten demnach BJ vor 1970 sein ;-) Grüße Mark
Mark L. schrieb: > Eagle stammt aus den 80ern Ist mir damals nicht aufgefallen (wie lange gibts denn dieses Forum schon?), erst so seit 95. Dabei gehörte ich laut Statistik zu den ersten 400 CAD-Anwendern in Deutschland überhaupt, nicht nur Elektronik-CAD. Gruss Reinhard
Hallo, wenn du deine Ausgabe mit einem Kamerabild mixen willst, gibt es prinzipiell 2 Möglichkeiten: A Du liest das Kamerabild in einen Bildspeicher ein, manipulierst den Speicherinhalt durch deinen Prozessor, indem du z.B. Text reinschreibst, und gibst das Bild wieder aus, logischerweise mit einer Verzögerung. Das ist das was Frank mit TBC meint und sehr sehr aufwendig. B Du schleifst das Bild von der Kamera im Wesentlichen durch an den Ausgang, nimmst aber die Sync-Signale um im Prozessor Zeilen und Pixel mitzuzählen, parallel dazu baut dein Prozessor ein eigenes Bild auf in einem eigenen Bildspeicher (nicht notwendigerweise so gross wie der für die Kamera), und dessen Inhalt mixt du in das Videosignal rein indem zu z.B. bei einer 1 das Signal umschaltest von Kamera auf eine feste Farbe - dazu brauchst du einen entsprechend schnellen Video-Multiplexer (Schaltzeiten für Analogsignale so um 10 ns, ist auch nicht ganz trivial, wie ich erst kürzlich festgestellt habe). Damit sparst du dir das Einlesen des Bildes, wofür du ja auch sehr schnelle ADCs bräuchest, Wandlungszeit bei VGA weniger als 30 ns. Also bei A mixt du im Speicher und bei B mixt du im laufenden Videosignal. Gruss Reinhard
Reinhard Kern schrieb: >> Eagle stammt aus den 80ern > > Ist mir damals nicht aufgefallen (wie lange gibts denn dieses Forum > schon?), erst so seit 95. Ich habe hier noch Eagle Dateien auf der Platte, die von 1990 sind. fchk
>Eins würde mich aber immer noch interessieren: Nur mal so theoretisch >wenn sich jetzt ja auch herausgestellt hat dass es auch anders geht. Wie >beschalte ich zwei single Port SRAMs so, sodass ich auf ein Dual Port >SRAM verzichten könnte. Für x-fache Ports, je Port RD-WR-Zwischenregister, die nach aussen asynchr die CPUs versorgen, nach innen gemuxt auf ein SRAM gehen. Dafür muss das SRAM (im Groben) min. die x-fache Geschwindigkeit haben. Bei >= 2 WR-Zugriffen auf die gleiche SRAM-Stelle soll INT ausgelöst werden können.
Also den UART zu verwenden für ne lückenlose Bildausgabe finde ich ja sowas von Genial. Da wär ich nie draufgekommen. Hatte mir gedacht ein externes Schieberegister zu verwenden um mir Prozessorzeit zu erkaufen aber dass ist echt genial. Schaltungstechnisch werde ich wohl Lösung b bevorzugen da ich mir damit am meisten CPU Zeit für andere Dinge erkaufe. Vielleicht muss der Speicher dann auch nicht so fett sein. Was ich allerdings gerne hätte wär ein linear adressierter Speicher. Sprich Speichergröße = Bildgröße aber mal sehen wie viel Aufwand ich bereit bin in die Software zu stecken. Ich könnte bei meinem 2560er sogar mehrere UARTs verwenden um nahtlos die Transparenz zu schalten. Sprich ein UART regelt das Wiederstandsnetzwerk sprich zwischen 0.3 und 1Volt während der andere UART die Transparenz regelt. Werde mir kommendes Wochenende mal endlich das Breakout Board für den 2560er machen, da ich den externen Speicher gerne über das XMEM Interface anbinden wollte (-> da das schneller als alles in SW über Ports zu machen). Weiss jemand ob ich dazu unbedingt das Latch brauche oder ob das XMEM I-Face auch so konfigurierbar ist dass ich den weglassen kann und die Zugriffe dann schneller sind. Hab dazu bei uns im Forum nichts gefunden, da ist nur die Schaltung mit 74HC573 drin. Der Aufwand von mehr Pins stört mich dabei nicht besonders, da der Chip ja genug davon hat.
@FCHK: Zu der Lösung per FPGA. Ich habs immer noch nicht ganz begriffen. Der Speicherzugriff mit dem FPGA wäre ja in der Zeit gemultiplext. Sprich Adress und Datenleitungen des RAMs wären ja sozusagen gleichzeitig mit uC und FPGA verbunden. Jetzt grübel ich mal kurz nach. Der FPGA würde bei einer Auflösung von 640 Pixeln in horizantaler Richtung bei eines Fenster von 52us (64us - 12 us für HSync und Burst) ja in etwa alle 81,25ns auf den Riegel zugreifen. Der uC selbst kann maximal mit 16 Mhz Takt also spricht einen Zugriff in 62,50ns schaffen. Moment, eigentlich sogar erst in 62,50ns*3=187,5ns laut DB also sogar noch einen Takt mehr. Extern sollten die Adress- und Datenleitungen auch dann zu flackern anfangen wenn ich nur auf internen Speicher Zugreife. Somit wird jeder Speicherzugriff vom uC in irgendeiner Form Zugriffe des FPGAs korrumpieren. Und ich schreibe ja nicht nur ein Byte, ich schreibe ja mehrere hintereinander vom uC wenn ich eine Linie im Speicher zeichne. Hab mit Multiplexing bisher allerdings auch noch nicht viel gemacht muss ich gestehen, bis auf ein paar 7 Segmentanzeigen gemultiplext. Ein Schaltplan wäre da ganz hilfreich wie sowas prinzipiell aussieht.
Das Ram ist ausschließlich am FPGA angeschlossen, das macht alles. Alle Schreibzugriffe müssen über das FPGA gehen, das damit sicherstellen kann, dass die Zugriffe passend synchronisiert sind. 640 Pixel in X Richtung ist für ein FBAS Signal zu viel. Da kannst Du nachher nichts mehr lesen. QCIF 352*288 ist das Maximum, was bei der beschränkten FBAS Bandbreite lesbar bleibt. fchk
Ah ok. Das macht jetzt Sinn. Mit lesbar beziehst du dich auf Text denke ich oder?. Ich will aber nicht nur Text, sondern auch Grafik machen. Sprich Linien / Kreise zeichnen. So wie man das von nem HUD in nem Flugzeug her vielleicht auch kennt. Vom Code her habe ich das ganze schon soweit getrieben dass ich die Auflösung mal mit dem Atmega 1284p mit 20MHZ noch auf 640 Pixel angefahren habe. Allerdings ging mir dann der Speicher aus und ich konnte nicht die vollen 480 Zeilen darstellen. Text war lesbar aber ich musste schon wie du gesagt hast die einzelnen Zeichen größer definieren.
Wolfgang M. schrieb: > Somit wird jeder Speicherzugriff vom uC in irgendeiner Form Zugriffe des > FPGAs korrumpieren. Natürlich muss das "irgendwie" sybchronisiert werden, dazu gibts allerdings viele Möglichkeiten. Jedenfalls können Prozessor und Video Out nicht einfach asynchron nebeneinander her laufen. Bei VGA wird ein Byte für die Anzeige alle 320 ns gebraucht, man kann aber in weniger als 100 ns zugreifen, wenn man den geigneten Speicher hat, dann stehen die übrigen rund 200 ns dem Prozessor zur Verfügung. Der muss also notfalls warten, wozu ein WAIT-Eingang sehr praktisch ist. Da er aber definitiv alle 320 ns drankommt, würde der Prozessor nicht besonders beeinträchtigt. Man kann auch umgekehrt freie Prozessorzeit für Video Out verwenden, aber das ist viel schwieriger, weil der Prozessor viele verschiedene Zyklen hat. Das ganze ist natürlich eine Timing-Pfriemelei, aber das Einhalten von Setup- und Holdzeiten ist viel einfacher, wenn z.B. der Prozessor mit dem Pixeltakt von 25 MHz betrieben wird oder mit der Hälfte davon. Also Step by Step: du entwirfst ein Video Ram mit Schieberegisterausgabe und einer Taktung von PixelClk/8, so dass vom Taktzyklus nach dem Lesen noch möglichst viel übrig bleibt, und überlegst dir, wie du den Prozessor dazu bringst, einen Zugriff darauf immer nach dem Ende des Video-Zugriffs durchzuführen (aber auch nicht viel später, notfalls den nächsten Zyklus abwarten). Das hat man schon in den 70er Jahren des vorigen Jahrhunderts geschafft, also kannst du das auch hinkriegen. Gruss Reinhard
Hm. Danke für dein Vertrauen. Ich schaff das auch. Wenn ich mich einmal an was fest beiße dann bleibe ich am Ball bis ich's hab. Kann man jetzt als positive oder negative Charactereigenschaft ansehen. Vielleicht sitz ich ja noch nächstes Jahr dran hehe, aber das ist ja das schöne wenn man sein Hobby nicht zum Beruf hat ;-) Vielen dank für den Input Leute. Sehe dass inzwischen schon 61 Posts gemacht wurden. Sagenhafter support hier im Forum.
Wolfgang M. schrieb: > Ah ok. Das macht jetzt Sinn. Mit lesbar beziehst du dich auf Text denke > ich oder?. Ich will aber nicht nur Text, sondern auch Grafik machen. > Sprich Linien / Kreise zeichnen. So wie man das von nem HUD in nem > Flugzeug her vielleicht auch kennt. 480 Zeilen geht bei FBAS nur über Interlace, dem Zeilensprungverfahren. Beim Amiga, der das alles normgerecht konnte, hat das furchtbar mit 25 Hz geflimmert, insbesondere dünne horizontale Linien. Daher machs nicht. Alle Heimcomputer der 80'er haben nur 320*200 oder 320*256 gemacht + Rand. Mit Overscan kommt Du bei PAL auf 352*288. fchk
Vermutlich hast du recht. Ich muss aber wie auch immer 640x480 als Bilddaten bereitstellen, weil ich zum Kamerabild die Grafik dazu mixe. Ich werd den Text dann halt größer machen, so dass er lesbar wird.
Wolfgang M. schrieb: > Vermutlich hast du recht. Ich muss aber wie auch immer 640x480 als > Bilddaten bereitstellen, weil ich zum Kamerabild die Grafik dazu mixe. Wieso? Das eine hat mit dem anderen nichts zu tun. Wie gesagt, von den 640 Pixeln hast Du nur einen höheren Aufwand, und bei 480 Rasterzeilen musst Du zusätzlich noch gerade und ungerade Halbbilder (vergiss nicht: Zeilensprungverfahren!) auseinander sortieren und zu jedem Halbbild die passende Rastergrafik ausgeben. Ich weiß nicht, ob Du weißt, was für einen zusätzlichen Aufwand Du Dir da für nichts einfängst. Ich habe schon meinen Grund, weswegen ich Dir 352*288 Pixel nahelege. fchk PS: Lies das! http://de.wikipedia.org/wiki/Zeilensprungverfahren
Hast recht. Interlacen will ich wirklich nicht. Da müsste ich ja auch den ganzen Speicher zerhacken. Danke für den Link
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.