Keresem, hogy az ICD3 milyen órajelet használ az ICSP-n, de nem találom. A J-Tag kommunikációban külön van be és kimenet, ez talán gyorsítja a debuggolás, de függ az órajeltől is. A Base (V9) 15MHz-et tud, a Pro 50MHz-et. Az ICD3 se lassú de a tesztek Pro-val hasonlítják össze, ami a mi esetünkben 3x is gyorsabb a Base-nél. Igaz nem erre veszem a V9-et, így nem érhet veszteség. Ellenben ha legalább úgy használható, mint az ICD3, akkor másoknak megfontolandó lehet (a V9 10alatt kapható, igaz nem tiszta a jogviszony, az ICD3 70felett...).

Hurrá! Sikerült!

Felismerte a pickit2 a PIC18F46K80-at.
Hálásan köszönöm Neked is a rávezetést és Hp41C -nek a dat file okosítást.

Bővebben: Link
Bővebben: Link

Ezek nem tudom mennyire valós adatok mert én se nagyon találtam semmit az MC honlapján erről, de ismét érdekes adatok.

Itt bújt el a válaszom.

Szia!
Csak a PICkit3 -ról van tapasztalatom. Sokszor küld teljesen felesleges (megismételt) parancsokat.

Talán azt lehet kiolvasni, hogy 6MHz az ICD3 ICSP-je (De lehet, hogy tévedek, mert ez inkább az NSDSP-re igaz, amit gyorsabbnak állítanak, így az ICD3 nem éri el a 6MHz-et). Ha a V9 15MHz et tud, akkor kétszer is gyorsabb lehet, ha Jtag-al lehetne használni, akkor még gyorsabb lehetne, feltéve, hogy a vonalak elbírják (nem véletlen a táblázat az ajánlott kondikkal). Kezd érdekessé válni a dolog, tűkön ülök...

Ha megérkezik, akár lehet egy cikket is megérne, megnézi JTAG, ICSP ki milyen gyors, meg hogy ugyanúgy szétesik a (asszem sima HID driver-e van) a kapcsolat vagy megbízhatóbb-e.
Ha az ICSP is él rajta akár a kezdőknek is jó választás lehet (8 biten még nem láttam JATAG-et az MC-nél).

Az mc-nél mostanra az atmeles avr cuccok is ott vannak. Jtagosok mind. A pk2 tudja őket vinni, a pk3 nem. Az mc kicsi üdvöskéje pofára esett?

Cikket biztosan nem fogok írni...

A pk2 hogyan?

Úgy, hogy a pk2 kimeneteihez még hozzá lehetett férni támogatott protokollal, és alkalmazás szinten újra lehetett definiálni a funkcionalitását, amit a pk3-ból _direkt_ kivettek (mert az MC görbe-orrú mindenségit nekije). Egy rövidke blog kiindulási pontnak, és egy külön megmentett letöltési lehetőség.

Meglepődtem volna, ha újra támogatnák! Nem érdemes ilyen megoldásokat alkalmazni, sokkal jobbak vannak.

Tényleg vannak jobb megoldások.

Minden elismerésem a tiéd, de egy mikrovezérlő beégetése nagyon szűk területe a vele való foglalkozásnak, főleg ha az egy 32bites eszköz hatalmas programterülettel és tudással. Gondolom te se PK2-t használsz amikor fejlesztesz...

A pickit sem több, mint egy szimpla digitális állapotgép, amit akár egy pic16f-el meg lehetne valósítani 8 bittől 32 bitig mindegyik pic-hez. Elvégre nem kell más, mint vezérelni valamilyen szintű meghajtást (pld fetes szintillesztőket vezérelni a pic kimeneteivel, illetve kell egy darab bemenet is szintillesztve), és adni égető feszültséget (amit szintén lehet digitálisan vezérelni, hogy mit állítson elő az usb 5 voltjából). Igaz, azon nem lenne programmer-to-go, de hát már a pk3-on sincs. Debugra sem biztos, hogy nagyon gyors lenne, de ha nem kell extra sebesség, arra bőven elég. A 16f-eket egy generic usb driver az mc libjével is meg tudja hajtani 64 kbyte / sec sebességig. Teljes kompatibilitás még android-ra is open source driverrel. Programozási sebességnek az is elég tud lenni. Nem kellene többé törődni még a pk2 beépített protokoljaival sem, le van-e valami dokumentálva vagy nincs, úgy működik-e, ahogyan írják, vagy úgymond félreértések vannak az egyes verzióknál és társaik. PC oldalra kerülhetne minden. Egyszer kellene csak megírni, és a világ végezetéig működhetne utána.

De lenne vele egy cefet nagy baj. Open hardware lenne. Bárki otthon kézileg le tudná barkácsolni 2-3k huf alkatrész + nyák költségből, és az úgy már nem jó. Még a végén hozzászokna a piac, hogy kreatív legyen és önálló. Mi történne akkor a kihasználhatósággal? Félnek azok a nyavajások az mc finanszírozási székeiben, hogy nem tudják majd zsírosra szedni magukat. Annyi az előnye a pk3-nak, a világon semmi más.

Nekem be jön a dizájnja a PK3-nak úgyhogy nálam két előny van
De viccet félre téve 32MZ-hez használhatatlan, de lehet nem is kell ilyen messze menni lehet, hogy egy 128K 16 bithez se kényelmes.

Ebben egyetértek, de én nem is állítottam ennek ellenkezőjét. Amit én állítok, hogy házilag nem vagyunk képesek a PK2-t sem a 3-at debuggolásra bírni, akkármilyen ügyesek és profik is nagyunk, ha az IDE nem támogatja a kérdéses MC-t rajtuk keresztül. Programozni COM-on keresztül is lehet...

Sziasztok!

Már régebben itt kérdeztem, hogy lehetne a LAT struktúra bármelyik elemére hivatkozni, hogy kicsit arduino-s módon lehetne pin címet átadni függvénynek, ott a define-t kaptam megoldásnak, de az nekem nem minden esetben a "legszebb megoldás".
Most jutott eszembe egy lehetőség ami működik C,C++-ban is és úgy akartam megcsinálni, hogy ne történjen akkora hatásfok csökkenés. És igazság szerint egy PIC32-vel működik csak a CLR, SET, INV regiszterek miatt. O3-ban nincs különbség LATGINV = _LATG_LATG12_MASK és LAT_INV(RG12) között 25-25MHz-el kapcsolgatja a lábat. O0-ban az első 20MHz-el a második 15MHz-el itt már csökken a hatásfok, de O0-ban még elfogadható szerintem (és ha jól emlékszem 200MHz-en megy a PIC).
Még csak vázlat, mert nincs benne minden regiszter meg, ha elkészül lehet felrakok egy header file-t aminek csak kell a pic header-je vagy az xc.h és #ifdef-el nézni fogja melyik láb mask-ja van definálva és csak azt fogja létrehozni.

És egy példa a használatra


Mi a véleményetek? Szerintem ennek C-ben is haszna lehet.

Néhány pontosítás:

Már (jó néhány verzióval a kezdeti után) működik a programmer-to-go a PICkit3 -on.


Szinte minden héten más programozási algoritmust jelentet meg a gyártó. Ld. az SPI alapú 16F, és 18FxxK4x, hogy a PICkit3 -nak kényelmesebb legyen.

IDE kérdés:
32: Más IDE -t is lehet használni: Pl. Eclipse --- GDB interface utility for MIPS processors, including PIC32
18F: DBG18F
16F: ismert az ICD2 működése.

Nekem személy szerint a szokásos megoldás is tökéletesen megfelel. Illetve aki PIC32-re fejleszt, felejtse el az arduino-t mert a kettő nagyon-nagyon messze van egymástól. Az arduino egy játékszer és erőforrás pocsékoló, csak annyit tanulsz vele hogy körülbelül hogy működhet egy egyszerűbb mikrokontroller, többet nem, mert a többi ctrl c és ctrl v.

Sose használtam arduino-t csak a suliban elég sok embernek kellet még abban is segítsek így ismerem és láttam jó pár source-t belőle és valóban eléggé erőforrás pazarló. Azt is tudtam, hogy biztos, hogy nem az igazi, ez a pl digitalWrite, de tetszet, hogy hordozható egy láb, és nem mint ahogy eddig csináltam én is egy global define-ba leírni (persze ez is hasznos egy helyen van minden).

De ez a "High Level" I/O dir, level, pull-up... módosító más gyártónál is megvan.
De én személy szerint 200MHz-is sajnálok ilyen fv.-eket használni, mert ha mondjuk 320x240 pixelt rajzolok ki, akkor az elején egy CS_L a végén egy CS_H töredék, de akkor is több idő lenne.
Ezért nem használom már REGISTERXbits.BITY mert az 5 sorra fordul REISTERSET/CLR (asszem) 2 sorra.

Persze ahol nem időkritikus a működés kényelmes a high level, de ez a kis apróság szerintem a high és a low között táncol.

Láttatok már megoldást fájlok listázására TFT kijelzőn? Maga a listázás megy, nem ezzel van a gondom, hanem a névsorba rendezéssel. Azon belül nem magával a sorba rendezés algoritmussal, csak majdnem.
Elvi gondom van azzal, hogy hogyan lehet sorba rendezni egy kis memóriával rendelkező PIC-el sok elemet tartalmazó könyvtár neveit. FAT32-ben nagyon sok könyvtár és fájl lehet egy mappán belül. Ha sorba szeretném rendelni őket két lehetőség jut eszembe. Egyik, hogy mindet kiolvasom kétdimenzós char tömbökbe, majd sorba rendezem őket a listázáshoz, esetleg létrehozok egy másik tömböt, amibe a sorrendet tárolom le és ez szerint listáztatom. Lényeg, hogy minden mappa és fájl nevét tárolnom kell. Ez gyors lehetne...
A másik, hogy kiolvasgatom az összes bejegyzést és minden kiolvasáskor kiválasztom a névsorba illőt és megjelenítem. Ez viszont baromi lassú a folytonos kiolvasások miatt(pl. SPI SD elég lassú kommunikáció) és egyébként is valahogy azt is követni kellene, hogy melyikek voltak már megjelenítve egy tömbbe, ami megint erőforrás igényes.
Tudtok valami bevállt megoldást esetleg?

Egy jo tanacs: ha makrot csinalsz, akkor mindig zarojelezd be az egeszet, ha barmilyen operator szerepel benne. Ebben az esetben nincs jelentosege, de maskor van. Jobb ezt megszokni. Egy kerdes: miert cast-olod ide-oda a pin.reg valtozot? A pointerbol is le tudsz vonni, hozza tudsz adni. Csak tudni kell, hogy, ha egy int pointerhez hozzaadsz egyet, akkor az valojaban kettovel vagy neggyel lesz tobb, hiszen egy int-nyit fog novekedni.

Lehet ezért nem ment cast nélkül (ha az int 32 bites) és én egy intptr-hez adok hozzá '1'-et akkor annak a címe 4-el növekszik? Jól értem?

Szerk.:
Miért ne annyival növekedne ezt jól benéztem, akkor az int byte-jain belül járkálnék.
Köszi, hogy szóltál.

A jelek szerint te nagyon szeretsz belefutni a pic32mz korlátaiba Előzőleg a grafikus kijelzővel kaptad el a problémát, hogy jobb lenne nagy adag cache ram, most meg a filesystemmel futottál bele ugyan abba.

Ha van esetleg rálátásod, mekkora lehet az általános igény dinamikus memóriára pic kategóriás mikrovezérlőkhöz (például 128 megabit kapacitás egy dip-6-os tokban), bármilyen meglátásodnak örülnék a kérdésben, ugyanis annak a témának a marketing problémáival is foglalkozom

Oké, de ez a probléma nem csak PIC-nél lép fel, hanem PC-n is. Kérdés, hol húzzuk meg a határt. Az NTFS ben 4 milliárd fájl lehet akár egy mappa alatt is. Ezt PC-n sem túl egyszerű kezelni, sok fájlkezelő meg se jelenít 30ezernél többet. A FAT32 esetében 65536 a max. ami PIC léptékben már sok, főleg, ha az nem 32MZ! Nem nagyon láttam ilyen megoldásokat, ezért kérdem, hogy ezt hogy szokták megoldani? Lehet azt mondani, hogy ezer és idomuljon a felhasználó? Persze lehet több fájl, csak azokat már nem tudja névsorba rendezni. A SYS_FS_DirRead() függvény sorban kiolvassa a fájlokat, azok létrehozásának sorrendjében, aminek nem a dátum az alapja, hanem a bejegyzés sorrendje. Még nem néztem meg, de valószínű, hogy az itt felhasznált index 16bites egész. Már az 128k-ba kerülne, ha csak a sorrendet kellene letárolni egész számonként...

PC-n úgy oldják meg, hogy a filesystem beolvassa a teljes mappát, és indexelve kezdi el feljegyezni belőle a tételeket. Azután megjeleníti. Ha megnyitsz egy intézőt, az riasztást kér az aktív mappát érintő változásokra, és azt a windows tudja, hogy most olyan szektorhoz volt írási hozzáférés, ami ahhoz a könyvtárhoz tartozik, ergo megy ki a riasztás mindegyik alkalmazásnak. Nem ördöngösség, ha van elég memóriád mindenfélét feljegyezni. Nem ész kell hozzá, hanem hardware

Fat 32 esetén hol találtál olyat, hogy egy könyvtár nem tartalmazhat több bejegyzést, mint 64k? Ugyanis képtelenség vfat alatt bármiféle korlátot meghúzni. A vfat mappák tipikusan olyanok, hogy szinte minden file szemét bennük marad, ami valaha bennük volt, ergo csak híznak és híznak. Egykori szerkezeti gyengeség a hosszú file nevek támogatása miatt. Pontosan ugyan az a probléma, mint ami miatt a 286-os időkben szabdalódott használhatatlanra a memória, ha valamelyik program dinamikusan foglalt / szabadított fel memória területeket (lásd c++ csak a 386-os időkben kezdett el terjedni, amikor már voltak vcpi és dpmi driverek is ems-t supportolni). De a maximális méretük nem különbözik a file-ok korlátjától (4 giga). Egy fat32-n a könyvtár file tipikusan addig hízik, míg az OS észre nem veszi, hogy már olyan törölt bejegyzések is vannak benne, amiknek a bejegyzett adatterületük is másik file-hoz tartozik (be-cache-eli mindegyik könyvtárat + a teljes fat-ot is, és tudja, mert real-time nyilvántartja), és akkor újraírja a teljes könyvtárat (azt a felesleget végleg kitörli belőle). De addig minden benne marad. Anno nem volt ritkaság a megabyte méretű könyvtár file sem, és az ráadásul azokban az időkben, amikor a teljes HDD kapacitások is csak 850 megabyte körül ingadoztak.

Igen, a pointerek eseteben az "egyseg" az annyi, amekkora a megcimzett tipus. Ha van egy 24 byte-os strukturad, akkor annak a pointere 24-gyel fog novekedni, ha leirod, hogy p++. Ha ket pointert kivonsz egymasbol, akkor az eredmeny is az elemek szamat fogja megadni, nem pedig a fizikai cimek kozotti kulonbseget. Ebbol adodik az is, hogy csak azonos tipusra mutato pointereket lehet egymasbol kivonni. Pointerekkel semmi mas matematikai muveletet nem lehet vegezni.

Semelyik FAT32 -n nem sikerült még 32000 + egynéhányszáz állománynál többet létrehoznom.

Nem a PC megvalósítást keresem, nyílván a memória megold mindent, bár 4 milliárd sztring, ami lehet 256 hosszú is, szerintem igencsak érdekes dolgokat művelne az oprendszerrel!

Engem a korlátos memóriával rendelkező eszközöknél szokásos megoldások érdekelnének. Van-e valamilyen dinamikus megoldás, vagy milyen korlátozások a szokásosak? Mert, hogy korlátozásokra szükség van, az szinte biztos.

Nem tudom hol találtam, de ezt találtam: