Enkelt grafikbibliotek för embedded?

[lillahuset]

Någon som har tips på något enkelt grafikbibliotek för användning på QVGA-display?

Vi är ute efter något öppet/gratis/tillverkaroberoende och kommer att använda en ARM Cortex av någon typ. Förmodligen STM32F429.

Jag har ett eget halvfärdigt bibliotek som jag gärna delar med mig av om någon är intresserad av att komplettera det.

[TomasL]

Vad vill du det skall kunna göra?

[lillahuset]

Det ska ersätta en gammal burk med 128x64 display. På den displayen visas lite text med olika fonter, lite rutor, en scrollist (av någon anledning), en ledsen och en glad smiley (!) och slutligen kan man "öppna dialogfönster" med skuggning och allt. Inte så märkvärdigt men när det dyker upp 320x240 pixlar eller mer kommer förmodligen fantasin igång.

Mitt halvfärdiga bibliotek ritar listor av pixlar, linjer, listor av linjer, polygoner, rektanglar, fyllda rektanglar, cirklar, fyllda cirklar och bitmappar. Så egentligen finns vad vi behöver. Men det vore trevligare med något färdigt alternativt mitt halvfärdiga med någon eller några fler intressenter. Ett "grafikbibliotek" tycker jag inte man ska vara ensam om.

[Klas-Kenny]

Nog finns ett intresse för det, har själv letat en del vid några tillfällen och slagits av hur svårt det verkar vara att hitta. Allt jag kunnat hitta har varit högst specifikt för någon hårdvara, eller så pass avancerat att jag inte orkat med att reda ut hur man portar det till viss hårdvara och får det att fungera.

Har också skrivit lite egna funktioner för bland annat rektanglar, text (med en viss font och storlek), svart-vita bitmappar, vektorer mm. Men vore väldigt användbart med något "lagom" stort med ett gäng användbara funktioner utan att kräva någon veckas arbete bara för att få att fungera på viss hårdvara.

[lillahuset]

"Alla" processortillverkare med självkänsla har ju egna bibliotek som troligen funkar utmärkt. Bekymret är att om man tröttnar på en tillverkare så "kan man inte" ta med sig biblioteket till en konkurrerande tillverkares processorer. Helt OK men jävligt irriterande.

Kan det här möjligen vara starten för ett öppet bibliotek? Hoppas det.

[bearing]

Snabb googling gav detta:
http://andybrown.me.uk/2012/06/04/nokia ... rt-2-of-2/
Vet inte kvaliteten på koden.

När jag senast gjorde ett bibliotek var det för en OLED 128x64. Då använde jag en buffer i RAM, samt processorns DMA för att överföra från RAM till OLED via SPI. All grafikbehandling gjordes mot RAM-bufferten, vilket gjorde att det inte var några konstigheter där, och det skulle nog gått att ta valfri kod från en PC om jag hade behövt mer avancerad grafik. Hade bara vertikala/horisontella linjer, samt text i mitt bibliotek.

Eftersom att jag använde DMA tog överföringen till LCD i princip ingen processorkraft. Behövde bara ett kort interrupt som startade om DMA-överföringen genom att sätta någon bit i några register.

Om detta går med QVGA beror väl på hur mycket RAM processorn har.

[lillahuset]

Intressant att ditt inlägg inte dök upp i mina "nya inlägg".
Jag har inte kollat vad Andy har gjort. Än. Men snart.
Att du har isolerat själva "ritkoden" från koden som skriver på själva hårdvaran är bra, det innebär ju att det blir lättare att porta till ny hårdvara.

Har vi ett gemensamt intresse?

[LHelge]

Har precis börjat labba med det danska TouchGFX på jobbet. Inte gratis, inte öppet men uj så snyggt och lättjobbat!

Utvecklat för Cortex-M funkar utmärkt på STM32F4, går supersnabbt att bygga upp snygga gränssnitt med "smartphone-känsla". Det hanterar det mesta med DMA så det är ganska resurssnålt också.

[bearing]

Har vi ett gemensamt intresse?

Jag har inte något eget behov. Mitt inlägg var mest ett tips, att använda DMA. Min kod skrev jag på ett jobb, så den har jag inte här.

[lillahuset]

Självklart använder man DMA.

[bearing]

Men kräver 80kB rambuffert. Alla mikrocontrollers har ju inte den storleken på RAM.

[LHelge]

STM32F429 som TS nämnde kan köra med externt SDRAM på FMC och skyffla data med DMA till TFT controllern.

[lillahuset]

bearing: Det beror ju på hur pånga bittar man har per pixel.

När jag höll på med det här projektet för fem år sedan använde jag en STM32F103 med 20kB RAM och 72MHz klocka. Jag hade en palett med fyra färger och alltså två bittar per pixel. Det blir 19200 byte. Sedan hade jag en buffer som är 848 byte, organiserad 424x16 för en linje på displayen och slutligen en palett 4x16. Kvar till stack och övriga variabler blir 424 byte.

All timing sköts av processorn och displaydrivningen har jag för mig tog ungefär en fjärdedel av processorn. Det här gjorde jag som ett "proof of koncept" bara för att visa att det går. När lågnivådetaljerna var klara så var det inte så kul längre.

LHelge: Jo med STM32F429 blir ju allt mycket enklare.

[Micke_s]

Detta finns ju också. Enkelt att byta processor. Svårare att byta LCD..
https://www.itead.cc/display/nextion/ne ... 8t070.html

[lillahuset]

Jo, men en kraftfull "overkill" för det vi ska använda det till. Befintligt instrument har en 128x64 grön display som är omöjlig att få tag på och en Rabbit-modul som intelligens. Av någon anledning (förmodligen konstruktionsfel) fungerar bara 2/3 av modulerna i instrumentet. Ingen på firman gillar det men kunderna köper det gärna så det är dags att göra något som är lite modernare.