Egyszerűen vannak olyan megoldások, amik nem működnek az XC alatt, helyettük kell mást találni. Ilyen pl. a delay függvény megoldás, ami a CPU Countert használja, de az XC-ben nincsenek meg a headerek, átvenni lehetetlen, mert 40 mélységű define van legalább egy egyszerű utasítás mögött, fele annyi fájlban. Aztán az SPI és az I2C-is. Ha készen leszek vele, akkor odadom.
Jelenleg ott tartok, hogy letöröltem az MPLAB X -et és az XC-t, mert olyankat művelt, hogy el se tudom mondani. (minden piros volt, de lefordult, közben a debug ökörségeket művelt, nem találta az alap libraryket, stb.) Most felteszem tisztán és haladok tovább...

Feltettem a 3.25-öt (micsoda új ikonok...). Minden úgy működik, ahogy elvileg kéne. Azért az elég gáz, hogy csak egy teljes takarítás segített. Remélem nem véletlenül hozták ki, mert az előző használhatatlanra dolgozta magát...

Én iszonyatosan ritka esetben használok delay-t, annak a híve vagyok hogy egy jó programban nincs delay, csak timeres időzítés. Persze van amikor a delay kézenfekvő pl mint ma a pmp és lcd init között kicsit várni kell.
Csak érdekesség képp mi a delay függvény neve amit találtál?

Én írtam, nem találtam, megoldásokat kell találnom, nem kódokat...
A Delay-t és minden mást a helyén kell kezelni...
Viszont elkiabáltam. Megint tele nyomja piros aláhúzásokkal. Kezd elegem lenni az XC32-ből! A C32-vel nagy projecteket nyomtam végig hiba nélkül, még jó, hogy ennek csak tesztelésből fogtam neki.

Neked is be kell csatolnod a project beállításánál, az XC32 golbal beállításnál a Common include dirs-hez az XC32 include könyvtárait, hogy felismerje az előre definiált rendszer neveket, makrókat? A vicc, hogy lefordítja simán a pirossal teletömött sorokat...

Mit hallottatok a CPU Count regiszterhez tartozó IFS0bits.CTIF jelzőbitről? Már a PIC32MX-nél is furcsán viselkedett, azaz nem állt be túlcsorduláskor, legalább is nem tért vissza belőle egy while ciklus.

Cache:
A pic32-es családokban mindenütt jelen van cache support is. A flash elérése sokkal több idő, és fogyasztás is, mint a ram elérése. Nem utolsó sorban flash-ből nem is képes akkora sebességből futni a végrehajtás, mint memóriából. A 32mx-nél amennyire megtalálni lehet doksikban, 16 byte-os cache line-ok vannak. Egyszerre a flashből annyi adatot olvas mindig a cpu, és azt áttölti ram-ba. Akár adat célú, akár végrehajtás célú olvasás megy ki flash-re, az mind cache supportot kaphat, ami alapból be van kapcsolva - programból ki lehet kapcsolni, ha úgy szükséges. Van néhány cache line, még ha nem is végtelen sok. Amikor újabb adatokat kell beolvasni, a legrégebben használt cache lineokból veszik el az adat, és azokban kap helyet az új.

Prefetch:
Az utasítás végrehajtás úgy zajlik, hogy dekódolni kell a programot vezérlő bitekre, hogy a processzor állapotgépeit vezérelni tudja. A dekódolás sok órajelet visz el, de szerencsére párhuzamosítható művelet (több állapotgép dolgozik egymással párhuzamosan), viszont ahhoz az is kell, hogy egy későbbi utasítás előzetes feldolgozása már akkor megkezdődjön, amikor a processzor még előző utasítást hajt végre.

Syskey:
Van pár speciális vezérlés, amire azt mondta a microchip, hogy azt nem engedik meg "véletlenül" végrehajtani, például egy eltévedt programvezérlés során, ezért sorfolytonos utasításokhoz kötik az engedélyt, amit teljesíteni kell. Minden "védett módú vezérlés" - nevezzük így - előzetesen igényli azt a szekvenciát (mert utólagosan ki is szokás kapcsolni), és azt nevezték el syskey-nek.

Minden cpu-nak megvan a maga erratája, workaroundokat is ott lehet megtalálni. Ha ott nincsen megemlítve, akkor vagy még senki sem jelentette, vagy hibátlanul működik. Konkrétumokért az adott cpu saját erratáját kotord fel MC-éknél. A processzorhoz tartozó weblapjukon ahol ott van a link az adatlaphoz, ott van a link az erratához is.

Szia! Olvasom a fórumokat, náluk is, nézem a google találatokat, stb. erratában nincs, az volt az első. Az az érdekes, hogy ugyanez volt az MX-ben is. Csak reméltem, hogy esetleg valaki olvasott róla, vagy van ötlete... Köszi!

Ehhez még annyit, hogy van külön cache az adatnak és a programnak. Ez a linkelt forrásokból is látszik.

Segítsetek, bekapcsolom a PMP modult, a LATC2-ben 1 van, az RC2=0. Ez a valós állapot! A két állapot között, csak az történik, hogy PMCONbits.ON = 1; Az RC2 a Blanc LED engedélyező bemenetén van a TFT-n. A lábon csont 0 van, tehát nem valami terhelés és előtte világít a háttér LED. A PMP modulon nincsenek engedélyezezve a cím vonalak. AZ ANSEL beállítva, a TRIS is, hiszen ezt megelőzően működik. A debugg alapján minden protot beállító regiszter jó, illetve nem módosul. Mi veheti át az RC2 vezérlését?
Droot, te használod az RC2-t másra? Megnéznéd, neked működik, miközben PMP-zel? Köszönöm!

...ha a következő lépésben letiltom a PMP-t, az RC2 újra magas lesz.

Nem néztem meg a lábkiosztást az adatlapon, mert azt sem tudom, melyik cpuról van szó, de ha neked megvan az adatlap, írd le, mikkel van együtt az az rc2.

Vakon egy tipp: a jtagot kikapcsoltad a configban?

PIC32MZ2048ECH100
EBIA12/AN21/RPC2/PMA12/RC2
#pragma config JTAGEN = OFF

Most nem vagyok otthon, de megnézem ma.
Nekem a mikrocsip fórumon ajánlották, hogy az ech helyett efh-t használjak, mert az ech-ban nagyon sok a hiba.

Akkor nem biztos hogy van értelme összehasonlítani. Közben folyamatosan tesztelem. Nem csak az RC2 csinálja a marhaságát, hanem más olyan lábak is, amik a PMP PMAx (cím) vonalain vannak (RA5, RA4). Biztosan bekapcsolja a cím lábakat is, pedig határozottan nem kapcsoltam be. Az RA5 a bekapcsolás előtt 0, PMP ON után 1 lesz. A LATA5 továbbra is 0. A másik kettő fordítva. Keresem a hibát...

Ne keressétek, az errataban benne van, hogy nem lehet használni a PMA lábakat kimenetnek, ha PMP aktív. Nem találok szavakat. Csak egy tucatnál több lábat nem lehet használni...

No comment. Hogy adhatnak ki ilyen mikrovezérlőket?

Igen, viszont amit te használsz, abban jelentősen kevesebb a hiba, gyakorlatilag "hibátlan". Nekem ez 8ezerbe fáj. Most rendelhetek ef-eket...

Egyébként nem az a fő kérdés, hogy hogy adhatták ki, hanem az, hogy hogyan lehet ezt jelenleg is forgalmazni? Lehet, hogy próbálok egy csere kérést feldobni a chipcadnél, bár nem hiszem...

Én is csak tök véletlenül említettem meg a mikrocsipp fórumon a PIC pontos típusát és rögtön tanácsolták is, hogy ezt a típust ne használjam.

Hát ja, nem egy olcsó darab. Mindenképp megéri megkérdezni a cserét. Amúgy mikor rendelted? A neten? Van ugye az elállás joga.

Már régen vettem.
Az erratában említik megoldásként az EBI-t. Egyelőre nem értem hogyan lenne ez jó, mert nem találok olyat, hogy le lehet kapcsolni a cím lábait...

Ezzel a kóddal próbálok egy I2C slave IC-nek a 0x6a regiszterét olvasni, de mindig 0-t ad vissza. PIC32MZ2048EFH100 továbbra is.


Az init:

10K-s felhúzóellenállások vannak az SDA és SCL vonalokon.

Sziasztok!
Az alábbi kód a microchip EBI-hez kiadott doksijában található. Kérem, ha valaki érti a működését, akkor segítsen! Az érdekelne, hogy melyik regiszterbe kell betenni a kimenetre szánt 16 bites adatot, vagy előtte hová kell letenni. A PMP-nél ez egyszerű, itt nem jövök rá. Köszi!

Cseréld ki a felhúzót 4,7K-ra. Rommá szívatott, mire eljutottam oda, hogy kicseréltem a felhúzókat. Azonnal jó lett.

Én is jobban támogatom a 4k7-et, de már megy neki 10k -val is...

Ment, de annyira nem tetszett neki. Elég bizonytalan volt a kommunikáció. 4,7K-sat akartam oda tenni csak most elfogyott és 10K volt kéznél, de már raktam mind a két felhúzóhoz még egy 10K-t párhuzamosan, így 5K lett.

Na sikerült rájönnöm (legalább is a lényegre). Nem akarok senkit fárasztani, (ha úgy gondoltátok, hogy ez tök egyszerű, nem értitek, miért nem értem... ), ezért nem is teszem, ha valakit érdekel jelezze, szívesen...

Szerintem aki ebben dolgozik, az tudja, hogy ez bizony előfordul... !
Én megkérlek rá, hogy okulásul írd le, mert valószínűleg másnak is jól fog jönni !

Persze, hogy írd le! Lehet belőle tanulni.

Ha más ilyen sokan kéritek!
Amit elsőre nem értettem, hogyan kerül ki az adat a 16(vagy 8), adat lábra, valamint a cím hogyan képződik, főleg úgy, hogy akár 4 eszközt is rá lehet pattintani. A titok a memória kezelésben van. A memória kezelés a PIC32 családban virtuális memóriaterületről indul, ezt a területet kötik össze a fizikai memóriával. Így nagy ruggalmasságot kapott a bővíthetőség és nem különben a külső memóriák becsatolása, párhuzamos porton nagy sebességgel (valamint a perifériák a CPU-tól függetlenül érhetik el a memória területeket!).
Az EBI-hez is hozzá van rendelve egy virtuális memória cím terület, ami a 0xC0000000-től a 0xC3FFFFFF-ig terjed, ez kb. 64MB-nyi tér (Van egy másik terület is, a 0xE0000000-0xE3FFFFFF, de ez nem gyorsítótárazott (cache-elt)).
Az EBICSx (x=0-3), regiszterekben lehet beállítani a fizikai memóriaterületet, ahol látszani fog az x csatornához rendelt kinti memória. A virtuális 0xC00000000-0xC3FFFFFF a fizikai 0x20000000-0x23FFFFFF címterülettel van összerendelve. Tehát ha a 0xC0000000 címre írunk, akkor az a 0x20000000 fizikai címre való írásnak felel meg, de az EBI címvonalakon 0x00000000 cím jelenik meg. További területeket is összerendelhetünk az EBICSx -ekkel, hasonlóan 0-tól indul a csatorna címe az összerendelés bázis címére való íráskor, olvasáskor. Ha létrehozunk egy 32bites pointert és beállítjuk az összerendelt EBI virtuális címre, majd írunk a címre, akkor az a hozzá csatolt fizikai címre kerül. Az EBI cím vonalak beállnak és vezérlő vonalak is a beállításoknak megfelelően működnek, az adat mozog.
Ha olyan eszköz van, aminek nincs címe (pl. TFT vezérlő IC), akkor le lehet tiltani (nem engedélyezni) az összes címvonalat és egy alap címet használni az adatok mozgatására, azaz ugyanarra a címre dobálni az adatokat. Ez felel meg a címzés nélküli PMP-nek. Remélem érthetőre sikerült és nem tévedek túl sokat!