Ha már törölted a PIC-et, akkor nem fogod tudni visszaolvasni azt, amit egyszer annó beletöltöttél. Lehet, hogy az a HEX fájl amit készítettél csak 22 kB-os, de kiolvasáskor a nem használt területen 0x3FFF fog megjelenni, nem pedig a semmi vagy nulla. Egy teljesen üres PIC-et kiolvasva sem nullák vagy a semmi jön vissza, hanem Hp41C által is leírt 0x3FFF.

Hozzá kell tenni, hogy kontrollerenként változhat, hogy az üres terület mivel van "feltöltve", ezt az adatlap többnyire tartalmazza. Továbbá, a gyárból kikerült kontrollerek általában nullákkal vannak teleírva. Ha egy ilyenre ráengeded a "Blank Check" parancsot, akkor azt fogja válaszolni a program, hogy a kontroller nem üres.

Tenyleg kivancsi lennek, hogy miert csinalsz egy ciklust es tologatod a biteket jobbra-balra, ahelyett, hogy negy MOVFF utasitassal megoldanad az egeszet.

Intel hex forámum

A törlés után persze, hogy nem tudom kiolvasni a korábbi tartalmat. Kezdő vagyok, nem hüle..
A gondom az, hogy a feltöltött és a visszaolvasott hex fájl nem egyezik meg.
És NEM csak azért mert kiolvasáskor a teljes memóriatartalmat kapom vissza a 0x3FF-kel bővített formában, hanem sorok cserélődnek ki másra és tűnnek el.
Mellékeltem az előbb a betöltött és utána kiolvasott, exportált fájlt.
Vannak sorok amik megtalálhatók az exportban is, de nem mind, és vannak olyanok, amelyek nem a forrásból származnak. (látszólag)
A feltöltött hex fájl amúgy egy assemblyben megírt led soros futófény, működik.
Az eredeti kérdés továbbra is áll:
Hogyan lehet a PIC-be töltött hex. fájlt eredeti formájában visszanyerni?

(Különben honnan a bánatból tudhatnám, hogy az adott PIC-kel mit csináltam régebben, hol hagytam abba, stb.
Próbapanelom van, amiben csereberélem a PIC-et az ép futó projektnek megfelelően, pl. LCD, hétszegmenses, futófény, stb .
Összedugom a "hardvert" beleteszem a hozzátartozó PIC-et, és jó lenne tudni, mi van benne.
Hangsúlyozom saját bütykölések, nem a NASA titkos projektjét akarom visszafejteni:nono

Köszi, ez nekem új és hasznos.
Sajnos a gondomat nem oldja meg.

Szerintem rossz oldalról közelíted meg a dolgot. PIC-ből kiolvasni csak debug és "ha nincs más út" esetén érdemes. Mivel ezek többször programozható eszközök, teljesen feleslegesnek érzem kiolvasni belőle a hex-et ha amúgy a gépeden meg van még esetleg a forráskód is.

Hát biztos az én hibám, rossz a "munkamódszerem" de én addig foglalkozom egy-egy témával, míg bele nem fáradok.
Akkor nézek valami mást (különösen, ha nem megy).
Például először egy LED-et villogtattam meg, aztán a LED soros futófénybe beletört a bicskám egy hét után kicsit félretettem, és kipróbáltam mire megyek egy kétsoros LCD kijelzővel.
Amikor az már ment, visszatértem a futófényre, de két hét után már nem tudtam, hol is akadtam el korábban.
A források persze meg vannak, (túl sok is), hogy melyik van épp a PIC-ben, jó lenne tudni.

Tényleg nem bántás, csak a saját módszerem: Létrehozom a projekt főmappáját (ráutaló névvel), majd bele további mappák, valami-1 vagy valami-2, stb nevekkel. A főmappában van egy TXT fájl, amibe beírom röviden, hogy mit mikor és miért... Egyébként a programjaimban meg rengeteg komment van, hogy tudjam, mit is csináltam ott, azon részen. Évek múlva is -ha előszedem- tudom, hogy hol jártam...

Ez tök jó! De mennyi programot írtál mire ez a gyakorlat kialakult?

Akkor kezdtem, amikor először belefutottam a Te problémádba. Jó pár éve volt már... Talán a 3. vagy 4 projektnél.

Nem az én problémám, hanem Fricu kollégáé, én csak érdeklődtem.

Úgy-úgy, bocsi. Kicsit figyelmetlen voltam.

Nem tűnik el semmi sem... Csak átrendeződik... Figyelem, csak egyszer írom le...
Az Intel hex állomány sorai lehetnek teljesen mások, de az állomány tartalma mégis ugyan az marad. Hogy miért?
A sorok egy memóriaterület adatait adják meg.
Minden adatokat tartalmazó sorban a ":" után a a sorban levő adat byte -ok száma van (természetesen hexadecimálos számrendszerben).
Ha egy 16 byte -os területet, melyen ugyan az az adatsorozat van kimentek egy 16 byte -os rekordba, vagy két rekordba (vagy máskép), amiben összesen 16 byte van, az adat ugyan az marad, de a file más lesz. Rengeteg féle módon menthetem ugyan azt a 16 byte -ot... A kontrollered 16k (program) + 256 (adat eeprom) + 8 (user ID) + 2 (config) byte adatot tartalmaz. Ugyan azt a tartalmat kismillió féle állományba lehet elmenteni. Akár byte -onként is írhatnám külön rekordba.....
Visszatérve:
Betöltött.hex: A fordító program készítette, csak a fontos adatok vannak benne:

A kiterjesztett cím 0x0000 - nem érdekes, mert az egyész tartalom < 64K.

Maga a program. A többi területre nem ad meg tartalmat.

A 0x400E byte cím azaz a 0x2007 memória cím (mivel 14 bit csak 2 byte -on fér el) a konfigurációs regiszter értékének megadása.

File vége rekord.

Kinyert.hex: A programozó készítette, minden adat benne van, ahol csak lehet 16 byte van egy rekordban:

A kiterjesztett cím 0x0000 - nem érdekes, mert az egyész tartalom < 64K. Ugyan az a sor.

Ugyan az a program csak 16 byte -osával....

A további programterület - a szerencsétlen kiolvasta, de nem tudja, hogy nincs benne hasznos információ...

A 0x4200 byte cím azaz a 0x2100 memória cím, az adat EEProm területe. A szerencsétlen kiolvasta, de nem tudja, hogy nincs benne hasznos információ...

A 0x4000 byte cím azaz a 0x2000 szócím, a felhasználói azonosítók (user id) területe. A szerencsétlen kiolvasta, de nem tudja, hogy nincs benne hasznos információ...

A 0x400E byte cím azaz a 0x2007 memória cím a konfigurációs regiszter értékének megadása. Ugyan az a sor csak egy kicsit hátrébb.

File vége rekord. Ugyan az a sor csak egy kicsit hátrébb.

Hát biztos az én hibám, hogy nem tudtam jól megfogalmazni.
A projektjeimet kommentelem, dokumentálom, stb.
Azt nem tudom mi van az adott PIC-ben aktuálisan.
Van egy programból négy-öt változatom, más más megoldással, (csak tanulom a dolgot, próbálkozok) hogy melyiket töltöttem fel utoljára, a fene tudja. (pár nap, hét múlva). A dátum nem irányadó.
Gondoltam: a legegyszerűbben a beletöltött hex. fájl alapján azonosíthatom.
Triviálisnak tűnt kiolvasni, exportálni a hex fájlt, és akkor már csak ki kell választani melyik volt.
Naivitás lenne, hogy ez működik-működhet?

Az már elvi kérdés, hogy miért nem egyezik a beírt és a kiolvasott hex fájl.
Hogy a hosszuk eltér ok, de sorok tűnnek el és keletkeznek.....
Vagy ez csak engem aggaszt?

Köszi
átolvasom és megpróbálom értelmezni

Szia!
Jelölj ki a PIC programmemóriájában egy címet, ahová írsz egy ID-t, ami azonosítja a programot. Így ránézésre meg tudod mondani a hex-ről (persze látnod kell a címeket is), hogy melyik program van benne.

Erre szolgálnak az un. felhasználói azonosító (UserId) szavak. Ezeknek a tartalmát akkor is ki lehet olvasni, ha a program és / vagy az adatmemória kiolvasásvédett.

Először ezt akartam írni, csak este nem voltam benne biztos, hogy minden PIC-ben van ilyen.

Sziasztok!
Azzal a kérdéssel fordulnék hozzátok, hogy a 16f628-as és 16f628A-s pic között mi a különbség?
A 16f628-ra írt program fut-e a 16f628A-n.

Igen fog futni rajta a program. Azt hiszem csak olyan különbség van, hogy a 628 az 3-5,5V között képes működni a 628A pedig 2-5,5V közötti feszültségen. Amúgy teljesen ugyan az a két PIC.

Köszönöm a választ.

Sziasztok!

Bocsánat hogg kiírom megint de eltűnt a hozzászólásom! :/ DDE protokollal kapcsolatban szeretnék segítséget kérni hogy ebben a formátumban kiadott adatokat hogy lehet kinyerni és PIC számára értelmezhetővé tenni??? Csak számadat!

Köszönöm!

Nem tünt el a hozzásszólásod, csak közben zajlik az élet.
Milyen DDE -re gondolsz?
PIC és a PC között többféle adatkapcsolat is megvalósítható:
Aszinkron soros vonal: Lehet vezetékes RS232, BlueTooth, USB -re konvertált, stb
USB: USB - uart, USB HIB, saját protokoll.
stb.

NA ez az amit nemtudok... :/ Van egy program (orbitron) ami számértékeket elvileg dde protokolon közvetít! Jelen esetben rádiófrekvenciát és pályaadatokat!

Ezeket a számokat szeretném valahogy levenni a programból és egy PIC számár kiküldeni!A gond ott kezdődik hogy nem ismerem ezt a tipusú "nyelvet " és nem tudom hogy mi a megoldás!

Esetleg apróhirdetés keretein belül is feldobom a témát.. és aki tud vagy akar segiteni és megoldást generálni, azzal nagyon szivesen egyezkednék! mert tudom hogy ez nem csak annyi hogy leellenőrzök mondjuk egy áramkört....

Van köztük néhány apróbb különbség, de alapvetően kompatibilisek egymással.
Bővebben: Link

Olyan kérdésem lenne, hogy a zavarszűrésre szánt kondenzátorok értéke mitől függ?
Például a táp szűrése, bemeneti port gombja, lm7805?
(Lm7805 datasheetjében ez van: input-gnd 0.33mikroF, output-gnd 100nF, de kapcsolásokon úgy láttam hogy inputra is 100nF-ot használnak sokan)

Vicsys nemrég rakta fel, hogy Ő mit szokott használni. Szinte bolondbiztos.

Ha ez a DDE a Microsoft-os Dynamic Data Exchange Protocol, akkor sok köze nincs a hardveres dolgokhoz. Ezzel programok közötti kommunikációt valósítanak meg, ha ezt le tudod kezelni PC-n, akkor onnantól már ki tudod küldeni soros/USB porton keresztül akár egy PIC számára is.

Bővebben: Dynamic Data Exchange

Pontosan arról van szó, és rátapintottál a lényegre, sajnos nem tudom lekezelni.. :/
Reméltem ebben tudok segítséget kapni, mert itt a forumon is olvastam egy két projektet ahol DDE rendszeres progi komunikált pic-el, ráadásul ugyanúgy számértéket küldött ki!