Este stale samo-domo programator PICov, tentokrat otazky k (Intel?)hex suboru a zvyklostiam v tomto svete mikrokontrolerov s neortodoxnym usporiadanim pamate, nastavovacich fusov a inych non-volatile zalezitosti

[j s]

Odpovede v texte:

Dňa 17. apríla 2012 15:32, Jan Waclawek <konfera na efton.sk> napísal/a:
> Zdravim vsetkych,
>
> Pripomeniem leitmotiv: chcem napalovat PIC12F683,PIC12F1501 a PIC12F1822, ale zatial nechcem z emotivnych (t.j. nie racionalnych) dovodov kupovat PICKit ktorejkolvek verzie.

Tu som pisal komentar asi 5x a vzdy som ho zmazal. Na domacu ulohu
skus popremyslat preco.

>
> Zatial som sa teda nedostal dalej nez po citanie Programming Specification pre tieto 3 cipy, ale uz som dostatocne znechuteny - zjavne aj Microchip postihla pliaga generovania kvantity aj za cenu upadajucej kvality metodou copy-paste... Spomenute 3 dokumenty v suhrnnom objeme cca 120 stran sa IMHO daju pomerne lahko zhrnut do tretinoveho objemu  aj s doplnenou informaciou, co am chyba... Ale mozno som len tupy a niekto mi rychlo vie objasnit, ze:
>
> - je potrebne "data memory" (EEPROM) pred zapisom explicitne vymazat? Rozdiel vyvojakov pre Data a Program Memory naznacuje, ze nie, ale v texte som to explicitne napisane nenasiel.
>

Ja tam vidim, ze vo vyvojaku je "Bulk Erase Data Memory", teda
evidentne je treba ju zmazat.

> - brani nastaveny bit CPD v CONFIG registri programovaniu Data Memory?
>

Neviem to odtial vycitat. Pravda je, ze som sa dlho nepozeral :-)
Ale nie som si isty, ci je to podstatne. Na zaciatku kazdeho jedneho
programovacieho cyklu by som urobil Bulk Erase, cim dostanem PICko do
"tovarenskeho stavu", potom by som nasypal data kam treba, cim sa
stane tato otazka bezpredmetna.


> - o com sa toci v PIC12F6xx v kapitole 3.1.3, Resetting Write Latches? To treba urobit po kazdom jednotlivm zapise do oblasti 0x2000-0x2007, alebo po 4 zapisoch? Podla vsetkeho iny druh pamati v tom case nemozem naprogramovat a tie latche sa resetuju ked sa resetne cely cip (co je podmienka programovania ineho druhu pamate), alebo je to nejako inak?
>

No ja som to z programovacej specifikacie pochopil tak, ze po kazdom
jednotlivom zapise.

> - v sheete k PIC12F6xx je naznacene (kap.2.3), ze je mozne kalibracne hodnoty nevratne poskodit, v ostatnych dvoch sheetoch sa to nepise, znamena to ze su tam tie kalibracne hodnoty neznicitelne?
>

Bulk Erase sa ich nedotkne a Row Erase tiez nie.
Neznicitelne ale asi nebudu kym mas poruke kladivo.

> - napriek tomu, co je v kap.2.3, pre *niektore* 16F6xx sa v kap.4 pri popise CALIB      wordu (-ov) spomina, ze sa daju vymazat... Tak ako je to? Just mam '683, kde to napisane nie je...
>

Pravdupovediac, toto som celkom nepochopil.
Spomina sa, ze Bulk Erase sa ich nedotkne, ale aj tak sa pise, ze mas
byt s nimi opatrny a pred mazanim ich precitat a po
zmazani/programovani verifikovat a pripadne obnovit.

> - fusy su na wordovej adrese 0x8000 co bytovo je uz za 64kB, EEPROM este vyssie - ktory typ zaznamu sa pouziva na "strankovanie" - 02 alebo 04?
>

Hex subor mozes dostat z MPLAB-u dvomi sposobmi:
1, Pri buildnuti projektu sa v output adresari (ak si ho nenastavis
inak, tak je tam, kde je projektovy subor, inak sa da menit v
nastaveniach projektu) objavi hex, ktory obsahuje len tie casti, kde
nieco je - teda tento ehx je relativne kratky, ak tvoj program
obsahuje len jeden nop, v hexe je tento nop a 01FF zaznam.
2, File->Export, tam mas kompletny obraz pamati, teda ak tvoj program
obsauje ten nop, bude tam, ale okrem toho este kila 0x3FFF zaznamov
To len pre uplnost, aby sme vedeli, o com sa rozpravame.
Samozrejme, ty asi MPLAB pouzivat nebudes, mozes si vykostit z MPLAB-u
MPASM, co je commandlinovy assembler, pripadne si viem predstavit, ze
budes mat tuzbu pouzit nejaky uplne iny typ assemblera, ale tam ti uz
tolko neporadim.

No, ale naspat k otazke: pouzivaju sa zaznamy typu 4. To si mozes
overit tym, ze si to overis, tak ako som to urobil ja pred chvilou,
lebo som to tiez nevedel.

> - da sa spolahnut, ze na konci intelhexu tak ako ho vypluju bezne PICovske vyvojove prostriedky, bude zaznam typu 01? (toto je potrebne pre programator krmeny priamo tym intelhexom)
>

Ked sa pozriem trebars sem http://en.wikipedia.org/wiki/Intel_HEX tak
tam vidim, ze "01, End Of File record. Must occur exactly once per
file in the last line of the file."
Takze v kazdom intel-hex subore musi byt zaznam typu 01. Microchipaci
maju tolko slusnosti a ctia tuto normu. Este som nevidel hex subor bez
tohto zaznamu.

> - je nejaka dohodnuta/obvykla/typicka maximalna dlzka zaznamu (riadku) v intelhexe?
>

Ty ma skusas, ze? :-)
Maximalna je 255B, lebo v intel-hex suboroch su dva znaky urcene na
dlzku riadku. Dohodnuta/obvykla/typicka, nic take neexistuje. Dlzka
moze byt 1B alebo 255B.
Druha vec je, ze sa bezne pouzivaju take zaznamy, aby sa zmestili na
monitor, resp. tlacovy riadok, teda 80 znakov, co by znamenalo
32B/riadok.
Tretia vec je, ze Microchip do svojich hexov dava *najviac* 16B na
riadok. Staci skusit a overit si. Ale tu pozor - pisal som, ze mozes
mat dva typy hexov, jeden ten kratky, druhy ten kompletny. V tom
kratkom mozes mat menej ako 16B na riadku, trebars aj jeden B. Tvoj
hex interpreter to musi pochopit.

> - vo vsetkych troch sheetoch sa spomina akasi checksuma. Ta je ulozena v tom intelhexe? A ak ano, v akom formate?
>

Neviem, nikdy som nijaku checksumu nepouzival.

> - zvykne byt identifikacny word pre typ cipu v tych intelhexoch? Ak ano, zvykne byt na zaciatku?
>

Nie, nic take v hex-och neexistuje.

> - podobne - zvykne byt CONFIG word na nejakom konkretnom mieste suboru (logicky na konci)?
>

Hej, byva to niekde pri konci. CONFIG ma svoju adresu, tak je na tej adrese.

> - je v tych intelhexoch este nieco zaujimave?
>

Programova FLASH, datova EEPROM (ak to pouzijes), CONFIG, ID locations
(ak ich pouzijes), vsetko na prislusnych adresach, inak uz nic
necakane.

> Je mi jasne, ze na vacsinu tychto otazok si budem musiet najst odpovede sam, ale potesilo by ma, ak by mi PIC-znali prezradili aspon cast z toho.
>

Snad som to stihol skor ako si si odpovedal sam :-)

> Dakujem
>
> wek
>

Nemas za co,
J.