Re: gpdasm 0.13.6 alpha question

Hello,

On Wed, Mar 11, 2009 at 09:41:10PM +0000, Robert Pearce wrote:
I just noticed something else too, suppose the addresses were right, and it
looked like this:

300000:  0804  sublw  0x4
300002:  1e38  comf   0x38, 0x1, 0

I would read that (from left to right) as being:

300000: 08
300001: 04
300002: 1e
300003: 38

But, as far as I can determine, there seems to be an endian swap, and it
really should look like this:

300000:  0408
300002:  381e

leading to:

300000: 04
300001: 08
300002: 38
300003: 1e

Both gpdasm and gpvo do this, and sadly, pk2cmd does this also when I
ask it for the configuration bits. I must say, this screwed me up for a
good long time since I thought the processor was in a certain mode when
it wasn't! Are the other sections printed out like this too?

How would one make gdasm and gpvo smarter to actually print out the
configuration bits is a much more human readable manner?

> (The data sheet doesn't quote that address because it's not real, merely
> conventional. Unlike the configuration data, the EEPROM can't be
> programmed using the tblwt scheme for main programming. Hence the
> 0xF00000 address offset used in the HEX file is only a convention for
> tools, not something imposed by the silicon.)

Could I get a bit more clarification on where the EEPROM addresses are on
PICs in general? It seems a hard thing to pin down.

> Given what you've posted, it appears gpdasm may be misinterpreting the
> "type 04" blocks - the lines of the HEX file that begin ":02000004"

I see. Think this may get fixed before the new release?

Also, is there a better place to report this stuff, like in the wiki or
something? Do I need an account? I'm interested in hacking on gputils
(as my time permits) since I'm using it for several projects of mine.

Thank you.

-pete

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...