Működik az említett példám, de lassabb pár usec-el, mint ha 5usec-et várakoznék az DMA int-ben...
Egyébként 58msec alatt törli le így a kijelzőt.
Csak halkan jegyzem meg, hogy ciklusból ez 52msec!

Szerintem ha a transfer complete re rakj egy intet es az intben indits el egy timert (CT is lehet) es azzal varj 5 us-t.

Utána még módosítottam pár dolgot(egyel több csomagot toltam ki, mert nem számoltam azt, amivel indítottam, így 54ms lett. A 2ms eltérés itt már nem az 5usec várakozáson múlik, hanem azon, hogy a DMA és a PMP target szinkronja 140nsec-es periódust ad, a ciklusban vezérelt 130nsec-hez képest. A ciklusost tovább lehetne gyorsítani, mert nop-al van késleltetve a kiírási rutin, ami egyébként is egy szubrutinhívás, ami eleve lassít. A gyorsításra tett kísérletek nem sikeresek, mert a kivitt adat sérül, hasonlóan a DMA-s esethez, ahol a PMP várakozásait sem lassíthatom, főleg nem tudom befolyásolni a PMP target párbeszéd időzítését, amit elég soknak találok. Ezek a változtatások pixelenként 10nsec-et jelentenek, ami 384000 pixel esetén(800x480) 3,8msec-et gyorsítana, azaz nem számottevő. Nagyságrendi gyorsításról szó sem lehet a PIC miatt.
Persze nem vagyok biztos benne, hogy mindent úgy csinálok, ahogy azt elképzelték, csak a gond, hogy a microchip nem túl bőbeszédű a PIC32 családról.

Szia!
Én nem használom a DMA-t csak a PMP megy (még most kezdtem a pic32MZ-vel foglakozni). Ha jól értem te is egy 480*800 as kijelzőt hajtasz. Az lenne a kérdésem hogy DMA -val mennyivel gyorsabb? Gyorsabb e akkor a PMP ha a dedikált WR és CS lábakat használom? Mert per pill a teljes fill rutin is max 5* megy kb le másodpercenként. Háttér és szövegcsere 16 biten kiábrándítóan lassú, mármint egy villanás de szemmel lekövethető.

Szia! Igen 800x480.
Amit olvashattál eddig, az egy egyszerű képernyőfeltöltés volt DMA-val.
A WR és RD lábakat a PMP kezeli jelentős sebességnövekedést okozva a szoftveressel szemben.
A CS (és az Adat/parancs) láb nálam szoftveres, de ennek nincs lassító szerepe, mert egyszer kell beállítani a tranzakció előtt.
Visszatérve a DMA-ra, sebességben lassabbnak adódott a RAM-ból való átvitel az egy változó kiküldésével szemben ciklusból (DMA 54ms vs. SW 52ms), de nem szabad elfelejteni, hogy közben egyáltalán nem terheli a magot! Bár látszólag egy képernyő törlést úgy is meg kell várni a további képernyőkezelések előtt, de azt várakozással tenni pazarlás, azt állapotgéppel illik tenni.
Tehát a művelet ~3,5%-al lassabb (a jelenlegi legjobb tudásom szerint), de a program futására nézve jelentősen gyorsabb lehet.

Az 54ms-es fill szemmel látható, de gyakorlatban megfelelő sebességű. Okostelefonos világban megmosolyogtató, de ipari szemmel megfelelő.

Az okostelefonokban 1.5 - 2+ MHz-es magok ketyegnek a 200MHz-es PIC-el szemben. Csapj alá egy megfelelő ARM-et és gyosabb lesz De ahogy mondtad ipari alkalmazásban elég.

Egy videot dobhatnál róla, megnézném mit jelent az az 54ms.

Egyébként az ebay-en van 5ˇvagy 7ˇkijelző ami aruino-hoz van ott pakoltak rá egy DRAM-ot meg egy FPGA-t (persze nem a legjobb módon, de az elgondolás jó). ha el akarod kerülni a frissítés láthatóságát akkor akkor ezzel nagyon szépen megoldható.
Vagy a másik út, de erről nem tudom, hogy nagyobb kijelzőknél mit csinál a PIC32MZ DA ott kapsz 32MB belső DRAM-ot is.

Furcsállom, hogy DMA-val lassabb, de ~50ms-ig blokkolni az MCU-t valamelyest durva, meg ha az SW közben jön high priority interrupt (sokszor) akkor sw-vel mert nem 52 ms-el vagy.
De az az 52-ms ha használsz VRAM-ot az objektumoknak a fill alatt pont elég hogy ki rendeled őket a VRAM-ban vagy ha nem csak grafika akkor 1000 mást dolgot végre tudsz hajtanii.

usane az giga akart lenni nem ?

Igen, Giga akart lenni

Igazából a sebességeket csak tájékoztatásként említettem a kérdésre válaszolva, nem panaszkodásképpen.
A PIC32 DA sorozat érdekel, lehet, hogy veszek, de a RAM-tól gyorsabb nem lesz az átvitel, mert a 140ns-es periódus szerintem a PMP és a DMA szinkronjából adódik.
Kisebb képek és más objektumok, mint pl. egy gomb, vagy egy Text esetén kielégítően gyors a megjelenítés. 32MX-el készítettem komoly alkalmazást és nincs panasz a TFT-re (pedig ott a DMA-t sem használtam még). Az MZ-vel ismerkedek, tesztelgetem amikor van rá idő, amíg nem ismertem ki teljesen, nem fogok tervezni köré semmit. Egyébként nem csalódtam benne nagyot, de az MX sorozat sokkal kiforrottabb, csak hát a 252MHz csábító volt.

Én is furcsállom a DMA PMP lassúságát.

Még egy dolog jutott eszembe a szinkron miatt.
Lehet sületlenség amire gondolok sose piszkáltam, de hátha.
Elvileg ugye MZ/MX mindegy van egy bus arbiter ami ugye adott bus-on megszabja a prioritást és lehet hogy a prioritás miatt megfogja a DMA-t? (nem tudom hogy PIC32-őn lehet-e a RAM-ból két külön címről egyszerre olvasni vagy hogy a DMA külön fér hozzá a RAM-hoz)

Gondoltam hogy nem panaszkodás teljesen csak a jó szándék vezérlet a gondolat megosztásával

Nem ai integrált memóriától lesz gyorsabb, hanem a dedikált LCD meghajtótól, amivel 50MHz/pixel sebességet lehet elérni.
Valamint/és az EBI perifériától, ami szintén tudja ezt a sebességet, és nem mellesleg az általad használtban is leledzik belőle. Gyorsabb, mint a PMP, miért nem azt használod inkább?!

De mindig pontosan ugyanakkor lép érvénybe a priorizálás? Mert a jelalak teljesen egyenletes a kivitel során. És, ha igen, akkor se tudunk ezen változtatni, gondolom.

Nem hiszek a szememnek!
A tőled kapott inicializáló kódsorozattal feléledtek azok a kijelzők, amelyekről már kezdtem azt hinni, hogy rosszak! Azta...., mit összeszenvedtem eddig ezekkel...
A dolog érdekessége, hogy van más eladótól származó ILI9341-es LCD-m is, az pl működött már korábban is, de ez a másik fajta istennek nem akart elindulni Pedig a te kódod alig különbözik a már korábban próbálgatott innen onnan vadászott kódoktól, de eddig egyikre sem reagált a kijelző. Ez a kód viszont jó mind a két féléhez...szuper...hálám örökké üldözni fog
Ha lesz időm és kedvem, megpróbálom kideríteni, melyik bit, vagy sorrend okozhatja az eltérést?! Bár lenne pár keresetlen szavam a gyártóhoz, hogy miért nem egyezik a két azonos típusú driver IC-je ?!

Amúgy elképzelésem sincs mit hogy csinál az init kód és hogy mi micsoda benne
Valamelyik arduionos driver-ből néztem ki ment vele így nem is foglalkoztatott.

Wezuv: említettem lehet hogy hülyeség csak olyan érthetetlennek tartom, hogy az a 2 ms miért a DMA oldalára szól negatívan, persze gondolom neked se világ fájdalom, de azért mégis -ha már elvileg a DMA gyorsabb.

De egyébként a fill-t hogy csinálod DMA-val tud memory fill-t is a DMA nem csak memory copy-t?

Hali!
Fill: x címre lerakod mivel kell tölteni, és copy az x címről az x+1 címre, már ha azonos memória blokkról van szó.
A dma felprogizásához nem értek, lehet igy nem lehet megcsinálni...

DMA forrás egy 32000 szavas(16bites) tömb címe, a cél a PMP regiszterének címe (16bites). Mivel a DMA max 65536 bájtot tud egyszerre átvinni, ezért több részletben kell ezt megoldani. Amikor a DMA kész, akkor megszakítást okoz, itt indítva van a PMP megszakítás, hogy megvárja a PMP-t, itt indítva van a következő DMA csomag, egészen 12 csomagig. A köztes műveletek a logon látszanak, de nem számottevőek.
A sebesség abból adódik, hogy a 20ns-es WR után 120ns szünet jön, amit maga a DMA PMP szinkronizáció okozhat, mert szoftveresen más nem történik. Ezt a 120ns-es szünetet nem tudtam befolyásolni eddig, de az tény, hogy szoftveresen se lehet e fölé menni, mert akkor hibázik az átvitel, tehát ez a PMP tulajdonsága lehet. Pedig a PMP 100MHz-ről megy és az adatlap szerint gyorsabbnak kellene lennie (ha csak nem olvastam félre valamit).
Tehát nem a DAM-val "lassú", szoftveresen sem lehet gyorsítani a 130ns-nél jobban. Ha gyorsítom, nem megy ki a WR jel, illetve nem mind. Ez a PMP tulajdonsága szerintem, vagy valami rossz beállítás, bár nem találok olyat, ami javítana.

Az elvi "DMA gyorsabb" feltevés elvi marad. Memory-memory között biztosan gyorsabb!

Sikerült kiderítenem, miért nem működött eddig ez a fajta LCD!
Ennek van egy 0xF7-es regisztere is(Pump ratio control). A régebbi adatlap ezt meg sem említi végképp, a legfrissebben benne van ugyan, de mintha ott is csak utólag csapták volna hozzá. A lényeg, hogy a benne lévő alapértelmezett értékkel valamelyik driver működik, valamelyik pedig nem(pl az enyém). Ha ez a regiszter értéket kap(megfelelőt), akkor mindkettő működik.
Viszont eddig ez volt feltehetően az egyetlen kód, amit tőled kaptam, ami tartalmazta ennek a regiszternek az írását is, ezért működött vele. Gondolom a többi kódot alkalmazó szerencsés LCD tulajdonosnak olyan verziójú LCD-je volt, ami nem igényelte eme regiszter átírását(avagy az alapértelmezett érték más azokban, és az megfelelő), ezért működött nekik.

Megosztanád a jó adatlap linkjét?

Van a pic-ben egy bus master, ami az átviteleket vezérli több csatornán prioritás alapon a perifériák és a memória között. Az mcu doksijaiban le van írva, elolvashatod részleteiben, ha van kedved hozzá. De annak elvileg nem szabadna tévesztenie, vagy ha mégis téveszt, az mikrokód hiba, amivel te tenni semmit sem tudsz.

Ha biztos vagy benne, hogy nem félreprogramozás esetéről van szó, és van kedved hibát bejelenteni az esetről, akkor amit tenned kellene, egy "fénytiszta" project gyártása. Mondjuk elő-init-elni egy memória tömböt, és dma-val tolni ki pmp-re a memóriát, ami szkóppal könnyen ellenőrizhető valami biten, hogy nem az a minta van ott, mint aminek kellene. Aztán feltolni a projectet az mc fórumra hibajelentéshez. Lesallangozni azért kell, mert másoknak is meg kell néznie, ugyan azt a hibát jól láthatóan fel kell ismerniük, és ha nem "fénytiszta" egy project, rá se fognak bagózni. Arra is gondolj, hogy ami hardveren meg akarják majd nézni, az valószínűleg egy előregyártott MC board. Olyan boardon jól kivezetett jeleken kell tudniuk megszemlélni a hibát. Ha ők is visszajelzik, hogy a program pöpec, de a pic sza*, akkor azzal a problémával már az MC saját mérnökei fognak tovább szenvedni, és valamit majd kitalálnak rá.

Ha nem ér neked annyi kínlódást a probléma, simán csak hagyd a fenébe, és használj interrupt-on programozott módot, vagy valami más perifériát.

Nem szerettem volna azt állítani, hogy az adatlap hibás, vagy a PIC hibás, az legfeljebb csak kiszólás volt, elnézést.
A PMP ciklus időtartamát a WAITB,WAITM,WAITE beállításai meghatározzák. Ehhez kell hozzávenni a DMA műveletekhez szükséges ciklusokat. A jelenlegi beállítások mellett a PMP ciklusnak (1,2,1)=>7*TPBCLK=70ns alatt kellene lezajlani.
Ehhez jön DMA szelete. A DMA-ról nem derül ki, hogy hány órajelre van szüksége egy 16bites RAM változó periféria regiszterbe való mozgatásához (lehet, hogy a COR adatlapját kéne nézegetni?). Lehetséges, hogy erre 70ns kell? Fel kell ismerje a PMP int flagjét, növelnie kell a címet, majd engedélyeznie kell pár belső vezérlő lábat, szerintem ez néhány órajel, lehet, hogy kettő, de nem 70ns... ?

Na mindegy, nem feltétlenül akarom megfejteni az okot, attól függetlenül, hogy felteszem a kérdést, lényeg, hogy nekem ennyit sikerült eddig elérni. Ha sikerülne gyorsítani, jelzem.

Ez a legfrissebb doksi, amit találtam hozzá!

Pár dolgot módosítottam a szoftveres fill-en. Sikerült 13,6ms alatt letudni (gyakorlatilag egyszerre töltődik ki a képernyő, szemmel nem lehet követni). Ha két egymásba ágyazott ciklusba szerveztem a kivitelt és csak egy PMDIN=Color volt belül, akkor 16ms alatt végzett. Most 100db egyedi kivitel van a belső ciklusban és 4 "nop" van közöttük. Ha nincs közöttük nop, akkor a PMP elárasztódik, nem visz ki minden adatot.
Ezek után még inkább nem tudom, hogy én rontok-e el valamit a DMA-nál...

Nem tudom, hogy szerintetek triviális-e, de a harmony példákban a protokhoz tartozó órajelet (PBCLK4) is 100MHz-re állítják be. Egyetlen DMA példánál és más példánál sem láttam más értéket.
Nos kínomban beállítottam az adatlap jóváhagyásával a portokat 200MHz-re. (csak ezt lehet 200MHz-re állítani, a többi max 100MHz lehet).
Az eredmény 21,17ms -es fill DMA-val. Az még mindig érdekes, hogy az átvitel során 40 és 70ns-es periódusok követik egymást (a szoftveresnél 30 és 40, de ott sem egyforma!). Ha mind 40ns lenne, amit nem értek miért nem így van, akkor 20ms alá menne a művelet.
De már így is kielégítően gyors, de szoftveresen még így is majd kétszer gyorsabb, ellenben így nem terheli a magot.

800x480 ~20ms fill jól hangzik, grat.

Azért én még utána néztem ennek a bus arbitration-nek Bővebben: Link.
És ha jól értelmeztem két Initiator nem férhet hozzá azonos Target-hez.
Tehát ha változót piszkál a proci a RAM bank 1-ből és a 32k-s tömb RAM bank 1-ben van akkor a CPU megállíthatja a DMA-t.

Esetleg próbáld ki ezt, hogy 32k-t a RAM bank 2-ben van a tömb és onnan pakol ki PMP-re.
Bár szerintem ezzel nem fogsz sokat nyeri max 3-4 ms-t.

Meg a PBCLK4 biztos hogy mehet 200MHz-ről?
Nem csak a PBCLK7 mehet 200MHz-ről (ami a core-é)?

A DMA-hoz speciálisan kell (ajánlott) deklarálni a változókat:

Ez a 0xA0003990 címterületre teszi a tömböt, ami a bank2 ha jól tudom.

Jó a 20ms, de szoftveresen 13...

Játszok az optimalizálásokkal, hát ha hiszed, ha nem lassabb 1-2ms-el, de volt olyan beállítás, ahol 40ms-re emelkedett. Legkevesebb, hogy érdekes.

A PBCLK4-rő az adatlap "AC Characteristics and Timing Parameters" táblázatában olvasható az infó.

Wezuv köszi az infot-t.

Egyébként cache-elt a flash?
Mert ha nincs cache-elve és a sw-s ennyivel gyorsabb az nekem fura.
Esetleg csak próbaként ha nem int-el indítod el a következő átvitelt, hanem channel chain-el (ez elég komoly DMA pazarlás, de ha van kedved egy próbát megér).

A későbbiekben esetleg lenne értelme a rederelő függvényeket (pl háromszög render) ramfunc-ként használni hogy a render is a leggyorsabb lehessen.

Channel-to-channel chaining -ra gondolsz?
Gondoltam rá, de eddig azért nem próbáltam, mert 11 alkalommal kerül a szál a PMP interruptra a teljes átvitel alatt (12*32000 szó). Ezek a váltások láthatóak a logoláson, de összegük minimális nyereséget okozhatna.
Ha fontos lenne a sebesség (fill-é), akkor SW megoldást használnék, ha nem, akkor DMA-t. Jelen esetben sokkal fontosabb a tapasztalat...

Erről a ramfunc megoldásról tudnál írni, mire gondolsz?

Sosem használtam de XC32 doksiban van róla info.
Nem tudom hogy hívják pontosan, de például van olyan rendszer ami flash-ből indul és átmásolják a RAM-ba a kódot és RAM-ból fut a kód.
Az egésznek 1 értelme van nem kell cache-elni.

Csak azért gondolok erre mert ugye a render erősen köti a procit, de ha procinak nem kell arra várnia hogy a flash-ből elérje az adatot megint gyorsul azt nem tudom mennyivel de valamivel biztos.

Ezt még nem is hallottam, hogy képes RAM-ból kódot futtatni. Köszi az infót, utána nézek!