A PIC-nek a PGED és PGEC lábai most 1-1db soros 100Ohm-al vannak az ICSP programozó csatira kötve. A két programozó láb azonban egyben a SOSCI és a SOSCO lábak is, és szeretnék rákötni ezekre egy 32,768kHz-es kvarcot. Fogom tudni utána programozni és debuggolni a PIC-et? Kipróbálnám, de most nincs rá lehetőségem.

Hali!
Ha nem lehet kipróbálni, de már nyákot kell tervezni, akkor tervezz be a egy soros jumpert a kvarccal, amit keskeny fólia alaphelyzetben áthidal. Ha mégsem működik akkor fólia elvág, programoz, jumper rádug, vagy ónpötty. Vagy csak két közeli forrpötty, amire a végén ónpötty.
Olimex is csinálja az utóbbit az utólagos konfiguráláshoz

Korrigálnom kell a találgatásokat egy, az Atmel fejlesztésről AVR fórumra beírt post alapján. Marad mindkét IDE és jönnek a PIC Cortex-ek. Ezek után érdekes lesz a mostani PIC32 jövője.

MC-ék árulnak szolgáltatást előre programozásra, és már égetve szállítják. Akkor sosem kell neked programoznod. Üzleti célra az van. Kitesztelni meg jumperezés, de akár mikrokapcsoló, simán csak átkapcsolod, nem kellenek soros ellenállások. Vagy ónpöttyözhetsz is, én azt részemről nem szeretem. Miféle filléreskedés már még egy jumpert is sajnálni egy prototípusra?

Kíváncsiság gyanánt, melyik az a pic?

Kíváncsi leszek, ha jön a Cortex PIC-re hogyan lesz a register szerkezet, mert ARM-on másabb az elgondolás mint MIPS-el, meg ha m3/m4-et kap akkor lesz bit-band is.

Rákerestem az egyetlen MPLAB X 4.0-ban elérhető PIC32C-re Bővebben: Link teljesen más doksi az eddigiekhez képest.

A kontroller minden PGEC - PGED lábpárral programozható, a nyomkövetés azon a páron megy, amit a konfigurációs szóban kiválasztottál.

dsPIC33EP512MU810

Majdnem. dsPIC33EP512GP806.

Értem én hogy mely lábak valóak a programozásra és a debuggolásra, a kérdés az hogy ez (a programozás és a debuggolás) akkor is lehetséges-e, ha a PGED és a PGEC lábakon rajta van egy 32,768kHz-es kvarc.

Nem sajnálom a jumpert, de ha már jumper akkor sokkal egyszerűbb ha nem ültetem be a kvarcot, nem?!

Az előre programozás jó dolog, de ilyesmire egyenlőre sajnos még nincs szükségem.

Szerintem nem fog menni a quartz -cal és a 22pF -kel. De a másik párosokon lehetséges lenne.
Próbáld ki egy DIP tokos dsPIC33EP -vel.

Elvileg nem kellenek kondik a kvarchoz:

Kipróbáltam pic24ep512gp806-on úgy, ahogy írtad (ICSP és 32768Hz kvarc egyszerre a 47,48-as lábakon). Ha csatlakoztatom a programozót (pickit3), akkor megáll a kvarc, és a programozás is sikertelen. (Kellett kondi a kvarcra, nélküle instabil volt.)

Köszönöm hogy kipróbáltad!
Akkor lesznek kondik és ezek a kvarccal együtt, a PIC felprogramozása után lesznek beültetve. Csak a szoftverfrissítés elég nehézkes lesz.

Bootloader?

Nem baj az sem, ha sajnálod a jumpert, de ha arra a lábra kellenek neked a kvarcok, amelyikeken programozni is akarod (elég furcsak annyira kihasználni pont azt a pic-et, de ha pont úgy alakult, hát pont úgy alakult), akkor a tapasztalatok szerint (@ndavid87 kipróbálta) jobb lenne nem összeütközniük funkcionalitásban, és ahhoz a tuti biztos lehetőségeid: mikrokapcsoló, jumper, ónpötty.

Nincs mit.
Arra figyelj, hogy ha már engedélyezted a másodlagos oszcillátort, akkor az reset után is engedélyezve marad. Ilyenkor nem fog működni a programozás ezen a PGEC, PGED pároson még akkor sem, ha a kvarc le van választva róla!
Áramtalanítani kell a mikrovezérlőt, és még azelőtt kell megkezdődnie a programozásnak, mielőtt a program engedélyezné a másodlagos oszcillátort.
(Ha ez a program elején van (bármi késleltetés nélkül), akkor végrehajtódik mielőtt a pic belépne programozás módba, és a programozó már nem fog tudni kommunikálni vele.)

A reset láb lehúzása bármikor resetbe kényszeríti a picet, és az alapiniteli a programozást.

De az OSCCON regiszter reset után nem áll alaphelyzetbe. Szóval elég, ha egyetlen egyszer elfut odáig a program, engedélyezi a másodlagos oszcillátort, és a kommunikáció ezen a két lábon a programozóval már nem fog működni.
Szóval a programozó először áramot ad a mikrovezérlőnek, és csak utána piszkálja az mclr lábat. Ha az engedélyezés a program elején van, akkor a pic végrehajtja azt még mielőtt a programozó eljut odáig, hogy "initeli" a programozást (vagy akármi mást).

Ilyenkor segít a Vpp First funkció.

Csak az a baj, hogy a dsPIC33EP -ken nincs Vpp first mód.

A PGED1 (27)(DB7) - PGED1 (26)(DB6) valamint a PGED3 (24)(DB1) - PGED3 (24)(DB0) szóba jöhetne, hiszen ide csak a két TFT csatlakozó és az LCD modul csatlakozik.

Feltételezem hogy azt gondolod hogy a fejlesztőpanelemre akarok kvarcot tenni, mert azon a panelomon van két TFT megy LCD csatlakozó és a lábszámok is amiket írsz, ahhoz stimmelnek.
De nem, ez egy teljesen más panel. Fentebb írtam is hogy ebben dsPIC33EP512GP806 van, ez az immobilizer/nyomkövető elektronikám: Bővebben: Link
Ennél sajnos nem tudom áttenni a programozólábakat a másik két PGED-PGEC párosra mert nagyon sűrű a nyák, illetve azoknak a lábaknak funkcióik is vannak. Az ICSP-s PGED és PGEC lábak azért is lennének előnyösek mert azok még szabadok (a programozást leszámítva). Mellékeltem egy képet amin látszik hogy milyen sűrű a vezetékezés a PIC körül.
Végül arra jutottam, hogy rátervezem a panelra a kvarcot meg a kondikat hogy a helyük meglegyen, de beültetve csak a végleges szoftver beégetése után lesznek. Addig megy szoftveres RTCC-vel az elsődleges órajelről, és a netről folyamatosan szinkronizálva. (Most is így megy.) Vagy legfeljebb sosem ültetem be őket.

Ez a másodlagos oszcillátoros mizéria azért elég meredek! Egyszer beleégetek egy kvázi "rossz" programot a PIC-be és onnantól kuka...

Legalább egyikünk nem érti

Kipróbálni sajnos most nem tudom, de szerintem ha az nMCLR-t lehúzom alacsonyba, akkor a pic statikusan resetbe kerül, ami a programozói gépezetet initeli. Akkor is, ha előtte akármi futott le. Semmit sem számít, mi futott le előtte. Semmit sem számít, mi van a configban. A kvarc beállítása sem számít semmit. Abban az állapotban a pic a saját belső rc oszcillátorát használja.

Nem kuka, mert a többi programozó lábon attól még elérhető, persze ha azok nem hozzáférhetőek akkor igen, de csak egy törlésig kell hozzáférni valamely más lábhoz, utána megy az oszcillátorosról is. Nem egy kész cuccba kell betenni a fejlesztés alatt álló PIC-et és akkor nincs gond.

Meg lehet próbálni egy olyan programágat, ami kikapcsolja az oszcillátort?

Én kipróbáltam, és azt írtam le amit tapasztaltam.
Ha arra a két lábra volt kötve a programozó, és a pic már átkapcsolta azokat oszcillátor módba sem a programozás, sem a programmemória törlés vagy ellenőrzés nem működött.
Másik PGEC-PGED párokon továbbra is ment minden.

A tesztprogramban a másodlagos oszcillátor timer1-et hajtotta, ami egy másodpercenként generált egy megszakítást. Ilyenkor a pic uarton kiküldött egy karaktert. Amikor lekötöttem a kvarcot, és a helyére kötöttem a programozót, akkor - ahogy a programozó próbálta programozni a mikrovezérlőt - több megszakítás is történt, de maga a programozási folyamat mindig hibára futott.
Én úgy gondolom, hogy ilyenkor a oszcillátor áramkör megzavarja a kommunikációt a pic és a programozó között. Hiába kapcsol át a pic programozás módba, nem fognak szót érteni egymással ha az adatvezetékeket valami más is vezérli.
Természetesen elfogadom, ha van erre más értelmes magyarázat.

Nincen, ez tökéletes magyarázat. A programozó lábakon az adatfolyam érzékeny. Én próbáltam már összeragasztottam 2 PIC32-es dimmert és egy műanyag kötődobozba raktam, kivezettem mindkét dimmer programozó lábait, ha módosítani kellene valamit rajta akkor csak rá kelljen dugni, ne kiszedni a beépített helyéről. Már 10-cm 5 eres lyczy-n sem működött a programozás a sok egymás melletti drót miatt.

Úgy néz ki hogy a jövő héten ki tudok próbálni egy ICD4-et, ha tényleg jó, gyors és megbízható akkor pedig lehet hogy veszek is egyet. Van esetleg kérdés, megnézzek rajta valamit nektek?

Gondolom nincs nálad 32 bites PIC mert nálam az ICD3 a 32MX-el megáll a BP (breakpoint)-nél majd run-ra megyek és nem megy tovább hanem ráugrik újra a BP-re.
A másik 32MZ-vel meg ha debug-ba vagyok akkor nem engedi az átírt kódot újra debugolni csak ha megállítom (jó ez nem olyan idegesítő, de azért na). Az elején nem volt asszem ilyen probléma, próbáltam driverezni is régebbi MPLAB -et vissza dobni, de nem segített.

1. ha esetleg van lehetőséged ezt leellenőrizni, hogy ez az ICD4 orvosolta-e az jó lenne
2. A sebesség az szerintem lényeges kérdés, állítólag állítható is lett
3. Ha tudod hosszabban nyúzni ugyanúgy összefossa magát mint a PK3/ICD3 és connection failed/endpoint hiba van vagy ez is megszűnt végre?
4. és erről nem láttam leírást esetleg még mindig köti a hw BP-t vagy engedi a végtelen BP-t