Mitől térnének? Kilövik az egyik legnagyobb ellenfelüket. Legyártották a hardvert, programot meg írjon rá aki fejleszt rajta.
A baj csak az, hogy a dokumentáció is egyre hiányosabb és kuszább.

Gondoltam attól, hogy a sok visszajelzés alapján rájönnek, hogy amit új utat választottak bemutatásként az eszközeik mellé a felhasználóknak, vásárlóknak, csoki. Ők meg ebből élnek...
Abban igazad lehet, hogy monopol helyzetbe kerültek, ami nem jó és pont az ellen hat, amit indokként írtam.

Őőő az "ARM" az nem Atmel. Két külön cég. Az Arm a risc procik magjait gyártja viszonteladóknak, pld Allwinner.

Nem gyártó,szellemi terméket árul. Ezt lehet licenszelni pl. Atmel.
Bővebben: Link

PIC32MZ I2C buszon szeretnék a csatolmányban látható formátumban adatot fogadni. Nem igazán akar menni.
Az alábbi függvénnyel szeretném:


Az I2C függvények ezek:

Nem nagyon akar sajna menni. A gond az ACK és NACK fogadással van. Ezt hogyan kell megoldani?

Viszont olvastam a cikkben hogy a Microchip-nek nagyobb bevétele volt mint az Atmelnek, csak azt nem tudom miből.
Ahol dolgozom ott olyan termékeket gyártottunk amiben NEC mivel megvette az is a Renesas ilyen kontrollereket használtunk.
Kár hogy Európában nincs hozzá fejlesztőkörnyezet mert biztos jók lehetnek ha a japán vagy kínai tervezők mindent meg tudnak vele csinálni.
PIC-et sorozat gyártott termékben még nem nagyon láttam...

Én már láttam porszívóban, konyhai gépben, fúrógépben, játékban, daruban (jó, mondjuk aszem csak a táp résznél volt), és még elég sok helyen használják.
Szerintem simán megállná a helyét komoly területeken is, csak az is baj, hogy 2015-öt írunk, és még mindig nincs hozzá normális, kiforott magas szintű nyelv (fordító), vagy legalábbis nem terjedt el.

Mi gyártunk BLDC motorokat, amikben PIC a központi vezérlő. Ipari környezetbe szánva, -40 +125 fok közötti hőmérsékletre. Van olyan motor, amiben valami 8 bites, meg van, amiben valami 16 bites van, fejből nem emlékszem a pontos típusokra.

Mit értesz a kiforrott magas szintű nyelv alatt?

Na jó, "kicsit" túlzásba estem, szóval kicsit ezt most visszavonom, viszont nem akarok belemenni, mert megint összehordok csomó butaságot.
De egyébként a C18 miatt akadtam ki, illetve annak megszüntetése miatt. Mert szerintem nagyon jó kis fordító lenne, ha nem álltak volna le vele.

A 8. sor az kell oda?
A 12. pedig NACK-nak felel meg.
A 14. nem is tudom, de talán egyikne se...
Ez az ACK:

Ez A NACK:

Ezzel a két paranccsal várakozik rá?
Egyébként ez egy fényérzékelő lesz, majd a háttérvilágítást szabályozza.

Nem, ezt neked kell kiadnod.
Ezzel ellenőrzöd, hogy kiment-e.

Érdemes bele tenni timeoutot, de szerintem amit küldtem kódot, abban megvan minden rutin, nem?

Tényleg benne van!
Úgy tűnik jó lett!

Nagy nehezen nekem is beindult a PMP. Nem győztem lassítani a kivitelt, de így is gyors, mint a villám. 0,11sec tized alatt tol ki egy teljes képernyőnyi színt, pontonként ciklusból, 800x480 16bit. Ez már tényleg felhasználó barát.

Na igen, az már tényleg tök jó!
Így hogy a PLL-em beindult nekem is lassítani kellett, de szerencsére nem sokat! Bár én csak 640x480-as képet nyomattam ki. Ha jól emlékszem az volt 153ms. Úgyhogy ennyivel lassabb az RA8875.

Valami mégsem kerek!
Tehát így olvasom ki:

A data_L mindig 255 lesz. De miért?

De lehet, hogy neked több utasítás volt a flash programterületről való másolás. Nem hiszem, hogy túl nagy eltérés lenne gyakrolatban a két vezérlő között.
A PMP időzítései nem befolyásolták a sebességet, igaz nem mélyedtem bele, mit is állítanak ezek, lehet, hogy csak címzés és CS jelek kezelését állíták, vagy olyan rövid időket enged max, amik nem játszanak a TFT vezérlő lassúsága miatt.
Holnap átteszem az egészet EBI-re, ha sikerül...

A 8. sorban nem te adod ki az ACK-t, ott fogadnod kell. Ami fehér, az válasz!
A másik, hogy ha az i2c_ack()-ban figyeled, hogy kiment-e a jel, akkor utána nem kell idle-t nézni.

Nekem sem befolyásolták egyébként. Annyi volt a hiba, hogy kirajzoltattam egy képet (egy tömbből, amit beprogramoztam a forráskódból) és a 640x480-as képen volt kb. 10-15db pixel ami mindig zöld színű volt. Ahogy csökkentettem kicsit a sebességet ez helyrejött. De egyébként itt az asztalon vezetékekkel van összekötve minden, még az is lehet, hogy ez volt a baj.

Köszönöm!
Az ACK-t hogyan fogadom?

Nekem is volt régebben 20cm szalagkábellel toldva foldva, ugyanúgy ment! Igen a határt ki lehet kísérletezgetni...

Az idle-vel simán.

A 8. sor kicseréltem i2c_wait_idle();-re és továbbra is 255-öt ad vissza.
Szerk.: A data_h-t megfelelő értékkel adja vissza és a data_l-el van a gond. Az világos, hogy az ACK-t fogadni kellett. De valami mást is elrontottam még?

A 9. ben is idle maradt?
Bizosan nem kevered össze az ACK-t a NACK-val?

Igen, de csak az idle:

nack után nem kell idle. (bár nem biztos, hogy ez segít, de nem kell.)

Nem segített sajna. :/

Na és amit kérdeztem, ack nack nincs összekeverve a rutinban?

Azt leellenőriztem, rendben van.
Azon gondolkozom, hogy lehet hogy a BH1570-es IC beállításában van valami gond.
Az elején a Continuously H-Resolution Mode-ot választottam ki ("Start measurement at 1lx resolution.Measurement Time is typically 120ms. "), most ezt olvasgatom, esetleg nem-e mindig ő küld ki 255-öt.

Szerk.: Úgy látom rendben van és 1 lux-tól kéne mérnie, tehát ha eltakarom 1 lux.