Van még egy olyan megjelenítési design is, hogy pontonként tűnik elő a kép. Mondjuk csak minden 30. pontot jelented meg, a letárolást is eleve úgy csinálod, aztán kitolod, amit visszaolvasol. Úgy időt lehet nyerni.

A munkám és egyben "szórakozásom" is ez amit te csinálsz.
Én nagyon a C# (és VSC++)-ból indultam el. Én nem is C-ben írom ezért váltottam 32 bitre mert ezeket lehet c++-ban is írni. Én úgy indultam el, hogy rajzolok egy téglalapot és bele a szöveget ez egy gomb, folyamatosan kirajzoltam és kirajzolás közben ellenőriztem, hogy a tapi-n megnyomták-e a gomb területét vagy nem, ez alapján back vagy selected color-al rajzoltam a gombot és rajzolás után indirekten hívtam az eventhandlert (említettem nagyon C#-osan épül a projekt).

Amit ebből én észre vettem, hogy mikor állapotot váltott a gomb látható volt a szövegnél egy pici villanás mivel kocka és bele a szöveg ez nem tetszett és (már úgy gondolom hülyeség volt) az csináltam, hogy körberajzoltam a szöveget kis téglalapokkal és utána a szöveget így nem villogott.

És ami neked is fontosabb lehet ami eszembe jutott, mi lenne, ha nem direkte a kijelzőre rajzolnék, hanem lenne egy VRAM abba én kidolgozok mindent (ott működik a téglalap és bele a szöveg) és utána az DMA-val és PMP-vel megy ki a kijelzőre így amíg rajzol ki egy frame-et addig tudom készíteni a következőt, ennek az egyetlen hátránya 153 600 byte egy frame (320x240, 16 bit) így 3 framet tudsz maximum tárolni egy 512 kB-os MZ-vel (ja meg itt ugye ügyeskedni kell a DMA-val mert az 2^16 tömböt tud mozgatni).

Kíváncsi vagyok a véleményedre erről az utolsó dologról, mert még nem kezdtem bele, hogy meg írjam és hátha ebből van egy jobb elgondolásod vagy egy teljesen más jobb ötleted.

Anno működött egy olyan lehetőség, hogy a fórumban lekereshettem a régebbi hozzászólásaimet (pld ha vissza akartam kotorni egy linket amit anno felpostoltam), és valami ilyesmit kellett beírni: "* topic:530 user:pajti2", amire most zéró találatot ad. Kiszedték a funkciót?

Szia! Mondhatni, hogy nekem is. Jelenleg ez nem éles project, inkább olyan előre tervezés, lassan is haladok. Készült már teljes projekt egy MX-el, de azt teljesen átgyúrtam, hogy az objektumokat könnyebben tudjam paraméterezni, kezelni.

Nálam a szöveget ki lehet írni transzparensen is, így nem villog, legalább is nem látom.

A direktbe írás nagyon gyors, nem lesz gyorsabb, ha RAM-ba előkészítem, mert nem biztos, hogy nyerek annyit a DMA-val, mint amit vesztek a részletekben történő kivitellel (800x480=> 768k. Elő lehetne készíteni 256-os blokkban, majd ezt 4x64-ben DMA-val. A DMA-t elő lehet készíteni több címre is, ha jól emlékszem, de még nem használtam...). De majd ezt is kipróbálom, ha lesz érkezésem...

Ezzel az a gond, hogy ha pontonként írom ki, akkor minden pontnak meg kell adni a címét, míg ha kijelölök egy területet, akkor csak tolni kell a szavakat egymás után, a cím automatikusan incrementálódik.

Szia! Sikerült 33MHz-en működtetni egy SST26VF064B-t. 40MHz-en, már nem megy, nyílván nem a flash hibájából. Mivel az SQI a REFCLK2-ről megy, az meg nem lehet 50MHz-nél magasabb, úgy vélem, hogy itt a 32MZ a korlát. A legközelebbi panelen sokkal rövidebben huzalozok, lehet, ettől is. Így elvileg 10MByte/sec-et tudnia kell, bele számítva a pufferből való áttöltést is, az meg talán elég lesz. Ki fog derülni hamarosan...

Sziasztok!

Rávezetett a kíváncsiság a Harmony MHGC (Graphics Composer)-re de nem igazán jöttem rá, hogy tudom be vinni neki, hogy az TFT melyik I/O lábon van, itt meg nagyon azt mutogatja, hogy pár klikk és kész is van.

Egyenlőre csak kipróbálni akarom aztán meglátom, hogy a kedv mennyire visz rá a komolyabb dologra.

Valaki foglalkozott vele már, (tudja) hogy hogy a fenébe lehet beállítani?

A PIC32MZ EC erratában olvasható az SQI-nál, hogy az adatlappal ellentétben nem működik 50MHz-en, csak 25-ön. Az EF erratában nincs említés SQI hibákról, látszólag kijavították mind, de gyanús, hogy ezt a hibát nem, mert az EF se megy 25MHz-nél gyorsabban, már 33MHz-nél is rakás olvasási hiba jön be.
Van más érthetetlen dolog is. A DMA példákban a 32 bájtos puffert nem használják ki, csak 24 re állítját a thresholdot. Ez azért érdekes, mert az ezt követően a kódban 32 bájtot olvasnak ki, ami természetesen hibás olvasáshoz vezet. Szinte az összes microchip példában ez a hiba benne van, még a harmony-ban is ilyen kód fordul! Próbáltam megkeresni az okot, mert biztosan valami EC-ben még jelen lévő puffer kezelési gond miatt maradt ez így mindenhol, de nem találtam. Esetleg valaki tudja a miértet?

A microchip ismét kiakasztott. A DMA-val szenvedek, itt is érdekes dolgkok vannak, de ami a flash-el történt, az agyrém. Vagy egy bit (BPNV) a flash konfigurációs bitjei között, amit ha törlünk, véglegesen törölhetetlen és írhatatlanná válik. Lehet vitatkozni, hogy ennek mi értelme van, mindegy, de hogy olyan szekvenciával lehet ezt megtenni, ami akár véletlenül is előállhat, az gáz. Végül is egy 0xE8 kell hozzá majd 18 ciklus bármilyen tartalommal. Az biztos, hogy nem adtam ki ilyen parancsot, sőt írás parancsot sem, még is lezárta magát a flash. Mivel ez egy olyan parancs, ami gyakorlatilag tönkre teszi a flasht annak aki nem akarja véglegesen lezárni, igazán megtehették volna, hogy komolyabb kódsorozatot kelljen ehhez használni, de legalább azt, hogy kétszer, vagy fene tudja még hány féle képpen lehetett volna megoldani, hogy ne történhessen véletlenül...

A másik a DMA. Jelenleg 256 bájtonként olvasnám ki a lapokat, de minden második lap olvasásakor FF-ek jönnek. Ha elsőre olvasom az FF-et adó lapot, akkor ott van a tartalom. A frekit visszavettem 6MHz-re, tuti nem ez okozza. Ez is valami nagyszerű dolog lehet, amivel a microchip elkápráztat!
Csak remélni tudom, hogy valaki tudja a megoldást!

Nagyon szidja mindenki ezt a céget a nagyobb kontrollerjei miatt, mégis jó üzleti pozicióban vannak. Biztos van más alternativa csak nem ismerjük, pl ahol dolgozom japán vállalat mérnökei a Renesas kontrollerjeit használja, pontosabban a felvásárolt NEC ét is, nem tudom de azok biztos jobbak, de itt európában nem ismertek.

Szia!
Szerintem véglegesen nem tudod magad kizárni a flash-ből,ez nem atmega .Valamelyik védelmet kapcsoltad be,ami nem felejtő,így nem is fogod újra tudni írni.Nézd át a regisztereket,és kapcsolj ki mindent,max törölni kell az egészet .Tény,hogy én csak felületesen használom ezeket a flash-eket,de még nem volt velük gondom.
Simán olvasva jól működik,csak dma-val nem?

Nem lehet törölni és írni. Olvasni lehet bármilyen módban. Az adatlap ezt írja a config bitre:

Én itt 0-t olvasok, azaz végleges lezárás történt. Nem találok olyan utasítást, ami ezt feloldaná, és akkor nem is lehetne végleges...
Ezzel a paranccsal lehet ezt elérni:
Annak nagyon örülnék, ha találnál egy ezt feloldót, de félek nincs. Köszi!

Nekünk ez jutott. Vannak azért jó dolgaik, mert ha nem, már rég nem használnám...

Valójában a 32mz project egészében egy kudarc halmaz. Évek óta nem tudnak zöld ágra vergődni vele. Ami a jó dolgaikat illeti, azok a 32mx795-nél és az mla libeknél véget értek valahol 2012-ben. Azok sem hibátlanok ugyan, de azért meg lehet szokni. Ami attól időben frissebb, én egyetlen jó dolgot sem tudok megemlíteni az mc védelmében.

Egy 32MZ2048EF100-at nyüstölök próbapanelen, vannak dolgai, de kezelhető. Előtte egy EC-t vettem, az kuka, úgy ahogy van. Az EF-en fut egy webszerver, PMP-n keresztül egy TFT, két soros port és most egy SQI flash is, úgy, ahogy 25MHz-el. Az SQI-n vannak érdekes dolgai, pl. Mode0-s órajelnél amit azanalizátor pontosan mutat értéket, a PIC-ben szanaszét esik, nibblénként ok, de a sorrend katasztrófa. Ez tuti hiba.

Mode 3-nál is szétesik?

Anno nézegettem különféle gyártók spi időzítéseit, és az a szitu, hogy a microchip spi-je nem az eredeti motorola spi-t valósította meg. Anno valami üzleti ellenlábaskodás lehetett mögötte, és talán az mc volt jobb pozícióban, de mostanra vesztesnek tűnik a csata. A mode 3 az egyedüli, amelyik kompatibilis tud lenni, bár a bit order még mindig útban van azon is. A microchip spi fixed magas bit -> alacsony bit sorrendben kommunikál, miközben a többin programozható a sorrend ugyan, de hagyományosan alacsony bit -> magas bit sorrendben használják mindenütt. Nem tudom, mennyi kerülhetett át abból a káoszból az sqi tervezésébe is, de az a gyanúm, megmarad az sqi cuccuk házi szabványnak kizárólag a saját flash eszközeikhez.

Hol hasznaljak LSB first modban? Es min lehet allitani a bitsorrendet? Sem az NXP, sem a Motorola, sem az Atmel cuccokon nem lehet allitani. Miota a Motorola kitalalta az SPI-t, az MSB first kommunikal.

Mode3-ban jól működik. Felszálló ágon érvényes az adat. Adatlap szerint mindkét módban jól kell működnie(nem értem minek ez a sok mód, miután ha jól tudom csak a mc gyárt SQI-t), de a mode0 is felszálló ágú, csak az órajel alap állapota nem magas, hanem alacsony. Hogy a szinkron megmaradjon, lehet a fázist is eltolni a módokhoz. Szóval mindkét mód szerint a flashből ugyanaz az adat jön ki, de a PIC nem ugyanazt olvassa be a pufferébe. Ami érdekes, hogy a kimenő parancsot jól adja ki, mert egyébként válasz se jönne...
A bitsorrend a szokásos.

Megnéztem az eredeti 68k-t, tényleg msb first volt. Valamit összekeverhettem. Viszont anno kutakodtam a témát mikrovezérlő kötögetésekről, és találtam fórum blogokat, hogy a pic meg az atmega nem szereti egymást, és a libekből annyi került elő, hogy át volt állítva a bit sorrend. Most nem találtam meg azt a blogot, nem tudom postolni. Helyette itt egy atmega128 adatlap:Bővebben: Link, és a 166. oldalán van egy ilyen:

Megnéztem egy NXP-t is találomra:Bővebben: Link, a doksi 237. oldalán találsz egy ilyet:

Megette a fene a vaksi szemem. Pont az atmega128 doksit neztem meg, mielott azt allitottam, hogy nem tudja megforditani. Az NXP kerdesben viszont csak reszben tevedtem, mert az altalam hasznalt LPC11xx, LPC13xx, LPC17xx, LPC23xx sorozatokban nem tudja megforditani a bitiranyt az SSP modul. Az LPC81x sorozat egy ujabb fejlesztes, annak az SPI modulja egy vicc. De teny, hogy a bitsorrendet meg tudja forditani, de mar egy puffer nem fert bele, nemhog egy FIFO. Igazabol nem is ertem, hogy miert lehet megforditani, hiszen az SPI kimondja, hogy MSB first. Ettol kezdve mire jo ez?

Anno csak arra tudtam gondolni, hogy valamiféle jogi / licence rivalizálásra jó mikroelektronikai szinten, de biztosan persze nem tudom. Amíg nincs akkora kommunikációs sebesség igény, hogy muszáj legyen nyers dma sebességet használni, programozottan is át lehet forgatni a biteket (pld csinálni egy 256 byte-os táblát, és indexeléssel cserélni az adatot). Majd amikor a fejlődési verseny odaér, hogy periféria áramkörök lesznek, amik kötötten lsb first kommunikálnak, majd akkor beérik a gyümölcse annak a játéknak is, mert nagyon bosszantó lesz állandó byte cserével fűteni a processzort. De az még biztosan odébb van.

Nem hiszem, hogy valaha is keszulne olyan periferia, ami LSB first megy. Nem lenne semmi ertelme. Versenyrol meg nem beszelhetunk, mert mindenki MSB first hasznalja az SPI-t. Az, hogy par uC-ben meg lehet forditani, az szerintem nem jelent semmit. Amugy tuloztam, mert az LPC81x SPI-je iranyonkent egy szonyi bufferrel rendelkezik.

pl AD9850, de biztos van még

Az még csak hagyján', de amikor azt írják, hogy SPI, de egyébként I2C... CMT2219.
Persze a lábkiosztásra, meg a rajzra, meg a leírásra ránézve azért hamar leesik, hogy ez bizony I2C, csak érdekes, hogy végig SPI-nak írják, az adatlapon és saját weboldalukon is.

Ez nem SPI interface. Nem minden soros adatatvitel SPI.

Ami azt illeti, a CMT2219 nem I2C. Olyan, mint az SPI, csak 1 vezeteken megy az adat oda/vissza. De semmikeppen nem I2C, mert nincs Start/Stop kondicio, sem ACK/NAK. Raadasul van CS, ami az I2C-n szinten nincs. Az SPI egy full duplex busz, ez az IC csak half duplex.

Basszus, tényleg.

Sikerült egy TFT adatlábait (DB0-DB15) fordítva bekötnöm a mikrovezérlő B portjára.
Van valami nagyon gyorsan lefutó megoldás egy 16 bites regiszter bitjeinek megfordítására? (A 0.bit cseréljen helyet a 15.-el, az 1. bit cseréljen helyet a 14.-el stb...)
Kár hogy nincs ilyen utasítás (dsPIC33E).

A legegyszerűbb az lenne,ha az MSB-LSB -t fel tudnád cserélni,valahol olvastam,hogy ott lehetett .
De itt szerintem marad a bitenkénti csere.Egy kis ciklussal meg lehet oldani,bár TFT-nél már lehet,hogy ez bezavar.