És ilyen még a jól kiforrott C-vel is megtörténik!

Sziasztok?
Sikerült már valakinek a C32 -ben beállítania a UserID értékét forrásból? Egy 32MX210F106B -vel próbálkozom, ennél a típusnál a UserId a Config3H regiszterben van és van mellette még konfigurációs bit is. Sehogy sem megy. Ha az MpLab Config / UserId menüjében állítom be, a kovetkező fordítás visszaállítja 0xFF, 0xFF -re.

Mindegyik variáció fordítási hibát ad.

Nekem sem sikerült. Bármit írok a forráskódba, vagy panaszkodik rá, vagy nem történik semmi.

Ezzel a részével úgy általánosságban egyetértek.


Ezzel a résszel viszont nem. Szerintem ad annyi többletet, hogy érdemes legyen. Vannak tökéletesen hasznos, fordítási idejű dolgai, amik használata nem rontja a végeredményt, mégis előrébb van vele az ember. Aminek ára van, azt meg nem kötelező benne használni, és akkor semmivel nem lesz rosszabb, mint a C.
A teljesen statikus osztályok pl. egyértelműen jobb típusellenőrzést adnak, és a fordítási időn kívül semmibe nem kerülnek. Egyszeres öröklés esetén a dinamikus metódusok használata sem igazán drágább, mint ugyanezt a funkcionalitást függvény-pointerekkel megvalósítani.

Biztos, csak annál megfelelő választás esetén publikus a forrás is !
Steve

Ettől tartok én is. Meg így is marad, hiszen minden erővel a XC32 -t fejlesztik. Kénytelen leszek kézzel átírni a hex állományt, hogy tesztelni tudjam a módosított PICKit2 programot PIC32MX210F016B -vel.

Én aposztrófok nélkül próbálnám, így:

Bocs az előző értékadásom hülyeség volt. Nálam így lefordul:


(Nálam ez a legfeljlettebb PIC32, a PIC32MX210 ebben az ósdi MPLAB-ban még ismeretlen...)

C++ téren nem vagyok nagyon otthon, ezért elfogadom amit írsz.

Szia!

Melyiket használod? Az MpLab V8.88 már ismeri, a vele egy csomagban levő C32 -t próbálgatom.

Ahogy a mellékelt képen látszik, így nem ad hibát, de a UserID marad FFFF.

Ezen a gépen v8.66 van fenn...

Nemrég én is váltottam erről, nincs vele gond eddig, bár néha kifagy a szimuláció(nem áll meg a Break pontoknál) és csak a program újra indítása segít, de lehet, hogy ez gépfüggő is.

A #pragma CONFIG ... nem ad hibát, de más biteknél sincs hatása.
A #pragma config ... más biteket állít, a USERID = 1234 -re hibát ad:

A hex-ben benne van, de a PICKit2 nem ismeri, ezért abban nem jelenik meg. Hátha neked igen.

Szia!

Még így sem megy. Most csak a linker panaszkodik. A UserID pontosan azért kell, mert tesztelni szeretném a hex importot, az programozást, kiolvasást, stb. Azért vettem 32MX210F016B -t, mert a PIC32MX1__, PIC32MX2__ családot nem ismeri a PICKit2.
A PICit2 módosított programja kiolvasni, törölni már tudja... Programozni a PIC32Prog képes a PICKit2 -vel.

Azért azon az "Ethernet MII enabled" feliraton jóízűt kacagtam...

Nem én írtam a programot, de az legalább kezeli a 32MX1_ ill. 32MX2_ típusokat PICKit2 -vel.

Láttam az elkövető nevét is

De nekem olyan halvány emlékeim vannak, hogy a CONFIG regiszterek bitjei nem 100%-ban ugyanúgy vannak az 5xx/6xx/7xx és a 1xx/2xx családban. Mondjuk gondolom itt csak a felhasználó szórakoztatására dekódolja a biteket, érdemben a programozáshoz nem kell neki, hogy melyik bitnek mi az értelme.

Milyen gyorsan tud programozni?

Szia! Most 0xFEDC írtam az ID-be és a hex harmadik sorában ezt látom:
:040bf000dcfe00002
Nézd meg te is ott kell lennie! A PK2 valami miatt nem találja a hexben!

Szia!
Nem értelek. Nem keletkezik hex állomány, ezért nincs benne semmi. Az első képen látható hibajelzés után kiírja, hogy Build failed. Ugyanígy járok, ha a

sort használom. A következő sorra nem ad hibát, de a hex -ben FFFF szerepel.


Ha kézzel átírom a hex állományt, most már behozza a PICKit2 betöltője...

Ha a USERID -s részt kikommentezem, a többi lefordul, és FFFF van az UserID helyén.

Én sem értettem, elnézést! Nekem lefordítja ezt és ez a hex lesz.

Szia!
Köszönöm, megvan!
Túlbuzgó voltam, az FUSBIDIO és az FVBUSONIO beállítása egy #pragma -ban is szerepelt. Ettől sokalt be a linker.

Örülök, hogy segíthettem egyszer neked is! Ritka pillanat!
Ezt ha jól értem a PK2 forrásának változtatásához használod ugye? Láttam nem semmi dologba fogtál! Jól meggondoltad?

Jól látod! Bár lehet még nem tudom pontosan, mibe is fogtam...
Sok típust a családjának egy már meglévő tagjának átparaméterezésével lehetett megoldani: 12F1501, 16F1508, 16F1509.
Egyes típusok kezelésére elég volt a Pk2DeviceEditor segítségével megjavítani a scripteket vagy újakat létrehozni: 16C83, 16C84, 16F83, 16F84, 18F__K80.
Másoknál új család létrehozásával jártam sikerrel: 16F1454, 16F1455, 16F1459, 16F1788, 16F1789 (14 bites DeviceId és RevisionId).
Néhány típusnál az átparaméterezés nem hozza meg a tökéletes kezelést, magát a programot kellett módosítani: 24F16KL402 (van egy nem használt konfigurációs regisztere).
A 24F, 30F, 33F, 32MX típusoknál a Programming Executive bele van fordítva a PICKit2 programba. A 24F és 33F -eknél a PE használata kikapcsolható, a 32MX -eknél nem. Ez a legnagyobb akadálya a további típusok kezelésének.

Több, mint 200 típus már hozzádava, de még nincs mindegyik tesztelve...

Nem semmi, szép munka és szép meló!

16F883-at használok. Írtam egy hosszú ASM kódot, de az On-Chip Program Memory Page0 részt elhasználtam. A kódom az több, mint 0x800.
Így nem nagyon akar lefordulni.
Mit tudok tenni, hogy a Page1-re is tudjak írni programot és a goto és call részek működjenek?

Szia!

Keress rá, régebben volt erről szó, Hp41C kolléga nagyon szépen összefoglalta...!

Steve

Szia!

Itt olvashatod.

Köszi,
Jó cikk.

Sziasztok!

Az eddigi legérdekesebb PIC problémával szembesültem a minap és remélem, hogy létezik rá megoldás, mert különben lég nagy sz*rban vagyok.

Adott egy elemről működő (3V) panel, PIC32MX440F512H-val a szívében, a tápon egy 0.33F-os backup kondi. A realtime clock miatt a backup elengedhetetlen.

Amikor elemcsere van (és ez nem történik meg elég gyorsan), a PIC idővel lezabálja a backup-ot 2V-ra és ott ugye kifagy. Ez idáig nem gond, mert a realtime clock-ja még simán eljár, mindenesetre a beállított dolgokat nem felejti el, DE: amikor újra 3V-os tápt kap, a PIC nem indul el többé... MCRL-es reset sem segít, semmit nem lehet vele kezdeni, csak ha elveszem tőle teljesen a tápot (azaz a bacup kondit) és úgy újra elindul, ilyenkor persze elfelejt mindent.

Lehetne mondani, hogy kicsit várjon az ember, amíg a backup-ból jobban kifogy a delej és akkor majd jó lesz(bár ekkor is elfelejtene mindent), de amikor 2V körül lehal a PIC, utána szinte 0-vá válik a fogyasztása és az életben nem megy 2V alá a backup. Olvastam valahol, hogy más is találkozott ezzel a problémával, tehát nem a PIC egyedi gyártási hibás.

Úgy tudom, hogy a 32-es családból ráadásul kivettek egy csomó regiszter állítási lehetőséget (pl "reset táphibára" és annak beállításai), maximum utólag kiolvashatók, hogy az ember megtudja, miért történt reset... de rajtam ez nem segít.

Az is igaz, hogy ha IDLE módban történik az elemcsere, akkor azért elég sokáig elmegy backupról, mielőtt a gond bekövetkezne, de nem lehet tudni, hogy a felhasználó nem veszi-e ki az elemet üzem közben (vagy pl. leesik a cucc és kiesik az elem).

Van ötletetek a probléma megoldására?

Köszönöm!