A 10F200 ... 10F226 adatlapjából:

A 10F32x adatlapjából:

Oké, akkor azt benéztem, thx.

Sziasztok! Azzal a problémával fordulok hozzátok, hogy van egy kész PIC programom, csak aza baja, hogy 200 bekapcsolás után "lejár" a program és lehet újra égetni a PIC-re. Ez sajnos egy demo verzió. A kérdésem az lenne, hogy milyen címen kell keresni azt a funkciót, ami a bekapcs. számlálásért felelős? Mert ha megtalálom, tuti átírom 0-ra (végtelen)*

*Kapsz egy virtuális 1 est!

Ha haladó lennél, tudnád, hogy a hex kódot nem könnyű visszafejteni. (Nem csak a kérdésnek kell(ene) haladónak lennie ebben a topicban!) Másrészt miből gondolod, hogy segítünk feltörni egy programot? Ilyen dolgokat nem támogat a HE közösség!

Pic32-re lehet valahogy extrában rendszer órát kinyerni, vagy csak timer felhasnálás van? Valami rémlik egy automata számlálóról, amiről olvastam, de nem emlékszem rá biztosan, hogy az pic32 volt-e.

CP0, 9-es regiszter. Hogy erre van-e a Microchip standard könyvtáraiban valami felhasználás, vagy szabadon használható, azt nem tudom.
Makrók vannak az elérésére: cp0defs.h, _CP0_GET_COUNT, _CP0_SET_COUNT
A regiszter működése a PIC32 doksik közül a "CPU" szekcióban van.

Core timer

Köszönöm, a cp0 lesz az, amire emlékeztem. Megtaláltam a timer.h-t is, köszönöm azt a tippet is. Már csak egy aprócska kételyem van, amiről nem találtam infót. Nincs meg sem a headerben kommentben leírva, sem a sec.2 mcu doksiban. Remélhetem, hogy ha az a 9-es counter regiszter elérte a 4 gigát, automatikusan fog átfordulni? Van manuálisan kell leresetelni pld egy 4 gigára beállított timer interruptból? Erről ugyanis sajna egy szó nem esett sehol sem.

Úgy emlékszem, hogy átfordul.

Nézte már valaki mplab / mplabx alatt, hogy a pk3cmd.exe-nek merre vannak környezeti dolgai? Ki akarok nyiszálni egy programozó toolt az mplab-ok alól. Pk3 alatt valami olyasmi van, hogy firmware-t kell állítani minden eszközhöz. Az ilyesmit automatikusan csinálja, vagy előbb a pk3-at kell programoznom valamivel, mielőtt azzal a pic-et programozhatnám? Van erről valahol esetleg egy geek leírás?

Megint kínoz a C18 MPLAB-ban.
Komolyan mondom, én maradok az asm-nél.
A probléma az, hogy definiálom a program elején a port lábát, hogy tudjak rá hivatkozni (ne kelljen mindig írkálni hogy PORTBbits.akármi), de a fordító kiabál hogy syntax error.

.
.
.
Na és erre a sorra Syntax errort ír:


De ha ezt írom, akkor lefordul:


Szerk.: a manóba, a definíciónál nem kell a sor végére a pontosvessző!

Látom megoldódott, de ne keseredj el, nekem is fél évig tartott, mire megszoktam. Máig inkább asm módon programozok C-ben, alig használok gyári függvényeket, kivéve a számításokat. Könnyebb vele programozni, mint asm-al és nem sokkal nagyobb a kód, ha nem használsz printf, open, USART függvényeket és társait. Az open elhagyásával azt is tudni fogod, milyen bitet hová állítottál, közelebb maradsz a PIC hardverhez, hamarabb rájössz, ha valami nem működik, mert azért még mindig lesznek meglepetések...

Azon filozom, mi a ráktól olyan marha lassú a pickit3? Egy 2k-s programot miért tart fél percig feltölteni?

Na ez egy nagyon jó kérdés...

Lehetséges lenne, hogy minden felküldésre kerülő anyagot beéget előbb a saját flash szöcskéibe - kvázi 10k reprogram után lehet majd kukába dobni a pickit3-at?

Nem, ez ki van csukva. Nincs annyi flash benne, mint mondjuk egy 795f512-ben.
Nekem amúgy úgy tűnt, hogy az égetendő adat mennyiségéhez képest nagyon sok időt tölt egyéb dolgokkal (az adat mennyiségének növelésekor csak kicsit nőtt az égetési idő, kb. annyival, mint amennyi időre a LED jelzi a tevékenységét). Nekem van olyan készülékem, ami bekapcsolás után LCD háttérvilágítást kapcsol, ezen égetéskor szépen látszik, hogy mikor végez érdemi tevékenységet a programozó. Az a tapasztalat, hogy a nettó égetési idő arányos az égetett adattal (ezt is várnám), de előtte a hosszas várakozások, malmozások, azok függetlenek ettől. Mintha valami mesterséges lassítás, várakozás lenne beépítve (pont, mint a Windowsba...)

Ezt meg tudom erősíteni. Nálam a 300k-s program égetése kb. 1 perc. De az elején még 15 sec, míg connect-ol a PICKit3-hoz, és kiolvassa a device ID-t.

Miért vagy benne annyira biztos? Ha kicsit megpofozták az adat tárolási formátumot, simán bele lehet rakni egy 795f512-es programját + configját egészében mondjuk max 512k + 2-3k-ba utolsó cseppig. Nem törtem még szét ezt a gagyi made in china dobozt, hogy megnézzem, milyen spi flashek, meg melyik pic van a panelen, de ahogy google pajtás keresgélt nekem, azt mondják az okosok, 2x 256kbyte spi flash, és egy 256 kbyte-os pic van rajta. Bőven elég memória az még tömörítés nélkül is. De akár tömörítési algoritmus is beleférhet abba a pic programba, ha már túl sok dolga egyébként sincsen, mert a kapacitása nagyon megnőtt (+224k!), de a feature-ök mégis szegényesedtek. Mi került hát akkor abba a +224k-ba?

A PICKit3 adatlapjában ezt írják: "Extended EE program image space (512 Kbytes)"
Szóval erre kell neki a flash.

Olvasgassátok a PICKit2 és a PICKit3 scripting Tools forrását.... A külső EEProm -okat csak a ProgramToGo funkció használja.

Helló!
Aki használt már PIC32-ben RAM függvényeket (XC32-vel), az meg tudná mondani, hogy normális dolog-e, ha a felhasznált RAM mérete 1 bájttal sem lesz nagyobb, miután elé írom a __ramfunc__ és a __longramfunc__ attribútumokat a függvényeknek. Ami még furcsa, hogy a program semmivel nem lesz gyorsabb, pedig biztos, hogy emiatt a függvény miatt lassú.
Előre is köszi!

Sziasztok volna egy*

*Törölve. A he, ebben nem óhajt részt venni!

Ha van memory report a fordításról, esetleg ellenőrizd, nincs-e egyébként is memóriába rakva az a függvény. Lehet, hogy azért nincs változás. Nézd meg a kseg listákban, hova teszi a fordító. Ha megtaláltad, véss ide fel egy memo-t róla légyszi, mert hamarosan én is ilyesmivel fogok küszködni, bár én C32-vel fordítok.

Nem igazán vagyok képében az ilyen dolgokkal. Milyen kiterjesztésű fájlt kell keresni?

Adott egy rs232 program. A problema az, hogy bizonyos esetekben csak zavarjel van a vonalon es ez nemkivant megszakitasokat general. Az erdekelne milyen megoldasi lehetosegek vannak szoftveres oldalrol es hardveres oldalrol?

Le kell kezelni az időtúllépéseket, CRC-vel kell kezelni a bejövő csomag jóságát és a hardveres túlcsordulást(OERR) és frame hibát(FERR) is kezelni kell(pl. timer megszakításból).
A vételt megszakításból kell kezelni bájtonként, így egy bájt időtúllépését is meg lehet oldani(szintén egy timer megszakításan.) Nyugtázni kell a kapott csomagot a vételi állípottól függően és ki kell találni valami eljárást a hiba esetére(újraküldés n-szer, sikertelenség esetén jelzés a felhasználónak stb.)
A vezetékkel nem lehet mit tenni, az olyan amilyen (rs232 max 15m), esetleg a vonalvezetéssel lehet zavarmentesebb helyen vezetékelni. A sebességen lehet még lassítani...

Illetve lehet ezen felül még differenciális adatátvitelt (RS422/485) használni, árnyékolt csavartérpáras vezetéken (FTP/STP).

Abszolút!

Nem file-ban van. A linkernek kell külön paraméterként átadni egy "--report-mem"-et. Parancssorosnál ezt könnyű megtenni, mplab-nál nem tudom. Össze tudod úgy rakni a projectet, hogy egyetlen main.c-be legyen beincludeolva minden?

Hardveresen 3-ból 2 hibatűrés? D= a&b | b&c | c&a

Kiadod a jelet 3 külön vezetéken 3 külön meghajtással, a bemeneten pedig felhasználás előtt rászabadítod 3 és kapura meg egy vagy kapura, és annak a kimenetét értelmezed beérkező jelként.