A vidíš, já jsem byl nucen kvůli těm neduhům přejít z x51 na AVR. Byla to příšerná řehole přepisovat programy z x51 na AVR, ale dnes toho vůbec nelituju. Bylo totiž čím dál tím složitější s x51 cokoliv realizovat jednoduše a levně.
Co se týče získání velikosti volné paměti, není to ani tak záležitost stránkování ani typem MCU, spíše samotným překladačem. V AVRStudiu tento problém taky nastává, používám-li direktivu ORG v dsegmentu. Dokonce se stává, že překladač nehlásí ani overlapování, což je dost závažná chyba. Pak je třeba zapnout LIST a podívat se, jak to překladač přeložil. Dá se z toho snadno zjistit i velikost volné paměti.
Stále platí, že když je něco zadarmo, tak to obyčejně není super.
Podle me to znamena podporu zaznamu typu:
Data Record (8-, 16-, or 32-bit formats)
Extended Segment Address Record (16- or 32-bit formats)
Extended Linear Address Record (32-bit format only)
Vsechny tyhle typy zaznamu ta moje knihovna podporuje a v tom HEXu zadna synktakticka chyba neni, jinak by mi to hodilo vyjimku “parse error”. Hex soubor je v poradku, jen je to rozlozeni dat jiny nez myslis ty, nebo nejakej jinej programek, kterej ti to ukazuje. Jedine, ze by nejakej konkretni typ zanamu (kterej je ale synktakticky podle intel HEX spravne) mel pro ty konkretni programatory jinej vyznam, nez by mel mit. Mas nejak moznost si overit to rozlozeni dat v pameti? nebo nema microchip svuj programek pro prevod HEX->BIN
Technik: “Stále platí, že když je něco zadarmo, tak to obyčejně není super.” njn… co nadelame, ale pokud vim, avrstudio je pro avr zatim porad ta nejlepsi volba, aspon na WIN.
Jen se mi moc nelibi, ze GCC nedodrzuje ANSI C, vsechno prelozi vporadku, ale prelozi i veci, ktery by nemel…
Já bych zas řek, že s x51 je všecko hodně jednoduché, jen je to pomalé 
x51 mi teda přijdou o dost “jednodušší” (v uvozovkách, oboje je jednoduchý, jen jiný), spíš bych měl říct že x51 jsou v ASM víc user friendly než AVR (PICy a ASM raději nezmiňovat )
Co se týká direktiv, se zjišťováním velikosti u mě nikdy nebyl problém. Stačí nepsat programy jako prase. (tim nemyslim že někdo prase je).
Direktivy, jediný který používám jsou:
u x51: ORG, EQU, DATA, BIT, INCLUDE - žádný jiný “slůvko” jsem nikdy nepoužil
u AVR: ORG, EQU, DEF, INCLUDE, LIST, NOLIST. Možná ješě budu nucen používat další (třeba kvůli EEPROM - tu jsem ještě nezkoušel programovat )
Honzo, zkus vygenerovat ty HEXy v tech dalsich dvou formatech a dat je sem, jesli to bude stejny 
Tady je jeste ta prozatimni verze programku:
mem_pic.zip (8.79 KB)
nasel sem u sebe nejaky hex2bin konvertor - pomohlo by to nekomu?
Ale az zejtra, mizim do postele 
Ano x51 je jednoduchá, ale měl jsem na mysli realizaci s ní. Co není v x51 musí být mimo ni a DPS roste do velikosti. O to je složitější její oživení a pájení. Z toho plyne dráhá výroba.
A s těma vyjmenovanejma direktivama bych asi nenaprogramoval nic. Asi jsem to progamátorský prase.
Co třeba DB, DW a hlavně MACRO. Právě pomocí maker lze fantasticky zjednodušit a zpřehladnit zápis. A jak bys chtěl udělt třeba circular buffer?
Snad to pomůže piityymu 
[code]4.10 Podporované varianty HEX souboru
• “obyčejný”, někdy též Intel 8-bit HEX File, MPASMWIN generuje tento soubor při parametru INHX8M
• “rozšířený”, někdy též Intel 32-bit HEX File, MPASMWIN generuje tento soubor při parametru INHX32
Popis formátu Intel HEX souboru
Intel HEX jsou textové soubory, které se skládají z řádků.
Každý řádek má následující strukturu: :LLAAAATTDDDD…CC
• : Tímto znakem (dvojtečka, 0x3A) musí začínat každý řádek souboru.
• LL Délka záznamu (počet políček DD).
• AAAA Adresa prvního byte záznamu.
• TT Typ záznamu. Typy mohou být:
• 00 - Datový záznam.
• 01 - Záznam Konec souboru. Každý soubor musí končit tímto záznamem.
• 02 - Rozšířená segmentová adresa. (pouze 32-bit HEX)
• 04 - Rozšířená lineární adresa. (pouze 32-bit HEX)
Existují i jiné typy, 03 a 05, které program UP při načítání ignoruje a při ukládání souboru nepoužívá.
• DD Data záznamu. Počet bytů musí být přesně LL.
• CC Kontrolní součet. Kontrolní součet je počítán jako dvojkový doplněk k součtu všech hodnot na řádku.
Datový záznam
Jako příklad poslouží řádek s uloženou konfigurační pamětí 14-bitové součástky.
:02400E00413F30
• Délka záznamu: 02 - Velikost konfigurační paměti je jedno slovo = 14 bit = 2 byte (zarovnáno na celé byty)
• Adresa záznamu: 400E - Adresa konfigurační paměti je slovo 2007h, adresováno po bytech tedy 400Eh
• Typ záznamu: 00 - Datový záznam
• Data záznamu: 413F - Konfigurační slovo je 3F41h
• Kontrolní součet: 30 = 02 + 40 + 0E + 00 + 41 + 3F = xxD0; neg D0 = 30
31
Konec souboru
Jedinou možnou variantou řádku Konec souboru je:
:00000001FF
Rozšířená lineární adresa
Tento řádek obsahují pouze soubory, které potřebují adresovat více než 64 kB adresového prostoru. Na příklad procesory rodiny PIC18F mají uloženou konfigurační paměť na adrese 0x 30 00 00 00.
Pokud je třeba použít tuto adresu, je nutné do HEX souboru vložit řádek s rozšířenou lineární adresou, který obsahuje horních 16 bitů adresy. Dolních 16 bitů je načteno z řádku s datovým záznamem.
: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.[/code]
MultiplexBIG8S.HEX (7.94 KB)
MultiplexBIG8M.HEX (15.8 KB)
Sice nevím, co přesně řešíte, ale pokud jde o délku paměti, tak můžete zkusit třeba free program UP od ASIX. Já ho mám v počítači, protože jsem používal jejich Piccolo. Je to programovací software. Když do něj naloadujete HEX, tak barevně zobrazí obsazení pamětí. Dovede i konverzi do BIN. Jediné co je nutno udělat, je nastavení správného procesoru.
Používám UP taky, ale tem barevně ukáže celkovou obsazenou a volnou paměť.
Honza3 by ale chtěl barevné rozdělení stránek v paměti, tedy jestli jsem ho správně pochopil.
Já jsem se původně ptal, jak zjistit místo v procesoru. Pak napsal pštros, že kdysi chtěl udělat něco jako defrag v barvě. Pak se toho piityy chytl a začal tvořit. Kdyby jste to vy dva napsaly hned, nebylo by co řešit a piityy by se nudil. Zkusím UP. Někde ho tu ještě mám, používal jsem ho na Picquick.
Edit: Tak jsem ho zkusil, ale nějak jsem nepochopil, co myslíte barevně ukáže obsazení paměti. Hlavně to PAGE.
To co je obsazené je zelené, to co volné bílé.
Pokud si dáš na začátek programu třeba tento zápis
org 07FFh ; konec prvni PAGE
movlw .1
org 0FFFh ; konec druhe PAGE
movlw .1
org 17FFh ; konec treti PAGE
movlw .1
uvidíš v UP programu zeleně označené konce PAGE. Zápis platí pro PIC16F877.
Tak… a mam po zabave 
Ale stejne budu jeste chvilku otravovat 
“Data záznamu: 413F - Konfigurační slovo je 3F41h”
Tady je problem, v rozdilu mezi mcu, PC a jinymi stroji (ne x86) . Jedna skupina stroju pouziva adresaci, kde nizssi adresa nese MSB vice bytoveho slova a druha skupina naopak 
nanestesti toto neni ve specifikaci intelHEX definovano (alespon v te, kterou mam k dispozici). Vznikl by tim problem pri adresaci rozsirenych adresovych prostoru, ktere ovsem nejsou v tech Honzovych hexech pouzity, takze by to stejne melo byt zobrazeno spravne 
Zajimave take je, ze ten 8-bit extended hex generuje stejne jako ten 32bit-extended pres 16kB dat, ale ten zakladni 8-bit jen 8kB a nejaky drobny… ted jsem teda mimo misu…
Ten UP je taková nouzovka po tom, co ukázal piityy, že by to mohlo i fungovat. Já jsem si dával na začatek každe page nop, abych věděl, kde je co a koukal na to ve WinPicu800. Ale UP to má hezčí. 
hod nejakej obrazek, at vim, jak to vypada u konkurence
Jankop psal, ze ten programek umi i konverzi do BIN… Muzes to tim prevest a dat vedet, jaky velikosti souboru to pri kterym hexu vyrobilo?
BIN je v raru. Ale podle mě je nesmysl, aby jsi to dělal na BIN. Chtělo by to přímo z HEXu.
MultiplexBIG.rar (1.7 KB)
Pardon, pane, zapomněl jsem na tyhle makra… DB, DW (použil jsem jen výjmečně), makra u x51 nepoužívám, u AVR je to samozřejmost…
To je mi jasny, jen sem chtel videt vystup z toho druhyho programku… Stejne ale porad netusim, kde je chyba 
Asi mezi klávesnicí a židlí.
nejspis… ale v tom pripade mezi vice klavesnicema a zidlema… Protoze jak uz jsem psal - i jiny programy to prelozej stejne jako ten muj…
Ale když ten HEX otevře programátor WinPic800 a ICProg, tak si myslím, že v něm chyba není, a nebo jestli je tam něco nestandartního, tak už se to asi standartem stalo.