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:
> 
> 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.
> -- 
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
> 
> 


-----
Best regards,

Philippe.

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

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist