[elektro] PIC32 LCD grfikus driver

[I F]

Hi!

Az új Microchip LIB csomagban jelentősen javult a configurálási lehetőség,
áttekinthetőség.
A régi az valóban katasztrófális volt.

"Óriási kunszt volna ha úgy írják meg, hogy a driver lib "meghív" pl. egy
SSD1289_WRITE makrót"

Egyébként szerintem a grafikus driver ilyen, csak nehány függvény hívást
kell megcsinálni az adott HW-re.
(init, pixel terulet definiálás-kiirás- olvasás, szín beállitás, stb.)
Az, hogy ezt HW bitre lebontva legyen makrozva az szerintem esélytelen.
A minimál CustomDriver.c-ben csak a PutPixel funkció-t kell megcsinálni.
Ettől persze biztos vérszegény lesz a dolog, ezért amit tud a HW az célszerű
kihasználni és betenni a driverbe.
Pl. egy hasonló meglévő driver progi mintájára.

Csak nincs idő, így fél szűzen szerintem kb. 1 hetes feladat lenne.
Ezért gondoltuk, hogy kiadjuk, ne kelljen mégegyszer kitalálni dolgokat.

Néztem az 512K-s PIC32-t kb 1/3-ig tölti meg a IP és GUI.

Egyébként milyen más, hasonló kaliberű nem PIC architektúra jöhetne még
szóba?

Ami kellene HW és SW funkcióban:

USB, USB boot.
Ethernet IP stack , IP boot
GUI, GUI fejlesztő támogatás
min. 80 Mips
Szokásos perifériák  I/O, CLOCK, SPI, I2C A/D, D/A, stb  + SW támogatás.

Az ARM7 klónok tudják ezeket, de milyen fejlesztő rendszer + SW lib.
támogatás + gyors betanulás?

Szétszedtem több MP4 kütyüt, szinte mindben RockChip volt benne.
A NET szerint is a legtöbb hasonló eszközben a RockChip készleteket
használják.
Brutális a tudásuk, de úgy látom halandó nem tud hozzájuk férni.
 http://www.rock-chips.com/index.php?lang=en



2011/9/2 Moczik Gabor <pm_levlista at progzmaster.hu>

> Pipi írta:
> > múltkorában kicsit nézegettem a microchip libraryt, nem egy leányálom
> > kigubancolni melyik portláb hová megy az (valamelyik)lcd-re se a
> kapcsirajzon, se a szoftverben.
> > ssd1289-et akartam hozzá, és "nyomokban" van benne "támogatás", egyenlőre
> parkol nálam
> > lehet egyszerűbb megírni (optimálisabban) újra, vagy keresni az adott
> lcdkontrollerhez mintaprogit a neten és azt applikálni,
> > netán eleve olyan lcd-t beszerezni amit a microhip sw ismer
> > ha nincs normális doksija az lcd-nek akkor is lehet vele szivornyázni,
> mire a kontrollert jól bekonfigolja az ember,
> >   hogy valamit már akarjon megjeleniteni
> > Az a baj hogy tele van #define mag #if-fel a progi hogy többféle
> procival, demopanellal, lcdvel is menjen,
> > ( bár ez a többi (pl ethernet) mintaprogikra is igaz) emiatt valszeg nem
> is igazán sebességoptimális a kódszerkezet
> >
> > Szerintem nem kis munka, úgy látom nem is kapkodnak érte az emberek...
>
> Ez csak attól függ, mekkora erőfeszítés az adott kontrollerrel egy
> pixelt kirajzolni.
>
> Azzal viszont rohadtul egyetértek, hogy a microchip demo szoftverekken
> módosítani, vagy azzal dolgozni igencsak idegtépő. Össze-vissza van
> gányolva minden, hogy a demo panelekkel jól menjen, de egy tetszőleges
> hardvert illeszteni hozzá nem jó buli.
>
> Ha gyárilag van driver, azt is egyszerűbb kigyomlálni és átírni.
>
> Óriási kunszt volna ha úgy írják meg, hogy a driver lib "meghív" pl. egy
> SSD1289_WRITE makrót, aztán hogy ez hogy kerül ki, melyik
> portlábon/multiplexeren vagy CPLD-n az eszközre az legyen az user dolga...
>
> Ugyanez a különféle bitekkel. Definiálhatod a TRIS meg a LAT regisztert,
> de mi van ha nem direkt I/O lábra megy, mi van ha negálva van, stb...
> Inkább hívna a driver mondjuk LCD_CS_SET meg LCD_CS_CLEAR makrót, aztán
> majd te beállítod valamilyen módon a CS bitet a makróban.
>
> Mellesleg a TCP/IP meg a GUI stack nagyjából megtölti a PIC32 flash-t.
>
> -----------------------------------------
>          elektro[-flame|-etc]
>