gnupic: Re: [gnupic] Re: [PATCH] CONFIG feature progress


Previous by date: 24 Jan 2006 18:14:49 +0000 Re: [gnupic] error making lcd, Scott Dattalo
Next by date: 24 Jan 2006 18:14:49 +0000 Re: [gnupic] USB code, PICDEM FS USB and Linux, Ben Dugan
Previous in thread: 24 Jan 2006 18:14:49 +0000 Re: [gnupic] Re: [PATCH] CONFIG feature progress, Chen Xiao Fan
Next in thread: 24 Jan 2006 18:14:49 +0000 Re: [gnupic] Re: [PATCH] CONFIG feature progress, Chen Xiao Fan

Subject: Re: [gnupic] Re: [PATCH] CONFIG feature progress
From: Michael Ballbach ####@####.####
Date: 24 Jan 2006 18:14:49 +0000
Message-Id: <20060124181446.GA19950@wayreth.rten.net>

On Tue, Jan 24, 2006 at 05:28:18PM +0800, Chen Xiao Fan wrote:
> MPASM allows it. I just tried out the 2550tmpo.asm example and I
> add another two asm files with only one line of
> configuration setting in each file. The first one has 
> "CONFIG WRTC = ON" and the second one has "CONFIG BOR = ON".
> 
> From the map files we can see clearly what MPASM/MPLINK are doing. 
> .config_300001_2550TMPO.O  romdata   0x300001    program   0x000001
> .config_300002_2550TMPO2.O romdata   0x300002    program   0x000001
> .config_30000B_2550TMPO1.O romdata   0x30000b    program   0x000001

What is interesting about this is that it means that after linking
object files together, the HEX file will not contain defaults for
configuration bytes that you don't specifically specify. However, when
using relative code, it does seem to fill in the defaults.

Of course, I would consider it good practice to list every configuration
value explicitly for the processor you are working with, but still, it
is an interesting difference that I don't recall being documented in any
specific way.

Now, the curious part is what happens if you specify a configuration
directive in two files that reference the same byte, like CP0 and CP1 do
on certain chips. This should generate the same section in both files,
and unless the linker has special code in it, should prevent it from
linking. Okay, verified, it does prevent it from linking.

So the question is whether this is desirable behavior to imitate - if
we allow spreading CONFIG directives across files, we have three
options:

 1) everything has to be extended to support 1 byte sections (better)
 2) the linker has to be modified to be aware of configuration data
    sections and merge them (hack)
 3) we could support spreading config directives on a word basis between
	files. that is, each word boundary config word would get a section
	and you couldn't specify directives covering either byte in multiple
	files (kinda lame)

> It is still Tuesday Jan 24 2006 here.
> Wed Jan 25 06:07:35 2006  <maybe bug!>

I'm not certain where you are located, but could this time be the time
in GMT at the time you built the object file? Or, at least, is it just
some static offset of hours?

The patch shouldn't have affected this, but it's possible.

-- 
Michael Ballbach, N0ZTQ
####@####.#### -- PGP KeyID: 0xA05D5555
http://www.rten.net/

[Content type application/pgp-signature not shown. Download]

Previous by date: 24 Jan 2006 18:14:49 +0000 Re: [gnupic] error making lcd, Scott Dattalo
Next by date: 24 Jan 2006 18:14:49 +0000 Re: [gnupic] USB code, PICDEM FS USB and Linux, Ben Dugan
Previous in thread: 24 Jan 2006 18:14:49 +0000 Re: [gnupic] Re: [PATCH] CONFIG feature progress, Chen Xiao Fan
Next in thread: 24 Jan 2006 18:14:49 +0000 Re: [gnupic] Re: [PATCH] CONFIG feature progress, Chen Xiao Fan


Powered by ezmlm-browse 0.20.