Bob Ammerman wrote:
> Would it be reasonable to create a single byte section in the .LKR file,
> just to hold the WREG on interrupt.
>
> Where multiple banks exist (but no common memory) this section would be
> in one of the banks and the other banks would be 'shorted' by omitting
> their corresponding byte.
>
> When only one bank exists you have nothing special to do.
>
> When you have shared memory you put the WREG save spot in the shared
> space and reduce the size of the 'user-visible' shared area by the one
> byte.

That would work, but I prefer to keep this information in the source code.
I like to think of the linker file as describing the hardware, and the
source code describing how the hardware is used.  After all, there is no
guarantee there will even be an interrupt routine.

I have a separate section in STD_DEF.INS.ASPIC for each supported PIC.
This provides an opportunity to set assembly time state unique for each
PIC.  This state already includes the number of RAM banks, and whether
there is unbanked memory, where, and how long.  This means I should be
able to add some logic to the INTR module to define W_SAVE appropriately
even on PICs that don't have unbanked RAM.  However, there may be other
problems when there is no unbanked memory.  I don't like to release code I
haven't tested.  Since I've never used a PIC with unbanked memory (and
probably never will), I guess I could just detect this case and emit an
assembly time error for now.

The problem Jan-Eric ran into was due to the PIC having ONLY unbanked
memory.  I guess the right way to handle this is to add more assembly time
configuration state so that this configuration can be detected, then
define all RAM as one SHAREBANK section in the linker file.  DEFRAM would
need to be smart enough to not emit UDATA in this case, only UDATA_SHR.
This is too big a change for me to feel comfortable updating the code
without having tested it on a real project.  I've got some projects on
12F629, 12F675, and 16F630.  Next time I mess with one of those I'll try
to convert everything over and release the result once I'm sure it's
working properly.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu