> If you have a project with a single asm file linked with absolute mode
> (which probably accounts for the majority of small projects rightly or
> wrongly), then why would you have 2 CBLOCKs for your variables?

I can see only two 'legal' reasons, one is that because there are more than
one ram area that are located in non-continuous places, and two because you
would like to have overlayed data usage.

Tamas


On Tue, Jun 17, 2008 at 6:36 PM, Michael Rigby-Jones <
Michael.Rigby-Jones@bookham.com> wrote:

>
>
> > -----Original Message-----
> > From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On
> Behalf
> > Of Jan-Erik Soderholm
> > Sent: 17 June 2008 16:39
> > To: Microcontroller discussion list - Public.
> > Subject: Re: [PIC] 16F887 and corrupted RAM/EEPROM
> >
> > Wouter van Ooijen wrote:
> > > Olin Lathrop wrote:
> > >> alan smith wrote:
> > >>> The
> > >>> original author used the cblock directive, but hardcoded some
> > >>> variables at the bottom end of the RAM, and as I added some
> > >>> additional variables it wrote over the top a couple of these.
> > >> So anyone out there still wonder why you should always use RES to
> > reserve
> > >> RAM?
> > >
> > > If I would this would not convince me: always CBLOCK would have
> > > prevented that error too. Hardcoding is the evil here, not CBLOCK.
> > >
> >
> > I'm not sure I understand here.
> > Two CBLOCK's can overlap, not ?
>
> If you have a project with a single asm file linked with absolute mode
> (which probably accounts for the majority of small projects rightly or
> wrongly), then why would you have 2 CBLOCKs for your variables?
>
> Regards
>
> Mike
>
> =======================================================================
> This e-mail is intended for the person it is addressed to only. The
> information contained in it may be confidential and/or protected by
> law. If you are not the intended recipient of this message, you must
> not make any use of this information, or copy or show it to any
> person. Please contact us immediately to tell us that you have
> received this e-mail, and return the original to us. Any use,
> forwarding, printing or copying of this message is strictly prohibited.
> No part of this message can be considered a request for goods or
> services.
> =======================================================================
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



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