Van azon a pic-en function unlock? Ha igen, az adatlapon a special functions résznél találsz róla említést.

Persze! Anélkül egy pic-en sem megy a flash, de még az eeprom írás sem...!

Melyik a legolcsóbb ferrit magos pici trafó, amit boltokban / akárhol fellelni tudtál? Valahol 1 MHz körül kellene csatolnom vele impulzus üzemben (áramlöket, nem színusz). Tömeggyártott cuccra lennék kíváncsi. Kínában az rj45-ös csati trafó pld 1 darabosan is csak 2 usd-ben van, és az már az ellenőrzött minőség. Van annál olcsóbb cucc?

Például: PE-65612NL

En nem trafot vettem, hanem ferritgyurut. De ez mar 10-12 eve volt. Tomeggyartashoz tenyleg jobb a gyari impulzustrafo vagy valami MagJack. Arakat nem tudok, legalabbis nem az olcso kategoriaban.

Kellene még valami nyers logikai sebesség is meghajtani az impulzus adó-vevőt. Van valakinek saját tapasztalata CLC-s pic-ekkel? Pld: PIC16F15313

Melyik típusról van szó?

dsPIC33EP32GS504

Azóta átnyálaztam még egy pár microchipes és egyéb forráskódot..., de érdekes módon szinte mindenütt csak a 2 utasításos írás módon használják, a 64-esről csak elvétve találni valamit is.
A már említett közvetlen memóriásból való írás, valamint ez a két utasításos mód hibátlanul megy is, ám a latch-ba írt 64 utasításos mód mint ha nem is létezne benne Kipróbáltam már minden létező verzióban, de csak nem akar úgy írni! Pedig az errátában sincs ennek semmi nyoma...
Vicces, hogy számtalan programban láttam annyiféle elírást, vagy hibásnak tűnő koncepciót, hogy csoda hogy nekik az állítólag működött... Bár ahogy írtam, a 90%-a csak a kétutasításos módot használta...ami működik is...

Sziasztok!
Szeretném egy PIC18f4520 pic AN0 portját váltogatva használni, hol digitális, hol analóg bemenetként.
Az adatlapot nézve, ha jól értelmezem, ezt az ADCON0 és az ADCON1 regiszterek bitjein keresztül lehet megoldani. Az ADCON0 regiszter CHS bitjeivel kell beállítani az analóg csatornát, pl. ha ez "0000" az AN0 csatorna lesz analóg csatorna. Emellett az ADON bit 1-be állítása engedélyezi a konvertálást és a GO/DONE bit 1-be állítása indítja a konverziót. Az ADCON1 regiszterrel lehet beállítani a portok analóg vagy digitális bemenetként való használatát. Ha a PCFG bitek "1111", akkor a portok digitális csatornák ha "1110" akkor az AN0 analóg.
Ha valamit nem jól értelmezek, javítsatok ki, ha pedig valamit kihagytam írjátok meg. Köszi.

Megtáltosodott az ICD4! Vettem egy új laptopot, új az oprendszer (Win10) és feltettem a legújabb MPLABX-et (4.05) is, nem tudom hogy melyik okozta a változást de a korábbi hibaüzenetek megszűntek. Nem csak hogy az ICD4 felismerése és a programozás, de még a debuggolás is hibaüzenetek és újraindítgatások nélkül működik, tökéletesen! Eddig négy debugger indításból háromszor valami hibaüzenetet dobott és nem indult el. Most órákig debuggoltam folyamatosan, töréspontokkal, átugrasztgattam a programszámlálót ide-oda, resetelgettem a PIC-et, újra és újra elindítottam a debuggert csomószor, de egyetlen hibaüzenetet sem dob. Szuper!
Mondjuk a 85000Ft-os árát azért még mindig nem éri meg szerintem (ennyi pénzért RJ45->ICSP kábel és 9V-os DC adapter igazán járhatna hozzá), de így már végre tökéletesen használható. És piszok gyors! Ha valaki nem sajnálja rá a pénzt akkor csak ajánlani tudom, a debuggolás egy álom vele.

Azt tudom, hogy High speed sebesség miatt gyorsabb, de ezt leszámítva, mi az ami miatt megér akár csak pár ezer ft ráadást egy pickit3-hoz képest ?

Ha valaki a hét minden napján napi 8 órát debuggol mondjuk annak. De gondolom annak futja is vagy a munaadója megveszi.
Nem hobbi árkategória.

Mert sokkal gyorsabb! PICkit3-nál egy komolyabb programnál debuggoláskor egy töréspontnál való megállás, a program soronkénti léptetése és minden léptetés után a változók beolvasása 3-4 másodperc. Néhány sor átléptetése így nagyon sok ideig tart. ICD4-el a léptetés azonnali, majdnem olyan gyors mintha szimulátorban történne! A hibavadászatot ez óriási mértékben megkönnyíti és meggyorsítja. Gyakorlatilag ahogy rányomok a debugger gombjaira, abban a pillanatban végre is hajtódik a léptetés, és a változókat is azonnal betölti.
A másik, hogy most hogy megtáltosodott az ICD4, így gyakorlatilag már megbízhatóbb a működése a PICkit3-nál. Nem kell néha ki-be dugdosni meg újrakapcsolódnia a programozóhoz.

Szia!

Próbáltad ezen a megtáltosodott gépen a PICKit3-at is? Lehet, hogy az is jobb tempót tud már, mint előtte...

Érdekes, nekem semmi bajom nincs a Pickit3-al. Most fejlesztek egy programot, kb. 30k a beégetett program (20e sor), teljesen asm.-ben, MPLAB 8.93-al, 18F87K22-vel. A Pickittel deuggolva a léptetés azonnali, ahogy nyomkodom az F8-at, azonnal megjelennek a változó értékek, amelyől a watch ablakan kb. 80db van beállítva.
Még soha nem kellett ki-be dugdosnom, mert valami probléma lett volna vele. Most az ünnepek alatt volt, hogy 2 napig folyamatosan debug módban futtatam a programot tesztelve, hogy ráfut-e a töréspontra. Semmi gondom nem volt vele.
Lehet, hogy 16 vagy 32bits procikra nem jó, de 18F-es procikkal még soha nem volt vele gondom.
Nekem egyetlen gondom van vele, hogy 3-nál több töréspont nem állítható be egyszerre.

Szia!


Ez azért C-ben más, ott egy utasítás nem egy asm sort jelent, így nyilván lassabb a működése is ( persze ott is belenézhetek az asm utasításokba és ott már tényleg gyors, de akkor pont elveszne a C előnye, ha értelmezni kellene hozzá az asm sorokat ( elég, akkor, ha valamit nem jól csinál ! )!
Most ne nyissunk vitát a C mellett és ellene, csak azért írtam, mert a Attila86 fejlesztési területén ennek simán lehet létjogosultsága!

Eszembe sem juttot vitát indítani.
Azon viszont egy debugger sem fog gyorsítani, hogy egy C függvény mögött az asm kódsor milyen gyorsan fut le az adott vezérlőn, ugynais az adott.

Én 16 bites PIC-eket programozok, jellemzően dsPIC33E sorozatúakat. De korábban 18F-eket programoztam, azok valóban lényegesen gyorsabban debuggolhatóak PICkit3-al is, és ott nálam sem kellett ki-be dugdosni. A 16 bitesek PICkit3-al már nem olyan szép világ sajnos.
Másrészt a Watch ablakban nálam kB-nyi, sokszor több tíz kB-nyi változót jelenítek meg. (UART vételi tömbbök, struktúra-FIFO-k, gyűrűs bufferek stb.)
És valóban, a maximum 3db töréspont sokszor kevés tud lenni. ICD4-nél annyit töréspontot használok amennyit akarok. Mondjuk lehet hogy ez az ICD3-nál is így van, nem tudom.

Idézet:
„Azon viszont egy debugger sem fog gyorsítani, hogy egy C függvény mögött az asm kódsor milyen gyorsan fut le az adott vezérlőn, ugynais az adott.”

Azon nem, de azon, hogy milyen gyorsan olvassa ki az adott töréspontnál a memória értékeit, azt milyen szervezésben teszi a feldolgozáshoz /pl. mennyi memóriát foglal le a debuggoláshoz! /és ezt milyen buszon keresztül, milyen protokollal olvassa be, abban már lehetnek eltérések és ezáltal sebességbeli különbségek !

Mindenkinek szól a PICKit3 ICD3/4 témában.
Tapasztalatom szerint:
Mind a kettőnek megvan a helye és van az az idő amikor már a 80.000 Ft megéri (vagy mint usane mondja a munkaadó megveszi, nálam is ez volt a helyzet az ICD3-mal).

Ha nem 8 biten gondolkodik az ember ahol 256kB-nál megáll a flash, hanem 16 vagy 32 bitben ahol már 1MB vagy 2MB a határ azért ott már igen nagy differenciák vannak, ha az ember felhasználja az egész flash-t (én grafikánál belső memóriába pakoltam a képeket).

Debug: a (mint ahogy Attila86 is írta) sokkal több idő kell a PICkit3-nak hogy megálljon, betöltse a watch-t, nincs runtime breakpoint ami nem hangzik egy nagy dolognak, de egyszer kipróbálja az ember és utána mindig megállítani a programot breakpoint újraindít őrület...

A másik dolog az árkülönbözethez míg a PICkit3-ban van egy 16 bites PIC és ennyi addig az ICD3-ban van egy HS USB, paralell RAM, FPGA, 16 bites PIC (ICD4-ben 32 bites) azért így már elfogadhatóbb az ára szerintem.

De egyébként, ha kicsit ARM tájékon körbenéz az ember a SEGGER-nél akkor látszik, hogy itt sem olcsóbbak a programozók, debuggerek.

Egyetértek.
Ám a hobbisták nem sűrűn nyúlnak ARM-hez sem.
PIC meg arduino és kész.
Csendesen jegyzem meg én az ottthoni PICkitemet is a főnökömmel vetettem meg

Szerintem meg a kis stm32f103 board a 2 dollár körüli árával, a hozzá passzoló programozó/debugger (stlink v2) szintén 2 dollárért, az ingyenes C fordítók és fejlesztő eszközök (eclipse, gcc cubemx stb.) bőven belefér a hobby kategóriába.

Értem! Azért az érdekes, hogy előre szóltam, nem a megnövelt sebesség miatti különbség érdekel, mégis legfőbb érvként, ha nem egyetlenként ez hangzott el

Én használtam pickit 2, 3-at, valamint icd3, 2-t...utóbbit magam is terveztem meg...így van némi hasonlítási alapom. Tény, hogy sebességben jóval gyorsabb, de amennyivel drágább...hát...nem otthonra való szerintem. Az icd3 ugyanazt a sebességet tudja...bár az sem volt korábban sokkal olcsóbb, tény...

Itt lapul a fiókomban a komplett szett..., de még nem vettem elő eddig, nincs rá időm.
Arra azért kíváncsi lennék, ez így mennyire gyors környezet, hiszen itt a legfőbb ellenérv a relatíve olcsó pickit3-al szemben a sebesség. Ez a kombó mennyire gyors debug módban, mondjuk legalább néhány tucat változó figyelésénél ?

Arra azért kíváncsi lennék, mi a túrónak oda az az fpga ??! Kissé ágyúval verébre kategóriának látom ezt..., persze valamivel meg kéne indokolni a magas árat!

Nem tudom én se pontosan, bár ha gondolod nekem meg van az ICD3 kapcsolás rajza, de én már láttam SEGGER-es JLink PRO-t szétszedve és ott is van FPGA tehát nem gondolnám, hogy véletlen van ott (bár a jlink trace funkciót is ellát már ha jól emlékszem).

Én amennyire ki tudtam szedni a kapcsolás rajzból az FPGA kezeli a 2x4Mb(it)-es RAM-ot.
De felrakom a kapcsolást is, már nem tudom honnan szedtem le, de a pdf megvan.
És azért ha megnézed nem csak azért fizetsz mert FPGA van benne az MCLR és a VDD otpo FET-el le van választva, LTC1696 és stb...

Van benne egy csomó dolog amit nem is gondolsz, hogy benne vannak, de sokkal jobban védik a gépet és a debuggert esetleges nem oda kellő dolgok ellen mint a PICkit3.

Ne haragudj, valóban.
A sebesség mellett más érv nem nagyon szól az ICD4 mellett, nyilván. Azt próbáltam ecsetelni hogy a nagyobb sebesség nem önmagában azért jó mert hamarabb beégeti a hex-et, hanem mert a fejlesztési folyamat sokkal gördülékenyebben megy, sokkal inkább úgy érzi az ember hogy dolgozik és most megalkot valamit, nem pedig sz*pik egész nap azzal a sz*rral.
A sebességen felül a robosztus és kimondottan szép szálcsiszolt fém dobozt, a tíz lépésben állítható fényerejű RGB LED-csíkokat és a PGD/PGC lábakra opcionálisan bekapcsolható (és beállítható értékű) le és felhúzóllenállásokat tudnám csak felhozni. Ezek a sebesség mellett persze kb említésre sem méltóak.

Ritkán szoktam használni a debug funkciót (inkább a printf -> soros port -> terminál kombót szoktam előnyben részesíteni, mert a perifériákat nem mindig lehet megállítani), de amikor használom akkor a "nem is gyors, de nem is túl lassú" amit tapasztalok.
Amúgy itt egy videó róla, ítéld meg.

Mondjuk, az tény, hogy egy nagy program esetén számottevő idő lehet maga a letöltés is, ami nem kevésbé idegesítő tud lenni!
Ohh...én még nem láttam fizikailag hogy néz ki, ezek szerint szakítottak a macisajt dobozzal ?