Így néhány perc alatt rájöttem, hogy miért nem olvassa ki jól az MCP79411 -ból az egyedi azonosítót a rutinom. Hiába debuggoltam a C# oldalon több órát, minden adatforgalom rendben lezajlott, csak az adat volt rossz. Az I2C jelek szép síma vízszintes vonalak voltak alacsony szinten. Egy apró hibát vétettem, kimaradt egy sor. Csak azt a script -et nem futtatam le, ami a beállította volna az ICSP vonalak meghajtását: ProgEnrty... Ha lefuttatom, teljesen jól megy a kiolvasás és az írás is. A jeleken alig van aktivitás, egy szkópon nem látni semmit sem - jobb analizátorom meg nincs.

Tényleg hasznos! Én is bele szoktam esni abba a hibába, hogy lusta vagyok kiépíteni a vizsgáló kört. Keresem, kutatom a hibát, mindent jónak vélek, aztán mikor megunom és rákötök valamit, amin látom is a jeleket, rögtön rájövök, hogy természetesen nem az áramkör a hibás! Visszatérve, azt sajnálom, hogy a Microchip-nél nincsenek olyan jó szakik, mint te! Sokkal előrébb lennének és mindenkinek jobb lenne! Persze lehet, hogy a PK2 kivezetése mögött sokkal inkább üzleti megfontolás volt, nem szakmai!

Hát valahogy így lehet... A PICkit3 bizonytalansága miatt a firmware "kitudódott", így leképzelhető, hogy rövidesen jön a PIC32 -re épülő PICKit4 és a PICKit3 fejlesztésével is felhagynak... Így lehet 2 - 4 évenként eladni egy csomó fejlesztőeszközt...

Működik az SST Flash is ... Csak a gépben legyen elég memória meg a felhasználó legyen elég türelmes. A 2Mbyte ellenőrzéséhez 790MB memória foglalás és kb 5 perc idő kell. Még csak ezt próbáltam, de a nagyobbakra nincs is esélyen 2Gb ram -mal a gépben...
Életveszélyes a típus autodetektálása, ha SPI EEProm van a PICKit2 -höz kapcsolva. Mivel nem tudja detektálni (még azt sem veszi figyelembe, hogy utoljára egy nem detektálható családot használtak), végigpróbálja az összes családot, egy 3.6V -os memóriára rákapcsolva a 13V -ot is (CE# -- MCLR / VPP). Megoldás az induláskori keresés, detektálás letiltása vagy jó előre a manuális kiválasztás beállítása vagy a család kiválasztása utáni csatlakoztatás.

Szerintem ha nincs elég memória, akkor a háttértárban alakítja ki a területet. Egy próbát megér!
A buta keresgélése valóban bajt okozhat! Nagyon oda kell figyelni, hogy a család kiválasztása legyen meg és nem szabad rádugni semmire, amíg a programja fel nem állt. A gond akkor kezdődik igazán, amikor nem találja meg valamiért az eszközt és elkezdi keresgélni tovább magasabb feszeken. Most abban nem vagyok biztos, hogy ha kiválasztok egy 3,6V-os családot és nem találja, hogy akkor is elkezd keresgélni nagyobb feszeken? Azt hiszem nem...

Szia!
Gratulálok a türelmedhez, a kitartásodhoz és a segítő szándékodhoz !

El sem tudom képzelni, hogy miért kell egy 2 MB-os terület ellenőrzéséhez közel 1 GB ?! Mit csinál, hogy közel 500-szoros területet igényel ?! Te látod ezt a sok "kusza" szál között ?!
Steve

Szia!
C# int[2^21] foglalása kb. 8Mbyte. Ehhez jön még a program és más adatszerkezetei kb 500kb valamint egy datagrid az ő 131072 * 16 = 2097152 db datagriditem rublikájával. Ellenőrzéskor átmenetileg az adatterület és a datagrid is kétszer foglalódik. Ezek szerint (durván) egy datagriditem helyfoglalása kb. 200 byte...

Egy kis kellemetlenség árán megzaboláztam a memóriaigényt. Ha egy EEPRom kapacitása nagyobb, mint 64K, az ablakban csak 64k látható és egy külön kezelőszervvel lehet a 64K -s lapokat váltani. Így 90-120 M -val beéri egy SST25FV064C ellenőrzésénél is. Bejött, a datagrid zabálja fel azt a rengeteg memóriát.

!
Steve

Nagy az esélye annak, hogy tönkretesszük a memória áramkörünket, ha legutoljára SPI vagy MicroWire EEPROM -mal foglalkoztunk és újraindítjuk a programot. Ezek a típusok felhasználják a MCLR / Vpp kivezetést a programozáshoz.
Feledékenyeknek:

Tetszik, amit csinálsz, és maximálisan elismerem a témába fektetett energiáidat!

Egy kis helyesbítés a jelenleg legutolsó posztodhoz: a harmfull egy db L-lel írandó.

Megint csak elismerésem
Tetszik hogy megszállottan dolgozol ezen a projekten .
Egy összefoglalót csinálhatnál hogy milyen új opciókat tettél bele (kíváncsiságból).

Várom már a béta tesztet

Köszönöm, javítom...

Szia! Ha bekötési rajzokat is készítesz a programhoz, akkor érdemes lenne egy zenert betenni védelemnek.

Szia!
Nagy vonalakban összefoglalva:
- Kisebb javítások, amik csak idegesítik a felhasználót:
A logikai analizátor bmp kiterjesztéssel mentette a png állományt, sem a logikai alanizátor sem az uart tools nem jegyzte meg az utoljára használt könyvtárat, hierarchikus családnevek kezelési problémák kiküszöbölése, egyes beállító ablakok kiválasztás nélkül is továbbengedték a programot (PICKit2 és DeviceFile kiválasztás), az utolsó 9 állomány megjegyzése, Vdd értékének megjelenítése a logikai tools és az uart tool ablakán.
- Nagyobb átalakítások:
PIC32 típusazonosító és revízió kezelés kibővítése, 16 és 32 bites típusok programozásánál a programming executive be volt fordítva a kódba megnehezítve a változtatásukat. A típushoz tartozó legfrissebb programming executive állományból való betöltésével megnyílt az út a kezelhető típusok számának növelésére.
- Kényelmi szolgáltatások:
Device support ablak exportálási és nyomtatási lehetőséggel, Hex összefűzési lehetőség bootloader -es konfigurációkhoz, több kisebb EEProm tartalmának betöltési lehetősége egy nagyobb kapacitásúba, időzített jelváltás a logic tools ablakban, EEPRom, HCS, KEELOQ eszközök bekötéséhez ábra, az ablakokban a szöveges rész is szerkeszthető (12, 14 bites kontrollereken a program memória szöveges kezelésénél csak az uatsítás alsó 8 bitje írható át), decimális megadásai lehetőség a memória ablak hexa részében ("." -tal kell kezdeni), időzített jelváltások kiadása a logic tools ablakban, a logikai alanizátor csv és sbs állományba is tudja menteni a regisztrátumot.
- DeviceFile:
Meg kellett változtatnom a DeviceFile -ban tárolt adatokat (főleg a PIC32MX és az EEProm kezeléséhez), így nem kompatibilis a Microchip által kiadottal.
- Eszközök bővítése:
Szinte minden most gyártásban levő és régebbi típus kezelésének megvalósítása:

- Programozástechnika: EEPRom kezelés memóriaigényének csökkentése.
És még egy sor más változtatás, ami most nem is jut az eszembe...

Szép listát csináltál

Elismerésem!


Eléggé szemléletes így a beleölt munkaóráid.

Én is gratulálok, ez tényleg nagyon nagy munka és ha elérhetővé teszed, akkor meg is köszönjük !
Steve

Gratulálok! Ilyesmivel (amit itt bevarázsoltál), még nem találkoztam. Köszönjük!

Köszönöm... Már csak az általam bevitt hibákat kellene kimazsolázni belőle...
Még egy-két dolgon gondolkozom:
- Uart tool legyen képes lejátszani egy az RCREG -re vonatkozó stimulus adatállományt.
- Egy kis firmware módosítással egy 3 csatornás Pattern generátor is kijöhetne a PICKit2 -ből: 1us/minta .. 10s/minta; 1024 mintával.

Igen, ez nekem is volt eszemben, mint hasznos lehetőség, de nem gondoltam, hogy van rá esély, hogy belevarázsolod !
Steve

Üdv
Van szerencsém személyesen ismerni Hp41C-t nagyon nagy koponya, minden elismerésem és tiszteletem az övé.

PIC32MZ ügyben: Bővebben: Link (valami Microchipes konferencia Csehországban)

Nem tudom, kinek mennyi infója van róla, én ezeket találtam:
141. oldal: M14KEC mag, 200 MHz, 300+ DMIPS, High Speed USB, 2MB flash, 512KB RAM, valami SST Flash interface, 12bit ADC, meg a többi sallang. Azt írják, gyorsabb lesz, mint a Cortex M4 (azon meglepődnék )
A következő oldalon a PIC32MX5/6/7 szériából nyilazzák, tehát gondolom abból fejlesztik tovább, ergo szerintem valami hasonlóra lehet számítani égetési dolgok terén is, mint az 5/6/7-ben.

Ilyenkor mindig a ZX Spectrum jut eszembe...

Szia!
A PIC32MZ programozása jelentősen fog változni: Programozási leírás már megjelent.

Nem néztem meg, de ezt nem miattad csinálják ?!
Steve

Nekik még nem írtam semmit... A magyar nyelvet nem túl jól fordítja a kugli.
A PICKit3, ICD3 kiokosítása a 32MZ programozásához sem lesz egyszerű.

Pedig lehet, hogy állást ajánlalának!

Az első már el is készült....

Ez tetszik, hasznos kiegészítés lesz!

A múltkor használtam volna a PICkit2öt UARTnak, de nem lehet a kommunikációt állítani, csak a sebességet. Nagyon nehéz hozzáadni a paritás állítását?