Searching \ for '[PIC] .hex format for PIC18?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: '.hex format for PIC18?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] .hex format for PIC18?'
2009\03\27@063248 by PPA

flavicon
face

Hi,

Here is a snippet of a .hex file generated by MPLINK for a PIC18F4620.
Is somebody can explain me what these lines are for?
:0100010002FC
:010002001AE3
:010003001EDE
:010005008179

I don't understand what these strange records are, since the byte count = 1
and addresses are odd.

Regards,

Philippe.


-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/-PIC--.hex-format-for-PIC18--tp22739114p22739114.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\03\27@063321 by PPA

flavicon
face

Hi,

Here is a snippet of a .hex file generated by MPLINK for a PIC18F4620.
Is somebody can explain me what these lines are for?
:0100010002FC
:010002001AE3
:010003001EDE
:010005008179

I don't understand what these strange records are, since the byte count = 1
and addresses are odd.


-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/-PIC--.hex-format-for-PIC18--tp22739114p22739114.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\03\27@065445 by PPA

flavicon
face



PPA wrote:
{Quote hidden}

Well, after further investigations I found that they are config bits. they
are stored in .hex as single bytes.
Sorry for annoying people with stupid questions.

-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/-PIC--.hex-format-for-PIC18--tp22739114p22739404.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\03\27@070025 by Tamas Rudnai

face picon face
:0100010002FC
:010002001AE3
:010003001EDE
:010005008179

:BBAAAATTHHHH....HHHCC
where:

BB  A two digit hexadecimal byte count representing the number of data
bytes that will appear on the line.
AAAA  A four digit hexadecimal address representing the starting
address of the data record.
TT  A two digit record type that will always be '00' except for the
end-of-file record, which will be '01'.
HH  A two digit hexadecimal data byte, presented in low byte/high byte
combinations.
CC  A two digit hexadecimal checksum that is the two's complement of
the sum of all preceding bytes in the record.


Tamas



On Fri, Mar 27, 2009 at 10:32 AM, PPA <spam_OUTphilippe.paternotteTakeThisOuTspampmpcomp.fr>wrote:

{Quote hidden}

> -

2009\03\27@072657 by Tamas Rudnai

face picon face
Yes, but then you should have a record in front of these like this:

:02 0000 04 0030 CA

(without the spaces)

The TT=04 tells that a new address range is being set.

Tamas

On Fri, Mar 27, 2009 at 10:54 AM, PPA <.....philippe.paternotteKILLspamspam@spam@pmpcomp.fr>wrote:

{Quote hidden}

> -

2009\03\27@074758 by olin piclist

face picon face
PPA wrote:
> Here is a snippet of a .hex file generated by MPLINK for a PIC18F4620.
> Is somebody can explain me what these lines are for?
>> 0100010002FC
>> 010002001AE3
>> 010003001EDE
>> 010005008179

That's not a HEX file.  HEX file lines start with ":".


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\27@075327 by olin piclist

face picon face
PPA wrote:
> Here is a snippet of a .hex file generated by MPLINK for a PIC18F4620.
> Is somebody can explain me what these lines are for?
>
>:0100010002FC
>:010002001AE3
>:010003001EDE
>:010005008179

I just realized the OE with QuoteFix converted ":" to ">" when I did a reply
and the original does indeed contain the leading colons.

This HEX file snippet contains the following data (all values in HEX):

 Address  Data
 -------  ----
    0001    02
    0002    1A
    0003    1E
    0005    81

Note that the high address bits are unknown just by looking at this snippet
alone.  As to why that data it at those addresses, that's up to your source
code.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\27@081234 by Alan B. Pearce

face picon face
>TT  A two digit record type that will always be '00' except
>for the end-of-file record, which will be '01'.

There can be other record types than those. I don't know if Microchip
actually use the other record types.

2009\03\27@084219 by Xiaofan Chen

face picon face
On Fri, Mar 27, 2009 at 8:12 PM, Alan B. Pearce
<Alan.B.PearcespamKILLspamstfc.ac.uk> wrote:
>>TT  A two digit record type that will always be '00' except
>>for the end-of-file record, which will be '01'.
>
> There can be other record types than those. I don't know if Microchip
> actually use the other record types.
>

Yes they are used.

Box Axtell asked for the Microchip hex32 format before and it
is in an old version of MPASM user's guide.

http://gputils.sourceforge.net/33014g.pdf
Page 173.

32-Bit Hex Format (.HEX)
       TT – is a two digit record type:
            00 – Data record
            01 – End of File record
            02 – Segment address record
            04 – Linear address record

Regards,
Xiaofan

2009\03\27@091256 by PPA

flavicon
face

Hi Olin,
No offense; this time you answered fastest than your shadow ;-)
Thanks for this explanation; I know about .hex format, I just had some
trouble with single byte records in the PIC context, I was dealing with
PIC16 before and never see this. I wrote some tools for dealing with .hex
files in the PIC context and I got errors with those records. Before this I
saw only code records that was always at even addresses with always an even
size (two bytes per PIC word)...
Finally I found that these records are for PIC18 configuration bits. They
are stored as single bytes. Strange but why not...


Olin Lathrop wrote:
{Quote hidden}

> --

2009\03\27@095300 by olin piclist

face picon face
Alan B. Pearce wrote:
> There can be other record types than those. I don't know if Microchip
> actually use the other record types.

They do.  You can only address 0-FFFFh without using other record types.

********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\27@100416 by Alan B. Pearce

face picon face
>Finally I found that these records are for PIC18 configuration bits.
>They are stored as single bytes. Strange but why not...

I think only the low 8 bits of each configuration word is used, hence they
need to have only a single byte at each address. If they had more than one
byte in each line, it would be seen as more than 8 bits at that address.

2009\03\27@120440 by PPA

flavicon
face

Alan,

Not exactly:
Other record addresses are even addresses so you have one byte for the even
address and one byte for the odd address, that gives one word of PIC code,
PIC addresses are always even, so we can say there is one byte per byte
address too.
Configuration bits are located at 300000h and use 8 byte addresses (in most
cases), but they can be coded as 4 words if you org 300000h / data generate
them directly in your source code. They have high byte, these high bytes are
those xxH coded configuration bits (along with xxL coded ones).
The system adopted by Microchip is not too coherent. Why not using the same
scheme for code and configuration data? In .hex files, why use word
addresses for code instead of byte addresses? Also this is not coherent with
TBLPTR witch is a byte pointer to code segment addresses...
Well, we may spend very long time on MC specificities. We have to make with,
no alternative.
I wonder why to make things so complicated?


Alan B. Pearce-2 wrote:
>
>>Finally I found that these records are for PIC18 configuration bits.
>>They are stored as single bytes. Strange but why not...
>
> I think only the low 8 bits of each configuration word is used, hence they
> need to have only a single byte at each address. If they had more than one
> byte in each line, it would be seen as more than 8 bits at that address.
>
> --

2009\03\27@133301 by olin piclist

face picon face
PPA wrote:
> PIC addresses are always even,

Huh?  You need to go read the datasheet for your PIC 18.

> Configuration bits are located at 300000h and use 8 byte addresses (in
> most cases),

Again, you need to read the datasheet.  The config address range for most
PIC 18 is 300000h-30000Dh with a few in there not used.  However, both odd
and even addresses of that range are used.

> but they can be coded as 4 words if you org 300000h / data
> generate them directly in your source code.

You'd be a lot safer off using DB in CODE_PACK sections.

> The system adopted by Microchip is not too coherent. Why not using the
> same scheme for code and configuration data?

They do.  The program memory, including the configuration region, of all PIC
18 is byte addressed.

> In .hex files, why use word addresses for code instead of byte
> addresses?  Also this is not coherent with TBLPTR witch is a byte
> pointer to code segment addresses...

What is not coherent is your thinking.

Program memory is a collection of 8 bit bytes.  That's how it's stored in
the HEX file and that's how it's accessed with the table read mechanism via
TBLPTR.  It all makes sense (for those that have bothered to read the
manual, of course).

> I wonder why to make things so complicated?

They didn't.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\28@035911 by PPA

flavicon
face

Olin,


Olin Lathrop wrote:
>
> PPA wrote:
>> PIC addresses are always even,
> Huh?  You need to go read the datasheet for your PIC 18.
>

You like to play on words... In this case it is a bit unfair:
First, I wasn't speaking about PIC architecture in general but about .hex
format.
Second, PIC16 addresses are by one step, PIC18 are by 2 steps, making a bit
more
difficult to use lookup tables that you like, Olin.
For PIC18, "real" addresses are always even, but architecture is byte
oriented so they
made an arbitrary mix of byte / word of code addressing with such funny
things as
goto $+1 that would jump into the middle of the an instruction...


Olin Lathrop wrote:
>
> PPA wrote:
>> Configuration bits are located at 300000h and use 8 byte addresses (in
>> most cases),
>
> Again, you need to read the datasheet.  The config address range for most
> PIC 18 is 300000h-30000Dh with a few in there not used.  However, both odd
> and even addresses of that range are used.
>

I agree that configuration bytes are 300000h-300000Dh, I wrote a bit too
fast but
that was not the subject. it was that PIC18 one byte instruction is
meaningless,
so odd code addresses are meaningless so why one byte records for
configuration bits,
with odd addresses?


Olin Lathrop wrote:
>
> PPA wrote:
>> but they can be coded as 4 words if you org 300000h / data
>> generate them directly in your source code.
>
> You'd be a lot safer off using DB in CODE_PACK sections.
>
Yeah, it was just to say that we can do it...


Olin Lathrop wrote:
{Quote hidden}

Maybe. What is sure is that I'm not always thinking like MC or you Olin...
May I have my own opinion Olin?


Olin Lathrop wrote:
>
> Program memory is a collection of 8 bit bytes.  That's how it's stored in
> the HEX file and that's how it's accessed with the table read mechanism
> via
> TBLPTR.  It all makes sense (for those that have bothered to read the
> manual, of course).
>
Again and again... Please stop thinking that people don't read datasheets or
manuals everytime, I'm involved in PICs for years (less in PIC18, so my
errors),
I wrote a not so bad optimizing compiler just for fun... Sometimes you are
too
agressive Olin, but I like to read your answers, they are never for
nothing...
Indeed.


-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/-PIC--.hex-format-for-PIC18--tp22739114p22754516.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\03\28@080259 by Tamas Rudnai

face picon face
On Sat, Mar 28, 2009 at 7:59 AM, PPA <.....philippe.paternotteKILLspamspam.....pmpcomp.fr> wrote:

> For PIC18, "real" addresses are always even, but architecture is byte
> oriented so they
> made an arbitrary mix of byte / word of code addressing with such funny
> things as
> goto $+1 that would jump into the middle of the an instruction...
>

I think that would cause a reset. Anyway, the so called 'program memory' is
not only to store program, but constant data as well - you do not need to
use jump tables for reading out the elements of an array anymore on 18F but
a simple TBLRD instruction which can easily address each one of the bytes on
the program memory - so why not to store these constants on odd addresses?

BTW: Is your compiler available to the public?

Tamas
--
http://www.mcuhobby.com

2009\03\28@085112 by olin piclist

face picon face
PPA wrote:
>>> PIC addresses are always even,
>>
>> Huh?  You need to go read the datasheet for your PIC 18.
>
> You like to play on words... In this case it is a bit unfair:
> First, I wasn't speaking about PIC architecture in general but about
> .hex format.

Your statement is still just plain wrong no matter how you look at it.
Every PIC has both odd and even program memory addresses and every PIC HEX
file can contain data for those odd and even addresses, and the HEX files
use both odd and even addresses internally.

> Second, PIC16 addresses are by one step, PIC18 are by 2 steps, making
> a bit more difficult to use lookup tables that you like, Olin.

I thought you were talking about program memory addressing and how it is
represented in the HEX file.  This is the first mention I recall of lookup
tables, and I don't see how they have anything to do with the discussion.
You had also previously been talking specifically about PIC 18, so that is
what my comments were in regard to, as I also stated and you even quoted
above.

However since you brought it up, tables in program memory are actually a bit
easier on an PIC 18 than a PIC 16.  On a PIC 18, program memory is addressed
as 8-bit bytes.  That is convenient since the data registers are also 8 bits
wide.  Furthermore, the auto-increment table read instructions make reading
sequential bytes easier.

In contrast, the PIC 16 (I mean 14 bit core by this) addresses program
memory at 14 bit words.  That makes it more awkward to store data that is
ultimately used 8 bits at a time.  There is also no auto-increment feature
for addressing sequential words, and the low 8 bits and the high 6 bits have
to be dealt with separately.

> For PIC18, "real" addresses are always even, but architecture is
> byte oriented so they made an arbitrary mix of byte / word of code
> addressing with such funny things as goto $+1 that would jump into
> the middle of the an instruction...

This engineering, not voodoo.  Odd program memory addresses of a PIC 18
aren't unreal or imaginary.  They are every bit as real as the even
addresses.

Your confusion seems to come from the fact that PIC 18 opcodes are always 2
or 4 bytes long and are always aligned to start on a even address.
Therefore *execution* addresses on a PIC 18 are always even.  However, that
does not restrict arbitrary data or anything else that isn't a opcode from
being byte wide and being stored at odd addresses.  Examples of such
arbitrary data are the config bytes, the user ID bytes, and any data you
want to store in program memory, like tables or constants.

> it was that PIC18 one byte instruction is meaningless, so odd code
> addresses are meaningless so why one byte records for configuration
> bits, with odd addresses?

Because configuration bits aren't code.  As you say, odd *code* addresses
are meaningless (illegal, actually), but data can still be stored at odd
addresses in program memory.

> Maybe. What is sure is that I'm not always thinking like MC or you
> Olin...  May I have my own opinion Olin?

We're talking about matters of fact, not opinion.  The PIC 18 program memory
addressing is well explained in the datasheet.  What you were saying about
it was just plain wrong.

> Again and again... Please stop thinking that people don't read
> datasheets or manuals everytime,

Then stop making incorrect statements for things clearly described in the
datasheet.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\29@051240 by PPA

flavicon
face

Olin,

To be honest, finally I think you are right, as often...

Yes, datasheets are facts not voodoo as you said (well sometimes, we may
feel
that's voodoo until errata sheets comes).
Is reading datasheets should be seen as a science?
Good (right) interpretation is sometimes difficult.
Datasheets should not need interpretation.
Can you really say that you never made mistakes when reading datasheets
Olin?

Well, the primary subject was on .hex files. I wrote a tool that had a bug
with .hex
files generated for PIC18.
I just wonder why this bug had come; it was a bad "interpretation" of .hex
format
as used by MC, not of the MC MCUs datasheets. I was wrong, now I see why.
Thanks to everybody for this discussion, I think that this subject may be
closed.

Then we've forked to architecture. It was not really where I wanted to go...
Yes, I may have my opinion on MC ways. I like a lot their products, but I
continue
to say that some parts of PIC18 architecture are strange, said more strange
than
PIC16. Who can say he had never experienced "surprises" with MC products?
Maybe we can say this is an evolution (I've not read about "evolutions" in
PIC24 and others). Some of architecture "evolutions" had bothered me to
adapt
my tools, I experienced a lot of "surprises". OK. As I said before, we have
to do
with and the good things are more important.


Olin Lathrop wrote:
{Quote hidden}

> --

2009\03\29@052704 by PPA

flavicon
face

Hi Tamas

Just follow the link on my signon...


Tamas Rudnai wrote:
>
> BTW: Is your compiler available to the public?
>


-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/-PIC--.hex-format-for-PIC18--tp22739114p22765759.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\03\29@103746 by olin piclist

face picon face
PPA wrote:
> Yes, I may have my opinion on MC ways. I like a lot their products,
> but I continue to say that some parts of PIC18 architecture are
> strange, said more strange than PIC16.

Like what?  The PIC 18 architecture gets rid of some of the awkwardness of
the PIC 16 architecture that are there due to tradeoffs with core size,
cost, and speed.  The PIC 18 architecture still has tradeoffs like that, as
all architectures do to some extent, but I can't think of anything that is
more awkward on a PIC 18 than a PIC 16.

> Who can say he had never experienced "surprises" with MC
> products?

Everyone makes a occasional mistake, but what pisses me off is when they try
to avoid looking stupid by blaming it on someone else.  You wrote code to
interpret HEX files and for some unfathomable reason designed it in such a
way that it couldn't handle single bytes at odd addresses.  Duh.  The HEX
file format was created many years ago and is well described in many places,
including in some Microchip documentation.  Even if you thought Microchip
used only a subset of it, just good software engineering alone should have
told you that your special case implementation was a bad idea.  HEX files
are so simple that interpreting them correctly is trivial enough.  I doubt
not allowing for single bytes at odd addresses makes interpreting them any
easier.

We all do stupid things on occasion.  The right answer is to say oops, slap
yourself on the head, then go fix it.  Unfortunately a few people feel the
need to blame everyone else for their stupidity.  This is the same attitude
that causes a freshman engineering student who just learned to spell "C" a
few weeks ago run around proclaiming there is a bug in the compiler because
his perfect program won't run.  Of course instead of saving face as
intended, it only broadcasts the stupidity to a wider audience.  Continuing
to defend his "perfect" code just makes him look more and more stupid.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\30@094027 by PPA

flavicon
face

Olin,

Sometimes you are making "definitive assumptions" with fragments of
evidences...
People may feel hurted by that.
Not me. I don't feel concerned by your shots on "stupid freshman engineering
students".
I've nothing to justify. Maybe I may explain.
You like facts, here are facts:
I'm 50 now, and 30 years in programming, most of these years on micros and
controllers.
I saw many things, I wrote many tools in my life, one of them was a simple
tool
for .hex file analysis / display. It worked fine.
One day I tried to use it with .hex files generated by MPLAB for PIC10/12/16
series
and it fails. Why? Because MC had mapped more than 8 bits in one address and
coded it at even addresses in the .hex so that PC address 1 is address 2 in
.hex,
PC address 2 is address 4 in .hex and so on, so we have to divide by 2 to
have
the real PC address. I said strange. That's strange.
Well, no complain, I adapted my tool and it worked well again.
Then came PIC18 family. The tool fails again, because with the new
architecture,
MC came back to the standard (?), PC address 2 is now address 2 in the .hex,
no need to divide by 2 the .hex address, and we see again odd addresses that
was meaningless in the model adopted for PIC10/12/16... My unmodified tool
would
have worked fine on PIC18!
I said strange. Yes.
So now my tool needs to know what is the family to display good
informations.
What is incoherent?
Who is to blame?
You said "HEX files are so simple that interpreting them correctly is
trivial enough".
Let me laugh a bit...


Olin Lathrop wrote:
{Quote hidden}

> --

2009\03\30@100856 by olin piclist

face picon face
PPA wrote:
> One day I tried to use it with .hex files generated by MPLAB for
> PIC10/12/16
> series
> and it fails. Why? Because MC had mapped more than 8 bits in one
> address and
> coded it at even addresses in the .hex so that PC address 1 is
> address 2 in .hex,
> PC address 2 is address 4 in .hex and so on, so we have to divide by
> 2 to
> have
> the real PC address. I said strange. That's strange.

It's not strange at all.  What alternative would you have used to define 12
and 14 bit words in a HEX file?

Once again you got bit by something even though it's well documented, then
go around saying the implementation is "strange".  If you had bothered
understanding why it is the way it is, it wouldn't be strange.  Again, how
would you have done it?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...