Szia!

A 16F87x és a 16F88x közötti eltérések, a 16F88x kiegészítéseit nem sorolom fel:

- T1 timer Gate funkcióval kiegészítve (T1CON 7..6),
- A CCP1 modul a 88x -en Enhancced Capture/Compare/PMW modul. CCP1CON 7.8 bitje definiált, A CCP1M biteknél négy kombináció (1100 .. 1111) más-más PWM módot jelent.
- Az uart illesztő EUART (TXSTA,4 ), 16 bites Baud generátorral, BAUDCTL regiszterrel kiegészítve,
- Az AD illesztő bitkiosztása és működése is eltér.
- MSSI SSP MASK regiszterrel bővítve,
- A komparátor modul az A/D -t és a T1 -et tudja vezérelni,
- A leglényegesebb etérés:
A 16F88x -en egyes portbitek digitálissá állításához az ANSEL és ANSELH regiszterekbe kell megfelelő értéket beírni, a 16F87x(A) -n a ADCON1 regiszterbe.

Valamint érdemes a két típus errata dokumentációját is összehasonlítani - nem biztos, hogy ugyan azokat a hibákat találjuk bennük...

Ha a 16F87x(A)-ra fejlesztett program a regiszterek nem használt bitjeit 0 értékkel írta, akkor működni fognak az illesztők, a portok beállítása és az A/D kivételével.

Valószínűleg .cof fileokról lehet inkább szó. A .hex fileok szöveges állományok, és pld ilyen sorokból állnak:

:100440000000fe004440a900a00020000000e000e1

Ha tényleg .hex file-jaid vannak, szöveges formában elő tudod keresni a gyárihoz képest azt a sort, ami eltérő. Koppantsd be plz az eredeti sort is, meg azt is, amit te csináltál. Ezekben a sorokban memória offset cím is benne van az adattal együtt. Lévén ismert a pic típusa is, amibe betöltenéd, egészen pontosan vissza lehet keresni a pic adatlapból, hogy melyik config bitet mire cserélted volna le a gyárihoz képest. A dolog forrása persze a programfile-ban lesz, de már tudni fogod, mit keress.

Egy-két dolog kimaradt:

- A 16F87x -nek 1, a 16F88x -nek két konfigurációs szava van - eltérő bitkiosztással,
- A programtár írásában is van eltérés...

Én már csak azt nem értem, hogy a PIC16F87x hogy jött a képbe...

Igen és reagálni is elfelejtenek egyesek, pedig tálán a megoldást is megkapták, bár lehet, hogy nem értették meg...

Ha ezt a #958428-ra értetted, amiatt ugyan ne törd a fejed. Volt anno 286-os processzoron idtr regiszter, át lehett állítani a megszakítás vektro táblát. Pic32-n egyesével saját kézbe lehet venni a táblát, és programozottan ugyan ezt megcsinálni RAM területen átfuttatni az összes vektort. A kernel modulokat szétosztani linux alatt pld az int 0x80-as vektoron általános gyakorlat, pic-en is lehet hasonlót csinálni. Kernel memóriának ott az anno ROM-BIOS munkaterület, még felépítésre is kézre áll (Abonyi Zsolt PC-Hardver kézikönyv). Memória szeletelésre meg az egykori MS-DOS paragrafus alapú memória felosztása remek példa (IBM PC DOS 3.3 reference). Adat újracímzésre bevált gyakorlat volt DOS alatt az .exe programok relokálása. Szóval ilyesmikből bőven el vagyok látva használható tapasztalatokkal. A gondom tényleg csak fordító oldalon van, mert ha nem sikerül kényelmes módot találni egy C szintű program írására olyan módon, hogy az utána gépi kód szintjén is blokkosan kezelhető maradjon, akkor ez az ötlet tuti a levesben végzi. És ha még mindig kérdés lenne, ugyan mivégre, akkor újra leírom, hogy működés közben akarok ethernetes pic elektronikán szoftvert frissíteni távolról a működési adatok megzavarása / vesztése nélkül. Erre pedig technológia kell kitalálni. Ezért próbálkozom dolgokkal. És igen, előfordulhat, hogy bebukom.

Ez nem hiszem, hogy kezdo PIC-es tema, de nem gondolod, hogy a relokalas csak amiatt kell, mert a cimzes nem relativ? Egy DOS-os EXE-nel mikor az operacios rendszer betolti az allomanyt, akkor szepen egyesevel vegig patcheli a nem relativ cimzesu utasitasokat, hogy azok a megfelelo emoria cimre mutassanak. Neked erre nincs szukseged a PIC eseteben.

Ha tobb modulod van amiket cserelgetni szeretnel, akkor kell egy un API tablat felepiteni, ami nagyon hasonlo ahhoz ahogy a Windows-ban is mukodnek a DLL API hivasok. Tehat a modulnak az 1-es verzioja aktiv, kozben feltoltod a 2-es verziot. Ekkor meg az ugro tabla (API tabla) az 1-es verziora mutat meg mindig. Mikor ez sikeres a letoltes, akkor az osszes megszakitast letiltod es ezt az ugro tablat irod at a 2-es verziora. Innentol kezdve a szoftver a modulod 2-es verziojat hasznalja. Ha hiba van, a user megnyom egy gombot mikor is egyszeruen csak vissza allitod a tablat az 1-es verziora (azal meg mukodott effektus...)

Kb ilyen egyszeru a keplet. Beagyazott rendszereknel elegge bevalt gyakorlat, hogy a firmware-nel tobb valtozata is el van tarolva, nem kell kitalalni a spanyol viaszt.

(OFF-ba tettem mert ez nem kezdoknek valo tema)

A félreértés abból adódott, hogy nem pontosan kérdezted meg amit szerettél volna, ezért mindenki a flash írásával kapcsolatosan kezdett válaszolgatni, én is.

A C fordítót nem hiszem, hogy gépi kód szinten lehetne vezényelni, mármint, hogy mit hová fordítson és ezzel elérni, hogy a megfelelő részeket kézben tartsd a célzott flash égetéshez. Bár a #pragma code paraméterezésével lehetne próbálkozni.
A biztos megoldás, hogy Assemblerben programozol...

Történetesen éppen asm kód fordítással van egy kis bajom. Parancssoros scriptet írok fordításhoz. Amikor beküldöm az assembler eredményét a linkerbe, kapok egy ilyet:


Ez a __reset nem tudom minek kell a linkernek, de ez nincs benne a pic libjeiben sem. A forráskódban sincsen ilyen hivatkozás.

Az indító parancssor egyébként ez volt:


Mit szúrtam el?

A __reset szimbólumot neked kellene globális címkeként deklarálnod a főprogram elején. A linkernek csak azért kell, mert itt kezdődne a program...

Például:

Hogyan van arra lehetőség, hogy én a .global-nak más nevet megadva le tudjam fordítani a programot? Mondjuk ugyan az lenne minden, épp csak a __reset helyett __kutyagumi -t akarok használni. Ez a __reset bele van hardkódolva a linkerbe? Elvileg nem kellene, hogy úgy legyen.

Van egy olyan sanda gyanúm, hogy a startup (crt0_standard.o vagy crt1_standard.o) kódjába van bedrótozva. Nem látom semmi értelmét a név megváltoztatásának. Ha más címre akarod fordítani a programot, akkor a linker scriptet (esetedben a p33FJ128GP802.gld állományt) szabd át!

program (xr) a program (a .text szekció) kezdőcíme, bootloader esetén pl. ezt kell megváltoztatni. A jelek szerint a reset és az interrupt vektorok címe is átírható a program számára (csak aztán legyen, aki beleugrat!).

PIC24/dsPIC esetén egyébként van alternatív interrupt vektor tábla (AIVT) is. Ez arra jó, hogy gyorsan át lehessen kapcsolni a felhasználói és a felügyeleti környezet között. Természetesen másra is használható, például ott, ahol különböző algoritmusok vagy alternatív rendszerek (pl. bootloader és felhasználói program) közötti váltogatásra van szükség. Az alternatív interrupt vektorok táblázata egyetlen bit módosításával, az INTCON2 regiszter 15. bitjének (ALTIVT) '1'-be állításával aktiválható.

Interrupt táblára köszönöm a tippet. Bárcsak már ott tartanék. De még nem. Pontosítanék egy problémát.

Ez lefordul:


Ez meg nem fordul le:



Hogy miért akarom én a másodikat erőltetni? Tök egyszerű. Mert a compilerrel ha asm forrást gyártatok, annak ilyen .global van a kimenetén. Nem találtam sem az assembler sem a linker paraméterezésében olyan kapcsolót, ami symbol helyettesítést csinálna. Ha mást nem, akkor még ellenőrzöm pic32 alatt is megvan-e ez, és ha ott is, akkor írok egy szöveg file feldolgozót csak emiatt - bár szívesebben megúsznám.

És amúgy valóban szívesebben írnám tisztán asm-ben a kódot, ha nem lenne eszetlen egy munka pld tcpip + flash + usb stacket átírni C-ről asm-re. Az MC support C-ben van. Azt mindenestül újracsinálni..

Szerintem kevered a szezont a fazonnal! A C program is így fordul:


Most akkor mi lesz ebből, ha a __reset címkét is _main-nak nevezed el?

Van egy C program:


Ennyi. Ezt bedobom compilernek -S kapcsolóval, csinál belőle egy ilyet:


És nem igazán tudom neki megmondani, hogy a start symbol-nak _main helyett __reset-et adjon be. Vagy kihagytam valamit, de mit?

Ha azt a _main-t átírom __reset-re, és csak ennyit csinálok, akkor le is fordul. Egyébként meg nem fordul le. Egy scriptben ez azért gáz, mert ezt automatizálni kellene, és nem kézzel csinálni. Amíg a scriptem egy lépésben C-ből objectet fordított, és azt dobtam a linkernek, nem volt ilyen gond. Szépen megcsinálta. Most, hogy asm-en keresztül megyek, mert a compiler után az assemblerrel csináltatom a cuccot, mert kell a lista file is, és tuti biztosan annak megfelelő object kimenet kell, ergo azt az assembly kódot kell tovább fordítani, így már elakad.

Ebben nincs benne a startup kod -- azt bongeszd inkabb!

Én így néztem meg: Link

icserny:
Az ott egy ASM program, nem C.

trudnai:
Sőt, a pic függő assembly include állományban sincsen benne startup kód részlet. És egyébként is ennyi volt a compiler teljes kimenete. Ha nem generált le valami szükséges cuccost, akkor azt hiba folytán nem tette meg. Jobbat nem tudok, most meglesem ugyan ezt pic32 alatt is.

Az nem program csak egy main függvény.

Na, összehoztam végre valahára. A compilerrel dobáltattam tovább az utasítást az assemblernek is, meg a linkernek is. A végeredményről kaptam object listet, meg van mem report.

Egyébként ami a .hex-be lekerült, abban annyi a sallang a reportolt dolgokhoz képest, hogy csak lesek. Lévén azt a cuccot a linker ragasztotta hozzá, nyugodtan nézze csak meg mindenki, aki az assembly tisztaságában hisz, mi is történik a kódjával, mire a linker hex-et gyárt belőle.

1. Fel kell tölteni a RESET vektort és az IVT, valamint az AIVT vektortáblákat.
2. Be kell állítani a vermet
3. Ha konstansokat használsz, akkor be kell állítani a PSV-t (kódterület láthatósága), ellenkező esetben pedig letiltásra kerül.
4. Ha van felhasználói inicializálás, akkor meghívásra kerül az __user_init függvény
5. Végül meghívásra kerül a _main függvény

Ez a crt1_standard.s-ben található rövidített litánia, ami a --no-data-init opció használata esetén érvényes.
Észrevetted már, hogy te mondod meg, hogy mit csatoljon hozzá, és mit ne a programodhoz? Nézd meg a linker állomány (.gld) elejét!

Ezt a kettő objectet valahogy nem találom. Pedig még a libeket is kinyitogattam bináris editorral, és rákerestem az object névre.

Szerintem a libpic30-coff.a és a libpic30-elf.a tartalmazza, mert nálam a forrásuk is az src/pic30/libpic30.zip-ben van.

Sziasztok.
Volna egy apró gondom, mégpedig egy 12f675-el. A probléma, hogy két PIC-et szeretnék meghajtani egy rezonátorral (vagy kvarcal). Próbának beállítottam a 12f675-t külső 4Mhz oscira (XT_OSC), és rámértem a 3-as lábra, de csak pár khz jön ki rajta. Ha ugyanezt megcsinálom pl 16f84-en (15 láb) ott megvan a 4Mhz és igy már menne a másik PIC is. Már átolvastam a 12f675 adatlapját, de nemnagyon találtam ezen a téren semmit, vagy csak elkerülte a figyelmem. A kérdésem , hogy a 12fxxx be mit kell még beállítani, hogy lássam a 4Mhz-t?

Nincs neki ilyen üzemmódja (egy kvarcról két PIC). Hivatalosan csak önálló, külső oszcillátor jele vihető be több PIC-be.Esetleg próbálkozz HS móddal, hátha csak az a baj, hogy túl sok volt a terhelés!

Egyébként mi értelme lenne a dolognak, a belső órajel miért nem jó?

Egy kapcsolásban láttam ezt a megoldást, hogy ott mi értelem van azt nem tudom pontossan, talán, hogy mind a két PIC ugyanazon ferkin járjon. A képen látszik, hogy köti össze a két PIC-et, Én is így szerettem volna, ja és a 12c508-al megy, de a 12f508 meg a 12f675-el már nem működik. Amúgy csak szerettem volna kipróbálni, és mivel a csatolt kapcsiba megy, nálam meg nem, mint probléma szerettem volna megoldani.

Hálás köszönet Icserny Úrnak, átraktam HS_OSC -ba s lőn világosság megjelent a 4Mhz és a progi is pontossan fut. Még lenne egy kérdésem, hogy lehet a lehető legkönyebben létrehozni egy 10 perces időzítést? Pontossabban azt szeretném, hogy a pic-en lévő program 10 perc után megálljon, és mondjuk egy gombnyomásra újabb 10 percig menjen.

Attól függ, hogy milyen nyelven programozol. JAL nyelven például csak be kell csatolni a késleltetéseket definiáló könyvtárat.

Bocs, de úgy nézem, hogy ez a JAL 2004-ben vagy 2003-ban volt utoljára frissítve, szerintem el kellene inkább felejteni. Lehet, hogy vannak benne jó dolgok, de a fenti okból kifolyólag szerintem nem érdemes vele foglalkozni...

Bocsánat, hogy nem írtam, asm-ben próbálkozok.Ja és PIC16f882-ről van szó.