Igen, pont ezt gondoltam. Tehat nalad a hatter ez a turkiz szin. Altalaban fekete hatterre szoktunk rajzolni. De ha mondjuk piros hatterre akarnal feketevel, akkor mindenkeppen le kell torolni a kepernyot (az osszes wordot atirni pirosra).

(De ures byte nincs, maximum a 0x00-t hivhatod annak, de az pont ugyanolyan fix ertek, mint mondjuk a 0x6543.

Jó igazad van az "üres bájtot" illetően Viszont most rá kell jönnöm, hogy a színeket hogyan kell keverni, illetve van e hozzá valami hex táblázat neten. És hogy hogyan tudnék betű vagy szám karaktereket rajzolni anélkül, hogy felemészteném az egész memóriát.
Egyébként ez a türkiz vagy koszos fehér szín init után autómatán beáll.

Mondjuk pofonegyszeru, mivel van 5 kek, 6 zold es 5 piros bited a wordon belul.
a tiszta piros a 0b0000000000011111 vagy 0x1f
a tiszta zold a 0b0000011111100000
a tiszta kek meg a 0b1111100000000000

es ennyi.

Jut eszembe, mar felforrasztottam az en kijelzomet a probanyakra, de egyelore nem akarja a jot, nem is fogadja az inicializalast.

Betukben tudok segiteni, legalabbis 18F-re keszen van a teljes megoldas.

Az init viszonylag egyszerű, bár a pozitív és negatív gamma beállítás az brutális, nem is értem a logikát benne. Tegnap próbáltam karaktert létrehozni egyenlőre kevés sikerrel. Ha nem titok mutathatsz egy karakter megadási mintát.. Bár szerintem nincs sok választás, mert a "téglalapon belül" sorban kell kirajzolni pixelenként gondolom.

Ugy ertem, hogy nem fogadja az initet,hogy egyelore nem csinal semmit, nem sotetedik el, amikor bekapcsolom a kepernyot.
Mondjuk en tablazatbol csinalom, hogy ne legyen ezer soron at az, hogy mov ertek,mov regiszter, mov ertek, mov regiszter.... majd tesztelem.

Szoval a karakterkeszlet trukkos, en kettot is belezsufoltam a 6000-8000 tartomanyba, az egyik a nagymeretu, a masik a kismeretu es ezek teljes karakterek.
A trukk az volt, hogy tomoritest alkalmaztam, az x kezdo es vegpont, valamint a teteje es az alja is meg van adva. Mindez azt hiszem talan 64*64 ponton belul.
Csinaltam hozza sajat karakter-atalakitot, a Windows kirajzolja nekem en meg onnan hasznalom atalakitva, igy skalazni is lehet.

Mindjart elkuldom a mailcimedre is.

Hű, nemsemmi munka lehetett vele. Egyébként én is táblázatból fogom majd kiküldeni az initet, csak most még tesztelgetek nem optmalizálok. Én is kitaláltam egy módszert a karakterek létrehozásához, a betű színe és a háttér tetszőlegesen változtatható viszont a méret kötött... 1 karakter 26 word, tehát nem vészes

Nem volt akkora munka, ha mar az elve keszen van, akkor egyszeru. Ugyanazt kell csinalni mindegyik karakterrel.
Egyebkent az adatok feltoltese is programmal ment, szoval progicska megnezte, hogy kezdodik , vegzodik, fent, lent, aztan txt fileba beirta adatostol. En meg inc file-a alakitottam.

A kis cuccom mar inicializal (korabban rossz sorrendben adtam meg neki a vezerlojeleket pinjeit, hibas reverse engeneering volt reszemrol, azert ketoldalas nyak, meghajtoIC utan), meg is jelenit ,de az orientacio teljesen rossz es mintha szinek nem is lennenek...

Nalad a karakterek proporcionalisak (W szeles I rovid) vagy mindegyik ugyanannyi helyet foglal el x iranyban?

Épp tesztelem illetve fejlesztem a karakter írást, az elv megvan, viszont nem azt rajzolja amit kellene... Épp azt nézem, hogy egy széles és egy keskeny oszlop van X tengelyben (nekem fektetve van a kijelző) a pixelek írása fentről lefelé halad és balról jobbra. 28x16-os pixel méretű karaktereket szeretnék használni.

Na, nalam is elindult vegre, minden rendben, en is fektetett kijelzot hasznalok.
A problema az volt, hogy meg szokatlan a 16 bit es a W0 regiszternek az aljaba olvastam TBLRD.b-vel, de az egesz regisztert hasonlitottam a 0-hoz (beolvasas veget jelzo byte), igy hiaba volt a tabla vegen 0, ha a w0 felso byte-ja valami random ertek maradt...

Azt javaslom, a te esetedben definialj egy x kezdocimet, annal 28-al nagyobb x vegcimet, valamint egy kezdo y erteket es annal 16-tal nagyobb y veget. (ugye a 2A,2B regiszterben a HI/LO a sorrend mindket beiraskor) es a szin is ket byte, szinten felso/also sorrendben.

Utana meg irj ki egy jol kiszamolt erteket, akar bitkepbol tarolva, akar egyelore byte-osan.
Szerintem egyebkent a hiba nalad a bitkepbol valo kiforgataskor jelentkezik - nem mindegy, melyiket hasznalod a rotalasok kozul (szimulator segithet, hogy melyikre gondolsz) es a carry is ennek megfeleloen legyen beallitva.

Nem használok forgatást. Az elvem kicsit nyakatekert lehet. Táblázatban, a pixelek számát tárolom. pl. 0x1234 ahol 12db fehér pixel mint háttér, és 34 fekete pixel mint karakter van megadva, és mivel kígyószerüen halad a pixel írás a téglalapban, így a rutinban felváltva küldöm ki a háttér és a karakter pixeleit. A címzést egyenlőre pihentetem, az megy egyébként, nincs gond. A probléma egyenlőre, hogy elcsúsznak a pixelek, de holnap megoldom.

Sziasztok,

Itt az én álltalam használt karakter kiírás.
Ezt nagyon könnyű áttenni akármilyen TFT vezérlőre.
Ha érdekel benneteket kocka,kör, azt is megosztom szívesen.
SSD1963,ILI9320,ILI9341,ILI9348 stb vezérlőben otthon vagyok.

Jo megoldas, de ahogy latod, mi assemblyben nyomjuk.
Mindamellett ha van jo vonalrajzolo vagy akar kocka/kor algoritmus, akkor johet. Sajnos assemblyben nem eleg az x=r*cos(a) sort beirni....

Szia! Én SSD1963-as meghajtóval szerelt 800x480 felbontású TFT-ket használok (5, 7, 9 colosakat), és PIC32MX-ekkel hajtom meg 16bites PMP porton, automata vezérlő lábak kezeléssel. Egyszerű geometriai elemeket, mint színátmenetes lekerekített gombok, ablakok (kerettel, árnyékolással), textboxok és több méretű karakterek, amit lehet fix szélességgel, dinamikus szélességgel, háttérrel és transzparens módon megjeleníteni. Sokat dolgoztam vele, de sikerült olyan rutinokat írni(C-ben) ami teljesen jó sebességgel működik. Persze nem olyan, mint egy táblagép, de megfelelő. Egy teljes ablakot telenyomva, 1-2 tized alatt feldob. Magam is meglepődtem, azok után, hogy milyen videókat láttam PIC32-essel meghajtott hasonló méretű TFT-kről. Most azt tervezem, hogy 32MZ-ket fogok be a feladatra, de van egy érzésem, hogy az SSD1963 lesz a szűk keresztmetszet, mert az MX-en is lassítani kellett a vezérléseken. Teljes kódokat nem szeretnék megosztani, de elvi dolgokról és megoldásokról szívesen beszélgetek.

A Pic32mz mivel jobb, mint az mx?

200MHz.

Köszönöm, minden világos!
Csak szeptemberben kezdtem a PIC-ezést, rögtön nagyban egy PIC32MX795F512L-en és még nem igazodok el köztük annyira.

Ezzel hasonló tudású PIC van az MZ szériában?
A panelemet PIC32MX795F512L-el tervezem, de még tudok módosítani, és MZ-re szeretnék is. Ethernetet is szeretnék mellé, ezt a részét is kipróbálnám, szerintem fejlettebb lehet, mint az ENC28J60.
A kijelzőkkel kapcsolatban nekem is ez az elvárásom, hogy a lehető leggyorsabb legyen, ne látszódjon a képernyőfrissítés. A cél az, hogy olyan legyen, mint a telefonomon például.

Most egy ilyen kijelzőre szántam rá magam, még nem rendeltem tőlük, de remélem, hogy minden rendben lesz.
Kapacitív touch-al rendeltem, erre is kíváncsi vagyok és a vezérlő IC-jére is, mert ugye a TP4056-ot nem dícséri senki agyon.
A fura csak annyi számomra, hogy I2C-n kommunikál, az van a panelra kivezetve és azt annyira nem szeretem, de biztos jó lesz.

Közben válaszolok is a saját kérdésemre: a PIC32MX795F512-höz hasonló tudású PIC nincs, csak sokkal jobb.
A PIC32MZ2048ECH064-I/PT-t válaszottam, ez tűnik nekem a legjobbnak, 144 lábú pedig felesleges, a 64 láb is elég számomra.

Azt még nézd meg, hogy a 64 lábún is van-e PMP, mert a nélkül nehézkes kivinni megfelelő frekivel a képet. Arra ne számíts, hogy olyan lesz, mint a teló. Egy telóban 10-20-szor gyorsabb magok vannak nem is egy, valamint integrált képernyőmeghajtó. Olyasmit nem lehet vele csinálni, hogy vontatsz képet, vagy képernyót, mert nincs elég memória. Igaz az MZ-ben talán már lenne elég, most hirtelen nem is emlékszem, de az MX kicsi ehhez. Külső RAM kezelése már lassú lenne, bár DMA-val talán nem...

Egyébként az MX is nagyon erős, olyan érzésed van, mint ha PC-re fejlesztenél. Megírod és fut, legyen az lebegőpontos, vagy bármi. Kész élvezet 18F-ek után (amivel nem akarom ledegradálni őket, mert mindent a maga helyén kell kezelni, sokat használom őket most is megfelelő feladatra...)!
MZ-vel még nem dolgoztam, csak van egy a fiókban, úgy hogy ez nekem is ismeretlen terület.

Ami zavaró, hogy az MZ nem lábkompatibilis az MX-el. Biztosan megvolt a nyomós okuk erre, amit én nem érthetek meg!

Szerk: Közben megnéztem, van PMP...

Köszönöm az utánanézést! Én meg azt fogom megnézni, hogy mi az a PMP.
Persze a telefon csak egy cél, szeretek ilyenekben (is) magas célt kitűzni.

Amikor MX-re fejlesztettem nekem is furcsa volt az ATmegák után, hogy ilyen frankó! Meg persze az új dolgokkal is jó ismerkedni, amiket az ATmegákban nem próbálhattam ki vagy nincsenek is.

Van egy érzésem, hogy az SS meghajtó IC-nek lesznek korlátai, nem az MZ-nek.

A PMP párhuzamos port 16 biten, hozzá való vezérlő vonalak hardveres kezelésével.

Az MZ miben más kérdésre még lenne itt pár válasz: USB HS, SQI 50MHz, Ethernet stb.

USB HS 2.0 szabványú gyors USB.

SQI "négyvezetékes" SPI (inkább egy 4 bites párhuzamos port ), amivel elvileg SD kártyákat lehet igen gyorsan SD protokol szerinti bekötési módban kezelni. Nem kell mondani, mennyivel gyorsabban lehet kiolvasni egy képet, mint egy sima SPI-vel. Ha jól rémlik talán támogatja is ezt a módot. Az már csak hab a tortán, hogy DMA-val át lehet tolni a beolvasott bájtokat a PMP portra direktben. Azaz előkészíted a parancsot a TFT-n, majd kiadod, hogy honnan, hová ömlessze a pixeleket leíró 16bites szavakat. Ha jól láttam be lehet állítani 16bites módba és ha megtelik a puffer, el is nyomja a DMA és veszi a következőt. (DMA közvetlen memória olvasás írás. Elő kell készíteni a forrás és cél címeket, pár dolgot beállítani és elindítani a másolást. Ezt követően nem kér erőforrást a művelet a lejártáig.)

Kész kánaán, de azért a hibák kikerülésére oda kell figyelni, mert sajnos vannak bőven, ahogy az erratákat olvasom!
Mindenesetre egy ilyen egységgel már meg lehet oldani elég látványos dolgokat egy TFT-n nagy felbontásban is.

A DMA-nal annyiban korrigálok, hogy csak memória-memória, illetve memória-periféria transfer lehetséges, azaz az SQI-PMP átvitelt csak két lépésben lehet megoldani, igaz, menet közben két DMA-t is el lehet indítani párhuzamosan, csak akkor van gond, ha az egyik gyorsabb mint a másik és a másik az ami kiviszi a TFT-re a tartalmat. Szóval ezt át kell még gondolni!

Nagyon jól hangzik amiket írsz!
Az SQI-ról sem hallottam még, arról viszont igen, hogy 4 bites módban is lehet az SD-t kezelni.
RA8875 chip van az LCD-n, erről csak egy helyen találtam véleményt, ott azt írták, hogy jobb, mint az SSD IC-k, de egy vélemény azért még nem teljesen mérvadó.

Az errata-kkal is PIC-nél találkoztam először, atmegáknál egyetlen "hibával" találkoztam csak, de az is logikus és egyszerűen kiküszöbölhető a PWM modulban.

Nem voltam elég figyelmes, amikor azt írtam, hogy nekem is van ilyen, mert nekem SSD meghajtó van rajta és Ilyen....
Az RA8875-öt még nem ismerem, megnézem milyen sebességet írnak, tényleg gyorsabb-e mint az SSD. Persze más dologban is lehet jobb, vagy bővebb szolgáltatásokat felsorakoztatni egy meghajtónál, mint a sebesség, de talán az a legfontosabb.

A PIC nem dicsekedhet ilyen téren sajnos!

Igazából én is SSD-set akartam venni, mert az a népszerű és a megrendelés után vettem észre, hogy RA-sat rendeltem az e-mailben. Akkor kezdtem el keresgélni róla.
Kíváncsi vagyok, hogy mit találsz róla. Lehet hogy tényleg többet tud, mert kicsit drágább mint az SSD meghajtós.

A helyzet az, hogy úgy látom az SSD majdnem kétszer gyorsabb, de az is igaz, hogy ezt nem tudtam kihasználni az MX-el. A sebességeket a Strobe Pulse width idejével arányítom, ami 12 vs. 20 ns. A teljes ciklus így 26 vs 50ns körül alakul az SSD javára. Az SSD max órajele 110MHz, az RA 60MHz- ha jól láttam. Viszont talán több mindent tud hardveresen kezelni, de ennyire nem mentem bele, csak láttam, hogy sok a fényképes magyarázat a műveleteknél.

Ez elég szomorú, érdekes, hogy ami általánosan (szerintem) a legfontosabb szempont, nem az fejlődik. Azt én is néztem, hogy a háttérvilágítást ez a kijelző alapból a chip-el vezérli, nem tudom az SSD is úgy csinálja-e. Elvileg tud hardveresen görgetni szövegeket, ezt egy youtube videóban láttam, viszont valószínű a kezelő mikrokontroller csinálta és nem a kijelző vezérlő IC.

Felmerült a kérdés bennem, hogy a PIC32MZ-n a PMP nem lenne túl gyors az RA vezérlőnek vagy még az SSD-nek is?
A gyakorlatban próbáltad már?

És csak a 6800-ás interfésszel megy, vagy a 8080-assal is? (A kettő között egyenlőre még nem látom egyértelműen különbséget. Mondtad, hogy 8080-at használsz, így olyat vettem. Az adatlapban azt láttam, hogy az egyik párhuzamos a másik pedig soros, ugye?)

Tőled függ milyen ütemben adod ki a szavakat. A vezérlő lábak időzítése is beállítható. Ez ugyanúgy működik a 80MHz-es MX-nél is.

A két interfész között csak a vezérlő lábak logikai értélmezésében van eltérés. Nézd meg az adatlapban milyen neveket adnak a lábaknak és a folyamatábrákon, hogy milyen időzítésekkel operálnak, illetve melyik mit csinál a két protokol szerint. Mindkét interfész párhuzamos és ugyanaz a fizikai hardver. A vezérlőben beállítható az inicializálásnál, hogy milyen protokoll szerint akarod vezérelni. A rendelékori kiválasztás feleslegesnek tűnik számomra, de ez már más kérdés...

Köszönöm!

Tehát jól értelmezem, hogy a sebességet én állítom be?
Az egyik belső órajelről egy frekvenciaosztást tudok beállítani?

SSD vezérlőt használtál már PMP-vel? Mik a tapasztalatok, esetleg össze tudtad hasonlítani azzal a megoldással, ha manuálisan applikálunk a portlábakkal?

Dehogy. Régen amikor lassú volt egy PIC arra törekedtünk, hogy minél kevesebb lépésben tudjuk kivinni a portra az adatot a memóriából. Egy MX-nél már határeset, leglább is nekem kicsit lassítanom kellett az ütemet, Nop-okkal. Egy MZ-nél, már lehet, hogy valós időzítés is szóba jöhet(timer int), bár kérdés, hogy milyen folyamatok futnak a megjelenítés közben, ami halaszthatatlan, azaz lehet, hogy megfelel a késleltetés is két adat kivitele között, amit meg lehet szakítani a fontosabb dolgokkal, feltéve, hogy azok nem tartanak sokáig és nincs túl sok belőlük. Szóval ez már szervezés kérdése...

Persze, csak PMP-vel használtam, mert másképpen sokkal lassabb.
Úgy lehet sokat gyorsítani, hogy területet választunk ki a kijelző memóriájában, a CS és az RS lábat beállítjuk, majd kiömlesztjük az adatokat a területre PMP-vel. Ezt lehet alkalmazni karaktereknél, textboxoknál, ablakoknál, vonalaknál, gomb rajzolásnál is. Transzparens karakterkiírásnál erre nincs lehetőség, ezért lassabb, de az se vészes.
Itt egy makró az adat írására:

A PMDIN = data reprezentálja a PMP használatának hihetettlen bonyolultságát!
Természetesen egy ciklus magjában foglal helyet a makró, a data pedig egy változó tömb indexelt eleme. A tömb mutathat program területre is(karakter táblák) vagy RAM-ra is, illetve lehet egy kalkulált érték (pl. gombok, vonalak, oválok stb).