Ich möchte gerne eine Grafikanwendung auf einem µC betreiben. Die erzeugten Bilder sollen auf einem SPI-Display (z.B. dem hier: https://www.ebay.de/itm/2-4-SPI-TFT-LCD-Display-2-4-Inch-Touch-Panel-LCD-ILI9341-240x320-5V-3-3V/201950756194) dargestellt werden. Nach meiner Rechnung benötige ich für den Pixelbuffer (R, G, B) mindestens 1.84 Mbit RAM. Die Pixeldaten müssen ständig im Speicher gehalten werden, da das Ergebnis einer vorherigen Berechnung für die Nächste benötigt wird. Als "Machbarkeitsstudie" wollte ich das auf einem 8-Bit Controller erledigen. Das Programm läuft im normalen RAM des µC und bei Bedarf werden die 3 Byte aus dem externen RAM geladen, verarbeitet und wieder zurückgeschrieben. Nach der Verarbeitung werden sie außerdem an das Display zur Darstellung gesendet. Bei Mouser gibt es da jetzt nicht so eine große Auswahl (eigentlich nur einen, wenn man bedenkt, dass der andere SRAM nicht verfügbar ist): https://www.mouser.de/Semiconductors/Memory/SRAM/_/N-4bzpt?P=1z0w12pZ1z0y176&pop=3i6n7 Könnte es damit klappen oder gibt es günstigeren, externen RAM, mit dem ein 8-Bit µC noch umgehen kann?
Du hast Dir da den falschen Mikrocontroller ausgesucht. Derart viele Daten kann man damit theoretisch verarbeiten, es wird aber sinnlos kompliziert. Schon alleine deswegen, weil kein aktueller 8bit Mikrocontroller so viel RAM direkt adressieren kann. Tue Dir das nicht an, es sei denn du musst für irgend eine Sünde Buße tun. Nimm lieber einen Mikrocontroller, der von Hause aus genug RAM enthält. Zum beispiel einen STM32F676 (http://www.st.com/en/microcontrollers/stm32f7x7.html?querycriteria=productId=LN1998). Entsprechende Entwickler-Boards samt Debugger bekommt man fast geschenkt: https://www.amazon.de/STM32-ST-NUCLEO-F767ZI-Nucleo-Development/dp/B072MMZZBK/ref=sr_1_fkmr1_2?ie=UTF8&qid=1522746515&sr=8-2-fkmr1&keywords=stm32f407+nucleo
Max M. schrieb: > dargestellt werden. Nach meiner Rechnung benötige ich für den > Pixelbuffer (R, G, B) mindestens 1.84 Mbit RAM. Den Buffer kannst Du auch mit 8 Bit pro Pixel betreiben, indem Du für R und G je drei Bit (Augenempfindlichkeit) und B 2 Bit spendierst. Oder gleich monochrom und 1-2 Bit pro Pixel. Zudem kannst Du Quadrate von 2x2, 3x3 oder 4x4 Pixeln auch als ein logisches Pixel behandeln. Für eine Machbarkeitsstudie wär's vielleicht gut genug?
> Zum beispiel einen STM32F676
Sorry, sollte STM32F767 heissen
Stefan U. schrieb: > weil kein aktueller 8bit > Mikrocontroller so viel RAM direkt adressieren kann. Deswegen der verlinkte SPI-RAM, damit geht das ja (wenn auch viel langsamer). Nop schrieb: > Für eine Machbarkeitsstudie wär's vielleicht gut genug? Soweit ich mich jetzt nicht verrechnet habe, käme ich immer noch auf mindestens 75 kBit, und ein Farbdisplay im S/W-Modus zu verwenden, naja... Und bei den restlichen Vorschlägen scheint ein externer RAM auch unumgänglich. Das spannende ist, wenn man sowohl das Display als auch den RAM per SPI ansteuert, man gerade mal 5 I/Os benötigt, eigentlich nur 4, wenn man vom Display nichts lesen will.
:
Bearbeitet durch User
@Max MMM (maxmicr) >dargestellt werden. Nach meiner Rechnung benötige ich für den >Pixelbuffer (R, G, B) mindestens 1.84 Mbit RAM. Das sind ~230kB RAM, ganz schön viel für einen 8-Bitter. >Als "Machbarkeitsstudie" wollte ich das auf einem 8-Bit Controller >erledigen. Kann man machen. Such dir ein Board, das den Speicher schon drauf hat, z.B. das AVR Explained mit einem ATXmega. Ist zwar nicht ganz taufrisch, hat aber 8 Mbit Speicher drauf, den man leidlich brauchbar nutzen kann. http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=ATAVRXPLAIN Kriegt man gebraucht für wenig Geld, ich hab auch noch eins rumliegen. >Bei Mouser gibt es da jetzt nicht so eine große Auswahl (eigentlich nur >einen, wenn man bedenkt, dass der andere SRAM nicht verfügbar ist): >https://www.mouser.de/Semiconductors/Memory/SRAM/_... Naja, serielles SRAM ist schon SEHR exotisch, erst recht in der Größe. Prinzipiell ist es damit machbar, ob es schnell und schön ist, ist eine andere Frage. >Könnte es damit klappen oder gibt es günstigeren, externen RAM, mit dem >ein 8-Bit µC noch umgehen kann? Was willst du denn da noch optimieren? Den Preis? Oder die Handhabung? Und warum soll es unbedingt ein 8-Bitter sein? Ein 32 Bitter ist für sowas deutlich besser geeignet, der kann 256kB RAM deutlich einfacher und schneller ansprechen und unter C ist es sowieso fast egal.
Max M. schrieb: > Soweit ich mich jetzt nicht verrechnet habe, käme ich immer noch auf > mindestens 75 kBit, Gibt von STM auch Cortex-M4 mit 192 kByte internem SRAM, und das komplette Board mit Spannungswandler usw. kostet unter 20 Euro (Olimex H405). Perfekt, um mal eben schnell einen Prototypen zurechtzubasteln. > und ein Farbdisplay im S/W-Modus zu verwenden, naja... Nur für die Machbarkeitsstudie. Wieviel bräuchtest Du bei 1 Byte pro Pixel?
Wozu eigentlich ein externes RAM? Der Display-Controller hat doch schon eins eingebaut. Das Auslesen geht zwar gemächlich, aber bei einem externen RAM ohne direkten Zugriff der CPU (mit externem Businterface, genügend Adressleitungen etc.) geht's wohl auch kaum so viel schneller ... Letztlich müssen die Daten ja sowieso in Display-RAM, also sind Geschwindigkeitsrekorde (bewegte Grafik) damit ohnehin nicht drin. Und der Lesezugriff aufs Display-RAM geht auch gleich auf Frame-Basis, besonders bequem, wenn man Text anzeigen will.
Stefan U. schrieb: > Entsprechende Entwickler-Boards samt Debugger bekommt man fast > geschenkt: Da kann man auch direkt das STM32F746 Discovery nehmen. Das hat 8 MByte SDRAM und ein großes Touch-Display direkt an Bord. Das ist dank paralleler Ansteuerung auch viel schneller als SPI. Nicht ganz billig, dafür aber perfekt für solche Multimedia Geschichten und Hardware mäßig ist alles schon fertig. Außerdem ist ein Debugger, Stereo Audio Codec, Ethernet Interface, USB HS OTG Interface, USB FS OTG, und microSD Slot mit SDIO (viel schneller als SPI) Anbindung vorhanden.
Vor droellfzig Jahren hatte hier mal jemand einen EDO-Riegel an einen AVR geknueppert. Das ist doch genau was du brauchst. Platz ohne Ende. Musst du mal nach suchen...
Falk B. schrieb: > Und warum soll es unbedingt ein 8-Bitter sein? Ich mag es, die Grenzen von Hardware auszuloten. Falk B. schrieb: > Ein 32 Bitter ist für > sowas deutlich besser geeignet, der kann 256kB RAM deutlich einfacher > und schneller ansprechen und unter C ist es sowieso fast egal. Welchen externen RAM würde man bei einem 32-Bit µC verwenden? Wie erfolgt das Adressieren / Ansprechen des externen RAMs? Ein SDRAM Interface oder so etwas müsste der Controller doch schon als Hardwaremodul dabei haben, oder? Falk B. schrieb: > Naja, serielles SRAM ist schon SEHR exotisch Verwenden das die µC nicht als internes RAM (z.B. der STM32F103: http://www.st.com/en/microcontrollers/stm32f103c8.html)
Max M. schrieb: > Welchen externen RAM würde man bei einem 32-Bit µC verwenden? SRAM oder SDRAM. Max M. schrieb: > Wie erfolgt das Adressieren / Ansprechen des externen RAMs? Über die entsprechenden Datenleitungen. Der Controller macht das in Hardware. Im Programm merkst du gar nicht ob eine Variable jetzt im internen oder externen RAM liegt (nur an der Geschwindigkeit). Wo sie landet, lässt sich über das Linker Script Steuern. Max M. schrieb: > Ein SDRAM Interface oder so etwas müsste der Controller doch schon als > Hardwaremodul dabei haben, oder? Jo, das SDRAM Interface der STM32 nennt sich "FMC". Das "FSMC" welches die kleineren STM32 haben kann keinen SDRAM.
Max M. schrieb: > Falk B. schrieb: >> Naja, serielles SRAM ist schon SEHR exotisch > > Verwenden das die µC nicht als internes RAM (z.B. der STM32F103: > http://www.st.com/en/microcontrollers/stm32f103c8.html) Wie soll das denn gehen? Dann würde ja jeder Zugriff 32 Takte oder so brauchen. Das wäre ja super langsam.
@Max MMM (maxmicr) >> Und warum soll es unbedingt ein 8-Bitter sein? >Ich mag es, die Grenzen von Hardware auszuloten. Naja. Beitrag "Re: Viel RAM am kleinen Controller" >Welchen externen RAM würde man bei einem 32-Bit µC verwenden? SRAM oder meistens eher SDRAM. > Wie >erfolgt das Adressieren / Ansprechen des externen RAMs? So wie es im Datenblatt steht. Das macht der Controller allein, wenn er einmal richtig konfiguriert wurde. > Ein SDRAM >Interface oder so etwas müsste der Controller doch schon als >Hardwaremodul dabei haben, oder? Sicher. >> Naja, serielles SRAM ist schon SEHR exotisch >Verwenden das die µC nicht als internes RAM (z.B. der STM32F103: >http://www.st.com/en/microcontrollers/stm32f103c8.html) Ja, das ist SRAM, aber das ist weder seriell noch extern ;-)
Max M. schrieb: > Falk B. schrieb: >> Und warum soll es unbedingt ein 8-Bitter sein? > > Ich mag es, die Grenzen von Hardware auszuloten. Andere aber womöglich nicht so. Wundere dich also nicht, wenn du von den meisten hier den Rat bekommst, der Problemstellung angemessene Technik zu nutzen. Ungeachtet dessen kannst du es ja trotzdem tun. Nur halt allein. >> Ein 32 Bitter ist für >> sowas deutlich besser geeignet, der kann 256kB RAM deutlich einfacher >> und schneller ansprechen und unter C ist es sowieso fast egal. > > Welchen externen RAM würde man bei einem 32-Bit µC verwenden? Wie > erfolgt das Adressieren / Ansprechen des externen RAMs? Ein SDRAM > Interface oder so etwas müsste der Controller doch schon als > Hardwaremodul dabei haben, oder? Im Normalfall würde man einen µC verwenden, der die benötigten ~256KByte RAM schon eingebaut hat. Sonst halt einen, der einen Memorycontroller für z.B. SDRAM mitbringt. STM baut sowas unter der Bezeichnung FMC (flexible memory controller) in einige Modelle ein. Wenn du allerdings so auf 8-Bitter fixiert bist und viel RAM brauchst - warum dann überhaupt einen µC? Nimm doch eine 8-Bit CPU und stricke da RAM und Flash dran. Ist im Zweifel sogar weniger aufwendig (und schneller) als das RAM per GPIO an einen µC zu knüppern. Vom Z80 gibt es z.B. Nachfolger wie Z180 oder HD64180, die 1MB Speicher direkt adressieren können. > Falk B. schrieb: >> Naja, serielles SRAM ist schon SEHR exotisch > > Verwenden das die µC nicht als internes RAM Nein. Warum sollte man auf einem Chip einen Flaschenhals in Form eines seriellen Interface zum RAM vorsehen? Leitungen sparen muß man eigentlich nur bei extern angebundenem Speicher. Und auch dann würde man das bevorzugt für Speicher verwenden, bei dem die Latenzzeit unkritisch ist. Etwa weil da ein Cache dazwischen ist.
:
Bearbeitet durch User
Max M. schrieb: > Könnte es damit klappen oder gibt es günstigeren, externen RAM, mit dem > ein 8-Bit µC noch umgehen kann? Du machst es Dir unnötig schwer. Die ILI9341-Displays haben alle ihren Grafikspeicher dabei. Den kannst Du schreiben und lesen. Damit das möglichst schnell geht, nimmst Du einen Prozesor mit External Memory Interface, d.h. einen der externe Adress- und Datenleitungen hat und wo Du SRAM anschließen kannst. Der ILI9341 kann auch über einen externen Adress/Datenbus angesteuert werden, nur bei dem, das Du Dir ausgesucht hast, sind die Leitungen nicht herausgeführt. Es gibt aber auch andere, z.B. ebay #172388598203. Wenn Du unbedingt einen AVR verwenden musst, dann wäre ein Mega64*/128*/256* der Prozessor Deiner wahl, weil die eben genau einen solchen Adress/Datenbus haben, d.h. Du kannst mit einem Speicherzugriff auf den Controller zugreifen. fchk
> Im Normalfall würde man einen µC verwenden, der die benötigten ~256KByte > RAM schon eingebaut hat. Ich kann nur dringend zu internem Ram raten. Gerade als Bastler. Einfach weil die Ansteuerung VIEL einfacher ist und man weniger EMV Probleme hat. Die Platine wird halt viel einfacher. Schaut mal hier was moeglich ist wenn man einmal ueber seinen Horizont schaut: https://www.renesas.com/en-us/docs/products/microcontrollers-microprocessors/rz/RZ-brochure.pdf Olaf
@Olaf (Gast) >Ich kann nur dringend zu internem Ram raten. Gerade als Bastler. Einfach >weil die Ansteuerung VIEL einfacher ist und man weniger EMV Probleme >hat. Die Platine wird halt viel einfacher. Das interessiert den OP keine Sekunde, wenn er sinnvollerweise ein fertiges Eval-Board kauft.
>> Und warum soll es unbedingt ein 8-Bitter sein? >Ich mag es, die Grenzen von Hardware auszuloten. ich habe vor ein paar Jahren auch mal mit den AVR 8-bittern herumgemacht und habe gedacht, Grafik und 8-bit muss doch gehen. Nach ein paar Experimenten bin ich auf den Trichter gekommen, Grafik braucht viel Speicher, damit man nicht ständig um irgendwelche Flaschenhälse herumprogrammieren muss. Konsequenz war der Xmega statt Atmega: http://www.dasrotemopped.de/index.php?var=projekte&nr=12 Hat sich schnell herausgestellt, das das auch keine Lösung war, da zu langsam, immer noch Flaschenhals um bequem was mit Grafik zu machen. Die Lösung ist das STM32F429i-disco, wenn man kein Board selbst bauen will. http://www.dasrotemopped.de/index.php?var=projekte&nr=21 ILI9341, 8MB SDRAM, mehr als genug CPU Leistung und der Grafikspeicher liegt bequem im Adressbereich der CPU, für die Software transparent und leicht zu benutzen. Mit dem BSP von STmicro kann man sofort loslegen, da die Hardware bereits initialisiert wird: http://www.dasrotemopped.de/dateien/STM32F429i-DISCO_BSP_20170417.zip Man kann sich also direkt seinem eigentlichen Ziel widmen statt Unzulänglichkeiten der gewählten Hardware zu umschiffen. Und preiswert ist das Disco Board auch noch. Wer will kann natürlich auch einen Arduino, SPI SRAM und ein externes Display verwenden, aber jeder wie er mag ... was dem einen der Spatz ist, ist dem anderen seine Nachtigall.
vergessen: ATmega für die Grafik: http://www.dasrotemopped.de/index.php?var=projekte&nr=9 Ohne ausreichend RAM eine Sackgasse für Grafik.
Bildverarbeitung ... was soll denn wie verarbeitet werden ? Ein Bisschen Zoom, ein Bisschen Pan, ein bisschen Filtern ? Hat sich der Poster schon mal Gedanken ueber die Geschwindigkeit gemacht ? Wie viele Operation da benoetigt werden ? Wieviele Memory zugriffe ? Ich empfehle eine Simulation auf einem PC. Da kann man jeden Zugriff zaehlen. Und dann vergleichen mit der Verarbeitungsgeschwindigkeit. Ist irgendetwas in Richtung Interaktivitaet geplant? Weshalb haben Smartphones Quadcore 32, resp Quadcore 64 bit Maschinen mit GHz Geschwindigkeit, und speziellem Grafikcoprozessor ... damit alles etwas flott reagiert. Bedeutet auch mit einer 100MHz 32bit Maschine, mit direkt angebundenem zerowaitstate RAM ist alles noch schnarchlangsam.
>Ich mag es, die Grenzen von Hardware auszuloten.
Dann aber bitte auch konsequent sein und das Ganze in Brainfuck oder
Whitespace programmieren.
Wer so etwas mit einem AVR machen möchte hat eventuell den alten C64 im Sinn, der konnte mit 1MHz ganze Spiele ausführen. Dabei vergisst man aber womöglich, dass der C64 einen eigenen Grafikprozessor hatte, der die bewegten Objekte vollkommen selbstständig dargestellt hat. Außerdem war die Programmierung von Grafik damals trotz dieses Prozessors eine ganz besonders aufwändige Herausforderung, mit der sich nur wenige Hobby-Programmierer befasst haben. Wer meint, die Grafik vom C64 war toll, möge sich bitte nochmal Bildschirmfotos ansehen. Die Wahrscheinlichkeit ist hoch, dass man sie sehr viel schöner und detaillierter im Gedächtnis hat, als sie tatsächlich waren. Damals waren die Bilder mehr ein Hilfsmittel um die Phantasie anzuregen, welche Bilder im Kopf erzeugt. Es sind die Bilder im Kopf, an die wir uns heute noch erinnern.
Die Frage ist was du willst. Es ist durchaus möglich bessere Grafikausgaben mit avrs zu machen - klar muss natürlich sein, dass mehr Arbeit in die Software gesteckt werden muss, als wenn man einfach einen Speicherbereich per dma an ein Display schickt. Bei der uzebox kann man gut sehen, was möglich ist. Unter Bildbearbeitung bezeichnet man übrigens in der Regel etwas anderes als du wahrscheinlich meinst.
Max M. schrieb: > Und bei den restlichen Vorschlägen scheint ein externer RAM auch > unumgänglich. Nein. Es gibt µC mit genug RAM. Der hier hat 32MByte: https://www.digikey.at/de/product-highlight/m/microchip-technology/pic32mz-da-series-mcus?utm_adgroup=General&mkwid=shpOrGYPK&pcrid=251907372415&pkw=&pmt=b&pdv=c&gclid=EAIaIQobChMI1eymlY-g2gIVAxwbCh2ETQ5zEAAYASAAEgLr3vD_BwE Die sind genau für derartige Dinge gebaut.
>Bedeutet auch mit einer 100MHz 32bit Maschine, mit direkt >angebundenem zerowaitstate RAM ist alles noch schnarchlangsam. so ein Cortex M4/7 kann schon was: https://youtu.be/a1U5W8K1GMM und auch der Hobbyprogrammierer kann mit einem STM32F429@180MHz flüssig animierte Grafik in 2D: https://youtu.be/miGGfDeDFWU hier wird der Unterschied von AVR zu ARM deutlich sichtbar: https://youtu.be/_SmLlGAyRRc 3D Grafik ist da nicht mehr empfehlenswert, aber möglich. Ein ARM Axx mit integierter GPU ist da natürlich klar besser, aber verlässt den Bastel-/Hobbybereich. Cortex-M zu ARM Axx verhält sich warscheinlich wie AVR zu ARM Cortex von der Geschwindigkeit her, aber vom Budget zu Leistung dürfte das STM32F429i-disc1 ungeschlagen sein.
Ich würde hier auch auf einen grösseren Controller wechseln (z.B. STM24F429 Discovery für ~20Euro hat schon externes RAM und Touch-Display). Da ersparst du dir viel Ärger: - FMC zum ansteuern des externen RAM - Display Controller (verschiedene RGB Formate...) - DMAs Dann kannst du dir auch im Speicher 2 LCD-Bilder ablegen: eines wird immer schön angezeigt und das andere bereitest du dir für die Anzeige vor. So hast du ein besseres Bild-Ergebnis (wird auch bei PC so gemacht, dass immer über 2 Buffer gearbeitet wird). Sobald dein neues Bild fertig ist, wechselst du den Speicher... Solche Displays haben oft keinen eigenen Speicher und die Pixel müssen auch zyklisch aktualisiert werden. Wenn dein 8-Bitter nun RAM Lesen, Bild berechnen und gleichzeitig das Display ansteuern wird, wird's vermutlich eng.
Stefan U. schrieb: > Wer meint, die Grafik vom C64 war toll, möge sich bitte nochmal > Bildschirmfotos ansehen. Die Wahrscheinlichkeit ist hoch, dass man sie > sehr viel schöner und detaillierter im Gedächtnis hat, als sie > tatsächlich waren. Damals waren die Bilder mehr ein Hilfsmittel um die > Phantasie anzuregen, welche Bilder im Kopf erzeugt. Es sind die Bilder > im Kopf, an die wir uns heute noch erinnern. Wobei das auch mit dem Ausgabemedium zutun hat. Solch niedrige Auflösungen sehen auf einem CRT grundsätzlich besser aus, als auf einem TFT. Liegt wahrscheinlich daran dass die alten CRTs zwangsläufig eine Art anti-aliasing hatten - schlicht nicht so scharf wie Flachbildschirme.
:
Bearbeitet durch User
Stefan U. schrieb: > Dabei vergisst man aber womöglich, dass der C64 einen eigenen > Grafikprozessor hatte, der die bewegten Objekte vollkommen selbstständig > dargestellt hat. Außerdem war die Programmierung von Grafik damals trotz > dieses Prozessors eine ganz besonders aufwändige Herausforderung, mit > der sich nur wenige Hobby-Programmierer befasst haben. Die Grafik der 8-Bit-Rechner früher war durch ihr Konzept soetwas wie komprimiert. 2 Bit pro Pixel zeigten auf eine Referenz-Farb-Palette und ein Tile konnte wiederholt werden bzw. musste sogar weil die Tile-Karte nur 256 verschiedene Einträge zuliess. Genaueres siehe: http://www.dustmop.io/blog/2015/04/28/nes-graphics-part-1/ Die Mühe wurde belohnt indem die lahme CPU pro Bild nur noch wenige Bytes an Daten verschieben musste und schon lief das Spiel. Nur die Erstellung der Grafik war furchtbar und erforderte Grips. Den hatten (und haben) die Japaner aber zuhauf.
Max M. schrieb: > Ich mag es, die Grenzen von Hardware auszuloten. Die meisten 8-Bitter können nur bis 64kB linear adressieren. Ich kann Dir versichern, es macht keinen Spaß, den RAM in kleine Häppchen aufteilen zu müssen und viel Zeit und Code mit Pageumschaltung zu vergeuden. Insbesondere Berechnungen an den Pagegrenzen werden dann zur Qual und fehlerträchtig. Zu DOS-Zeiten war das nötig, als die Grafikspeicher nicht mehr in den dafür vorgesehenen Bereich paßten. Jeder Grafikhersteller kochte da sein eigenes Süppchen der Pageumschaltung. Daher waren viele Spiele im Grafikmodus oft nur im 320*240 Format.
:
Bearbeitet durch User
>Die Grafik der 8-Bit-Rechner früher war durch ihr Konzept soetwas >wie komprimiert. 2 Bit pro Pixel zeigten auf eine Referenz-Farb-Palette das heisst beim STM32F429 CLUT "colour lookup table". 8-bit Index Werte zeigen auf eine Tabelle mit 256 RGB 32 bit Farbwerte. Spart RAM und Speicherbandbreite bei der Nutzung von SDRAM bei hohen Auflösungen.
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.