Ich habe vor ein kleines Display (160x128px 18bit) zu verwenden. Um mir ein wenig Prozessorlast zu sparen und dennoch ein schönen schnellen Bildaufbau zu haben dachte ich, das es wohl am besten wäre, wenn ich dieses über einen FPGA / CPLD mache. Nun meine Vorstellung: Der FPGA / CPLD bekommt einen Speicher bisschen mehr als 2x der Größe des Bildinhaltes. Am Anfang des Speichers wird das "Hintergrundbild" gespeichert. Danach kommen mehrere kleine "Bilder" ca. 8x8px. Desweiteren gibt es eine Tabelle in welcher steht an welchen Positionen die Bilder im Speicher hinter dem Hintergrund im Bild über den Hintergrund geschrieben werden sollen. Auch können in dieser Tabelle Linien und Rechtecke angegeben werden. Somit könnte man Cursor // Schriftarten / häufige Muster "einfügen" ohne diese bei jeder Bewegung / Veränderung neu schreiben zu müssen. Nun meine Frage: Ist der Gedankengang so machbar oder gibt es bessere / andere Lösungen.
Ist aber schon eine ganze Menge aufwandt. Aber durchaus. Ich hatte mal ein Display, welches immer 8Bit in Spalten wollte. So musste ich mir die 8Bit im Puffer immer zusammensuchen. Das könnte der CPLD machen. Aber dann benötigst du vielleicht eine SPI um mit dem Controller zu kommunizieren und das Display-Interface musst du auch implementieren.
Also so wie ich das verstanden habe willst du ein Spiel programmien mit festem Hintergrundbild auf dem sich Sprites bewegen. Da die Auflösung sehr gering ist: Was spricht gegen einen uC mit einer eingebauten 'Grafikkarte' und genügend RAM? Bspw. bei PICs (hier werden aber auch um mögliche Alternativen aufgelistet, und bei anderen Herstellern wird es sicherlich ähnliches geben): http://www.microchip.com/pagehandler/en-us/technology/graphics/technology.html http://www.microchip.com/pagehandler/en-us/technology/graphics/products/home.html
Gegen PIC spricht, das ich mit Atmel aufgewachsen bin, und daher erstmal dort bleiben möchte. Desweiteren habe ich bereits angefangen mich mit dem AT32 aus einander zu setzen. Theoretisch würde dieser µC es auch schaffen, das Display zu verwalten. Ich möchte mir aber freihalten ggf. stark Leistungshungrigen Code zu verwenden, ohne dass der Bildaufbau darunter leiden muss. Bzgl. deiner vermutung eines Spieles: Spiele sollen später auch kommen. Erstmal geht es um sowas wie einen "Desktop", Menuehintergründe. Das ganze soll primär als Schnittstelle bzgl. eines Hausbusses dienen, aber auch Audio/Video abspielen können (wird ein mobiles Gerät).
Michael D. schrieb: > Gegen PIC spricht, das ich mit Atmel aufgewachsen bin, und daher erstmal > dort bleiben möchte. Soso. Du möchtest also nicht den Videobeschleuniger des PIC24FJ256DA210 benutzen, der selber ohne Prozessorhilfe Pixel verschieben und füllen kann. Ich bin mit Z80 aufgewachsen, weißt Du. Das ist aber schon fast 35 Jahre her. Ein paar Jahre später kamen 6502, 68k, 8086 dazu. Es schadet gar nichts, mal den Blickwinkel zu wechseln. Das hilft gegen Verbohrtheit und hilft, optimale Lösungen zu finden. Und ich tippe mal, dass die Einarbeitung in PIC24 (der so gut wie gar nichts mit den 8 Bit PICs zu tun hat) Dir einfacher fällt als die Einarbeitung in VHDL. Und einen neuen Programmer brauchst Du ohnehin. fchk
Vergleichen wir mal den von dir angebotenen PIC24FJ256DA210 mit dem aktuell eingeplanten und schon fast fertig gerouteten AT32UC3B0512: CPU 16MHz vs. 60MHz Programm Memory 256kB vs. 512kB Ram: 98kB vs. 96kB PinCount 100 vs. 64 D/A Wanlder: keine vs. 2x 16Bit DMA Channel: 2 vs. 7 Stromverbrauch: 18mA vs. 5,3mA Umgebung: Akkubetrieb, geringer Platz. Pro AT32: CPU >3x Takt bei gleichem Stromverbrauch Doppelter Speicher Halb so viele Pins D/A Wandler Onboard (Grund für meine Whl dieses Chips) Pro PIC: Hardware für Ram und Display
wieder kann ich nur von PICs reden, da ich die eben nutze: Microchip bietete eine komplette Bibiliothek für deinen Einsatzzweck an, die dir erlaubt Objekte wie Buttons, Bilder, Graphen, ... zu erstellen und Objektorientiert anzusprechen: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en543091 Präsentation als PDF zum Aufbau: http://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en542831.pdf Beispielvideo (16-Bit): http://www.youtube.com/watch?v=rFWVKqY8jWA Beispielvideo auf einem 32-Bit PIC: http://www.youtube.com/watch?v=9vf2dAW3Uc4 Simple Anwendung der Library in einem Starter-Kit (16-Bit) (paar Spiele, Potispannung grafisch auslesen, ...) (Source Code ist frei verfügbar): http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535092 Eine kurze suche bei Atmel brachte mich zu einem Widget Toolkit http://asf.atmel.com/docs/latest/uc3a/html/group__wtk__group.html Das wahrscheinlich ähnliches macht. Beispielcode musst du hier aber selber suchen, da ich nicht weiß was Atmel da anbietet. Generell denke ich aber wird der Weg über diese Libraries der vor allem für deinen Zweck sinnvollere sein. Bzgl. deinem Vergleich: Ich wusste nicht dass du solch einen großen 32-Bit uC verwendest, da dann die Auslagerung der Grafik bei solch einem winzigen Display maßlos übertrieben ist, zumal du ja auch mit deinem AVR genug RAM hast und da nichts auslagern musst. Willst du ihn mit einem PIC vergleichen, so vergleiche ihn bitte auch mit einem 32-bit PIC und nicht einem 16-bit, der dann wieder einen selben Leistungsumfang hat. bspw. (wild ausgewählt) PIC32MX795F512L mit 125 DMIPS, 128kb RAM, etc. Jedoch zwingt dich niemand zu PIC zu wechseln, ich kann halt nur von PICs sprechen da ich die benutze, aber ATMEL bietet ja ähnliches an (widget toolkit) Wie gut, keine Ahnung. btw. dein AVR verbraucht laut Atmel Homepage 23mA @ 3.3V @ 60Mhz http://www.atmel.com/devices/at32uc3b0512.aspx
Frank K. schrieb: > Michael D. schrieb: >> Gegen PIC spricht, das ich mit Atmel aufgewachsen bin, und daher erstmal >> dort bleiben möchte. > Ich bin mit Z80 aufgewachsen, weißt Du. Das ist aber schon fast 35 Jahre > her. Ein paar Jahre später kamen 6502, 68k, 8086 dazu. Deine Erinnerungen täuschen dich, der 6502 war zuerst, die anderen folgten kurz danach: 6800 1974 6502 1975 Z80 1976 8086 1978 68k 1979 MfG,
Das Auslagern der Grafik soll mehr ein Projekt sein als ein nötiges Mittel. Voteil dabei ist, dass auch noch alles sauber läuft, wenn ich mal nicht soo sauber geschriebene Programme laufen habe. Den Strombedarf habe ich aus dem Datenblatt der AT32UC3B Serie, welcher auf Seite 615 mit 18,5mA @ 60Mhz angegeben ist. Für 16MHz steht als Formel 0,3x16MHz+0,443mA. Bzgl. der Bibliotheken, ist es so das ich immer gerne 100% Code selber schreibe. Die einzigen Codeteile, die ich nicht selber schreibe sind die "Delay" sowie EEPROM zugriffe. VHDL brauch ich eig. nurnoch wieder auf zu frischen, habe ich bereits mit gearbeitet gehabt. Bei deinem 32Bit PIC gefällt mir die Ethernet Schnittstelle, allerdings würden mir hier wieder die DA Wandler fehlen. Sobald es sich lohnt eher einen PIC anstelle eines Atmel zu verwenden, werde ich mich da auch umschauen, aber wozu wenn das auch alles mit dem Atmel geht, wo ich den Programmer habe und mir keinen neuen anschaffen brauch. Edit: Sehe gerade, das ich den Stromverbrauch eines bis 256kB Chips verwendet hatte. Beim 512er sind es 24mA @ 60MHz und ~7,3mA @ 16MHz
Michael D. schrieb: > Vergleichen wir mal den von dir angebotenen PIC24FJ256DA210 mit dem > aktuell eingeplanten und schon fast fertig gerouteten AT32UC3B0512: Man fängt natürlich erst dann zu routen, wenn ALLE technischen Details stehen. Brauchst Du die CPU-Leistung wirklich? > D/A Wanlder: keine vs. 2x 16Bit 16 Bit aus einem mit digitalem Rauschen verseuchten Controller? Die letzten 3-4 Bit wirst Du wohl wegwerfen können - das ist so meine Vermutung. Ist das für Audio? In Handys werden dafür normalerweise externe I2S/TDM-Codecs verbaut, die gleich noch einen Class D bzw Class G Verstärker für einen kleinen Speaker bzw Headphones haben. Weil sie extern sind, kann man sie so platzieren und beschalten, dass sie möglichst wenig noise aufnehmen. > Stromverbrauch: 18mA vs. 5,3mA Der Stromverbrauch ist bei CMOS-Schaltungen immer proportional zum Takt. Das Display wird Dir den Stromverbrauch allein schon durch den Zugriff auf den Bildspeicher hochtreiben. Das ist einfach so. Auch ein FPGA wird Dir den Stromverbrauch in die Höhe treiben, und das alleine schon durch die hohe Anzahl an Transistoren, von denen Du vielleicht 20% für Deine Funktionalität brauchst. Du musst immer das Gesamtsystem sehen und nicht nur Deinen Prozessor. TIP: Wenn Du die Rechenleistung wirklich brauchst und eine hohe Grafikleistung haben willst, nimm einen Controller mit integriertem TFT-Controller. Wenn der PIC24 nicht reicht (ich kenne Deine Anforderungen nicht), dann wirds eben ein NXP LPC1850 oder so werden müssen. Alternative: Energy Micro Giant Gecko, sehr sparsam, da gibts auch Versionen mit integrierten TFT-Controller. Wenn Du Deinen AVR32 behalten willst, dann nimmst Du am Besten ein Display mit integriertem Controllerchip (z.B. ILI93xx) und integriertem Speicher und 8080/6800 Memory Businterface. Diese Teile sind allerdings langsam, weil der Prozessor nur indirekten Zugriff auf den Grafikspeicher hat (Index/Datenregister). Und: Kein Grafikbeschleuniger, der Prozessor muss alles machen, Dein FPGA darfst Du streichen (was aber auch Deinen Strombedarf senkt). Mir kommt das alles so vor, als würdest Du irgendwie nicht zu Ende denken, sondern einfach loslegen, und Dich dann beschweren, dass Du am Ende Arbeit doppelt und dreifach gemacht hast. Unprofessionell. fchk
Fpga Kuechle schrieb: > Frank K. schrieb: >> Michael D. schrieb: >>> Gegen PIC spricht, das ich mit Atmel aufgewachsen bin, und daher erstmal >>> dort bleiben möchte. > >> Ich bin mit Z80 aufgewachsen, weißt Du. Das ist aber schon fast 35 Jahre >> her. Ein paar Jahre später kamen 6502, 68k, 8086 dazu. > > Deine Erinnerungen täuschen dich, der 6502 war zuerst, die anderen > folgten kurz danach: > > 6800 1974 > 6502 1975 > Z80 1976 > 8086 1978 > 68k 1979 Aber nicht für mich. Ich hatte zuerst eine Z80-Maschine, den C64 (als Henkelmann SX64) gabs erst viele Jahre später zu Weihnachten. fchk
Frank K. schrieb: > die gleich noch einen Class D bzw Class > G Verstärker für einen kleinen Speaker bzw Headphones haben. Hört sich interessant an, dann kann ich die Kopfhörerendstufe durch einen solchen ersetzen. Frank K. schrieb: > dann nimmst Du am Besten ein > Display mit integriertem Controllerchip Das Display hat einen integrierten Controller ... SEPS525 An den Stromverbrauch des FPGA habe ich garnicht gedacht .. werde das ganze nochmal überdenken doch intern zu machen. Frank K. schrieb: > Mir kommt das alles so vor, als würdest Du irgendwie nicht zu Ende > denken, sondern einfach loslegen, und Dich dann beschweren, dass Du am > Ende Arbeit doppelt und dreifach gemacht hast. Unprofessionell. Einfach loslegen: Im laufe der Zeit kommt immer noch ne Idee :Þ Beschweren: Nein, warum sollte ich mich bei mir selbst beschweren. Unprofessionell: Ja, aber das darf beim Hobby ja auch so sein. Die Rechenleistung brauche ich eig. nicht, aber kann ja immer noch kommen. Das Gerät soll nicht als "Hergestellt und Fertig" verwendet werden, sondern als Gerät um immer neue Programme zu schreiben.
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.