Ehhez kellene.http://www.iq-technologies.net/projects/mcu/013/index.html" target="_blank" rel="nofollow" >Bővebben: http://www.iq-technologies.net/projects/mcu/013/index.html

Igen, nem igazán találtam semmilyen érdemi információt (rajz, firmware) róla.

Szia!
Itt megtalálod a kapcsolási rajzot...Bővebben: Link !

Kapcsolási rajza a User`s Guide -ban. Mivel sok PICkit3 bolondult meg a sok-sok firmware csere közben, rengeteg eljárást lehet találni a bricked PICkit3 felélesztésére.
Bővebben: Link

Szörnyű gyanúd borzalmas bizonyossággá vált

Szia! A program beállitásainál kell valamit beállítaní,hogy jó legyen pic12f629 hez?

Nagy gondban vagyok... A programomban egy csomó helyen hívok meg olyan függvényeket melyek karakterláncot várnak bemeneti paraméterként (pl. sprintf(), strcat() stb...), és ezek jelentős részénél a függvény zárójelébe, aposztrófok közé írom a konstans szöveget amivel a függvénynek dolgoznia kell. Egy csomó ilyen van, és már nem fordul le a programom miattuk. A hibaüzenetek közül amit a fordító dob, szerintem ez a rész a releváns:

Ha kikommentezek néhány ilyen sort ahol ilyen konstansok vannak, akkor újra lefordul. De a programom fejlesztgetése még kb a felénél tart csak, még nagyon sok ilyen programsorra lenne szükségem!

Miért nem fordul le így a program, mi baja van? Rémlik valami hogy a 16 bites PIC-eknél van a programmemóriában egy kisebb rész amelyet el tud érni úgy mintha adatmemória lenne. Nem erről van itt szó, hogy próbálja erre a programmemória-részre tenni az ilyen konstansaimat csak már nem fér bele? Van egyébként néhány sima const char tömböm is, összesen 28924 bájtnyi méretben. Kipróbáltam hogy ezekből kikommentezem egy csomót, de ugyan úgy nem fordul le. Tehát a const tömbben lévő adatokat már nem erre a kis részre próbálja pakolni ezek szerint? Komolyan, const char tömbbbökbe kellene írogatnom ezeket a szövegeket amiket most az aposztrófok közé, és a sprintf()-nek és társainak a tömbbök címeit kellene átadnom? Úgy jó lenne? Mondjuk míg ezt leírtam ki is próbálhattam volna...
De miért akarja arra a területre pakolászni ezeket a fordító mindenképpen? Nem lehet megbeszélni vele hogy jó lesz az a sima programmemória-részen is? Vagy nem is ez a probléma oka?

dsPIC33EP512GP806, MPLABX és XC16.

Azt próbáltad -anélkül, hogy pontosan elemezgettem volna a dolgot részletesen, de nálam is szerintem hasonló volt a probléma lényege, mégpedig az, hogyha egy változót egy bizonyos méret fölöttinek deklarálok, akkor valamilyen hibaüzenet miatt nem fordult le-, viszont a neten kutakodva azt találtam, hogy a változót, ha így deklarálom, hogy pl :
int szamok[nagytomb]__attbibute__((far))
(ahelyett, hogy simán int szamok[nagytomb])

Akkor működik.. Legalábbis hasonló kontrolleren, mint amit te használsz, valami hasonló hibára ez megoldás volt...

A 16 bites pic-eknek még szegmens korlátaik voltak. Most nem néztem meg az adatlapját, hogy pontosan milyen porszem került a gépezet fogaskerekei közé. Lehet, hogy megkerülhető. De miért erőlködnél a kerülgetésével? Elérted a korlátot. Gondolkodtál már pic 32-esre áttérésen?

Kicsit off, de talán elfér ide.

Egy nagyon kicsi fogyasztású pic-et kellene használnom egyszerű impulzus számolásra, amit jó lenne leválasztott tápforrással üzemeltetni. Mint valami realtime clock, ami mellé akku van rakva.

Nézegettem akkukat árlistákban, melyiknek van adatlapja is hőmérséklet függést / önlemerülést és olyasmiket számolgatni, és nem találok olyat egyikről sem.

Ami kellene, az valami 3.6V névleges feszültségű akku, ami elbír legalább 2 hónapot 0.1 mA átlagfogyasztású (worst case) áramkörrel, kb 150 mAh. Ha egyben is léteznek akkuval szerelt 8 bites pic modulok / breakout-ok, az még jobb, de igazán nem ügy barkácsolni, ha megvannak hozzá az adatok. Aki futott már bele ilyesmibe, és átrágta magát rajta, valami tippnek örülnék, merre talált használható anyagot?

Én pl. elemet használtam: ER14505

A Maxim-nak vannak direkt ilyen RTC-i. Valamikor nézegettem az adatlapokat, de aztán meghíúsúlt egy hasonló projekt. Maxim: RTCs. Neked elméletileg az "Event Recorder" szűrő által mutatott eredmények a lényegesek. Ha ráérsz, böngészd át a kínálatot, hátha.

Szia!

Nem tudom ismered-e/használod-e/jó-e ehhez a pichez (mert persze a 8bitesekhez nem jó, én meg azzal szerettem volna kihasználni a benne rejlő lehetőségeket): elfviewer plugin mplab-x-hez.
Ezzel, ha minden igaz, megnézheted hova kerülnek a programod darabkái a vezérlőn. Talán segít majd megtalálnod a megoldást.

Na jó, lehet hogy tényleg ideje a 32 bitesekre váltani...
Hallott már itt valaki a PIC32MK családról? Egy ilyennel szemezek most, konkrétan a PIC32MK1024GPD64-el. Aggaszt egy kicsit, hogy ha az MPLABX-ben a projekt beállításainál átállítom a PIC típusát erre, akkor a PICkit3 mellett a kis lámpácska zöld helyett sárgára vált (meg a többi is). Nem tudná programozni/debuggolni, vagy mit jelent ez?

Amúgy egész jónak tűnik ez a PIC!

32-esek közül az mx795 a legutolsó "stabil" cucc - értsd: több lesz vele a sikerélmény, mint a lelki egészséged romlása a temérdek sok hiba miatt. Onnantól fölfelé nagyon sokkal rosszabb a statisztika. Sajnos az mx795-höz win7 kell, mert a régi fordítónak és mla-knak bajos volt a supportja linux alatt, és az újabb windowsokon is.

Megint egy fordító korlát. A DSRPAG regiszter tartalma programból változtatható, így nincs akadálya annak, hogy a program memóriában több 32k méretű részt használjunk PSV elérési móddal.
Emlékszel még a Microsoft C -beli string table recource struktúrára?

Az MX széria lábai nem PPS-elhetőek, így nálam nem jöhet szóba sajnos.

Szomorú vagyok... most csak emiatt lesz muszáj 32 bites PIC-re váltanom.

Én csak mikrovezérlőket programoztam mindig is.

Az a régi problémát idézte fel bennem a hiba, amibe belefutottál, amivel a régebbi windows -os fejlesztéseknél küzdöttünk. A program szövegben megadott karakter láncokat a fordító egy string szegmensbe helyezte. Amikor ez a terület betelt, jöttek a hibajelzések. A megkerülő megoldás a resource állományban külön string táblázatok létrehozása volt. A szövegekre az indexükkel lehetett hivatkozni.
A 24 bites PIC esetében a konstans karakter láncok default helye egy 32k -s rész a program memóriában, amit a PSV segítségével is olvashat a kontroller.
Ha ez betelt, a további láncokat a program memória más helyeire kellene tenni.

Az mx1-2-esek dip tokosak, kevés lábbal, azokon van pps. De miért olyan fontos az? Nincsen elég láb egy tq100-as mx795-ösön?

De nem teszi más helyre sajnos. Vagy be lehet ezt valahogyan állítani a fordítónak?

Azért fontos, mert használok két OC-t, 5db UART-ot, 1db SPI-t és 2db I2C-t, és a nyák szempontjából nagyon nem mindegy hogy ezek a PIC melyik lábaira vannak kötve.

A legnagyobb méretűtől kezdve használj helyettük program memóriában foglalat konstans karakterfüzéreket.

pic32mx170f256b - 24C32 EEPROM (ez utóbbi Atmel) kérdés.
Találtam a Microchip oldalán egy példa programot, ami az EEPROM doku alapján kiokoskodott javítással működőképes. Hiányzott belőle stop és start. Tudok írni és olvasni 1 bype-ot, de hiába küzdök több byte olvasásával. Ahogy látom a neten, ez másoknak is okozott gondot. Sajnos nem sikerült megoldást találnom. Van esetleg valaki, aki ez megoldotta? És ha igen, akkor hogyan?

Fixed DS1287

Egy külső, soros memória szóba jöhet a stringek tárolására?

Másik pic-el lehetséges használni azt az eepromot? Csak a megadott pic-nek vannak vele gondjai?

Ha jól értettem, multiplexer gondjaid vannak, amiből kispórolnád a multiplexert Mint említettem, a 32mx1-2 családok pdip tokos tagjaiban találsz pps-t.

Ezzel is lehet. Egy byte kiírása és visszaolvasása is megy. Csak több byte folyamatos olvasását nem sikerült összehozni, pedig elvben azt is lehet. Néztem az erratat, a magasabb számuakra van olyan hiba, hogy az SDA jel nem minden helyzetben OK, de az 1xx-es és 2xx-esekre csak egy cím van, amivel baj van.
A neten keresgélve ezzel sokaknak van baja, egyelőre azt feltételezem, hogy az állapot figyelés/írás/olvasás műveletek lehetnek rosszul összerakva. De már rengeteg módob próbálgattam.

Az egyik, ami hirtelen eszembe jut, hogy ugyan mi más van még azon az i2c buszon, amiért i2c kell neked és nem jó az spi?

A másik, hogy valami olyan fél fázisnyi eltérés van valahol a protokolban, ami az egyik pic erratájával még összefér, a másikéval már nem, és éppen abban a kommunikációs helyzetben jön elő.