MPLAB - volné místo v procesoru

[piityy]

a nebo je to standardem jen u microchipu…

[honza3]

Myslím si, že nemáš pravdu. Kdyby tomu tak bylo, ty HEXy by nepřekously jiné programatorské softy, ale jen MPLAB.

[piityy]

Jsem ted nemocnej, tak do toho zas vrtam

Soubor: “MultiplexBIG8S.HEX”

@honza3

Jasně že moh. Obsazeny všechny page, ale ne plné. PAGE 0 0x0000 do 0x02FE, page 1 0x0800 do 0x0C99, page 2 0x1000 do 0x10A5, page 3 0x1800 do 0x1AF9

:100000000000002800080008000800111212131355 Bytes: 16, Address: 0000, Type: 00 :0F02F0000030002A220B2A3408000B2A0B2A3474 Bytes: 15, Address: 02F0, Type: 00
Page 0 vporadku

:100800001512161708201617000007343434343434 Bytes: 16, Address: 0800, Type: 00 :0A0C9000162011122212131112296E Bytes: 10, Address: 0C90, Type: 00
Page 1 vporadku

:101000001213300000000000000000001213300036 Bytes: 16, Address: 1000, Type: 00 :0610A000003000300000EA Bytes: 6, Address: 10A0, Type: 00
Page 2 vporadku

:1018000007343434343434343434343434343434C5 Bytes: 16, Address: 1800, Type: 00 :0A1AF00012130A151622121300004B Bytes: 10, Address: 1AF0, Type: 00
Page 3 vporadku

Nyni by mel nasledovat zaznam “EndOfFile”. Bohuzel pred nim je jeste jeden(ten druhej je spravny EOF):

:0120070037A1 Bytes: 1, Address: 2007, Type: 00 :00000001FF Bytes: 0, Address: 0000, Type: 01

Tudiz je tento HEX podle honzova popisu temer spravne (vesel by se do 8kB) nebyt predposledniho zaznamu “:0120070037A1”. Ten totiz obsahuje adresu 8199(dec). Proc tak blba adresa? vsechny predchozi adresy koncily “0”(nasobky 2^4) - zaznamy byly az do posledniho v page po 16 bytech…
Cosi shnileho je u microchipu… Pokud by mel ten predposledni zaznam pro microchip nejaky specificky vyznam, meli by ho tam vlozit jinym zpusobem, nebo ho alespon nekde popsat…

@honza3

…ten HEX je INHX32, HEX obsahuje typ a nastaveni procesoru a data do EEPROM.

Nemaj nekde popsany to nastaveni a specialni kody? Neco v tom smylsu uz jsi natuknul:

@honza3

:020000040030CA
Tímto řádkem se vybírá konfigurační paměť u součástek rodiny PIC18F.
U rozšířených segmentových záznamů se udává segment, tedy bity 19-4 adresy (segment), které se pak přičítají k
adresám z datových záznamů (offset).

Ukládání typu součástky do .HEX souboru
Velmi často se stává, že dojde k záměně mezi vybraným typem součástky a typem součástky, pro kterou byl Intel HEX soubor uložen. Proto program UP obsahuje funkci ukládání typu součástky do souboru.
Program zapíše za konec souboru ještě řádek #PART=… Drtivá většina programů pracujících s Intel HEX soubory takovýto řádek ignoruje, avšak takovýto soubor nelze považovat za vyhovující formátu Intel HEX.

Zminovany zaznam ani #PART tento soubor neobsahuje, ale prave ten predposledni, ktery mi tam dela bordel, by taky mohl byt nejaky ten “konfiguracni”. Ta jeho adresa je totiz znacne neobvykla (navic licha, u microchipu v praxi nerealna)…

v priloze je cely komentovany HEX a vystup myho programku pri smazani toho konfliktniho radku.

BTW: ty dalsi HEX soubory jsou uplne mimo…

MultiplexBIG8S.HEX.txt (14.5 KB)

[honza3]

:0120070037A1

To je konfigurace paměti.
Ale kdyby jsi do toho prográmku dal i detekci konfigurační paměti, tak by to mohlo fungovat.

Konkétně

__config _BODEN_OFF & _CP_OFF & _PWRTE_ON & _WDT_OFF & _HS_OSC & _DEBUG_ON & _CPD_OFF & _LVP_OFF

Teď jsem si s tím hrál a zkoušel jsem ty HEXy nahrát postupně do PIC a ten MultiplexBIG8S.HEX nefunguje!!

[piityy]

@honza3

… Ale kdyby jsi do toho prográmku dal i detekci konfigurační paměti…

Bych klidne dal, ale neznam ty jejich specialni zaznamy, abych si z toho hexu vybral jen to, co potrebuju

Ten muj “komentovanej” hex nepujde(ikdyz treba ten muj programek ignoruje vsechno za kontrolnim souctem, tudiz by mu to nevadilo) - nedodrzuje format, ale ten tvuj puvodni vy fachat mel, kdyz ti ho prekladac vyrobil, ne?

[honza3]

Já myslel ty moje, ne ten tvůj.
Já to předtím jen přeložil, ale nezkoušel a včera jsem si s tím hrál a zjistil jsem, že překladač MPASMWIN udělá nějakou změnu v tom HEXu a program ve formátu 8S nejede v procesoru. Ono to totiž není ani HEX, ale má to příponu HXH.