Thank you Tony:

I suspect I am just dense on that - I thought that when the data sheet
referred to RAM memory location in the 0x123 format, that they had
eliminated the need for the paging register.  My Mistake. Obviously
I was forcing two variables to occupy the same RAM location, with
the usual great results.

I am a bit surprised that the assembler didn't flag that with a warning,
or that the program ran anyway- just not correctly.  I don't see
exactly why the timer was slowed down, though.

I will have to take a look at the paging issue - I am totally surprised
that they have a 12-bit address for the RAM but still need a page
register.

Roy J. Gromlich



----- Original Message -----
From: "Tony K|bek" <tony.kubek@FLINTAB.COM>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Wednesday, January 14, 2004 3:27 AM
Subject: Re: [PIC]: I hope I am missing something here


> Hi,
>
> Roy J. Gromlich wrote:
> <snip>
> >
> >        TimerLO    equ    0x030
> >        TimerMD    equ    0x031
> >        TimerHI    equ    0x032
> >
> >I load the three variables with a set of starting values and then do a
> mu=
> >ltiple loop on the three timers until they all get to zero. Fairly
> simple=
> >.
> >
> >While moving things around in memory I discovered (as far as I can see)
> t=
> >hat putting the three TimerLO/MD/HI variables anywhere above the 1st
> page=
> > 0x130...0x530 causes the time delay to increase MARKEDLY - like 10X.
> My=
> > scope just died so I can't even continue checking this.
> >
> >I can't see any reason this would happen - the 18Fxxx are supposed to
> acc=
> >ess 6 banks of register files ($0x000..$0x5ff of RAM) directly.  Or am I
> =
> <snip>
>
> Well, first off, you really shouldn't use equ's for declaring variables,
> although unrelated to your particular problem, you should use either:
>
> Relocatable code, in which use something like this:
>
> BANK1_RAM       UDATA ; ram in bank1
> TimerLO RES 1
> TimerMD RES 1
> TimerHI RES 1
>
> (BANK1_RAM needs to be declared in the linker control file)
>
> Or if you absolutely need to write in absolute mode:
>
>         CBLOCK 0x0000 ; access bank
>         TimerLO:1
>         TimerMD:1
>         TimerHI:1
>         ENDC
>
> Anyway, back to your problem, the 18F452 (and family) can access bascilly
> two types of ram, one called access ram which is the lowest 128 bytes of
> available ram 0x0000 - 0x007F (general purpose) and the top 128 bytes of
> ram
> 0x0F7F - 0x0FFF (SFR's). This 'access' ram can be accessed without the
> need for
> switching ram banks.
> However the remaining ram, 0x0080-0x05FF (in the 18F452) needs to have the
> correct
> BSR setting before you try to access them (low nibble high byte 0..5).
> The 18F series are improved upon from the 16F series in many regards, but
> the one
> thing still remaning is the ram bank switching, you do have much more ram
> (not to
> mention 255 bytes continous blocks) but you still need to setup the ram
> bank select register
> BSR.
> Please read the data sheet carefully, this information is essential when
> working with these
> critters.
> Particulary take a look at page 44 in DS39564B (18FXXX2 datasheet).
> In regards to time penalty, there is none, disregarding the actual bank
> switching (1 instr.)
> all ram can be access at the same speed. However as you can see having
> variables sprinkled
> around in the total available ram can give an penalty is you need to
> constanly swithing backNforth
> between them. An thoughtful placing of your variables and using the FSR's
> as much as possible will
> make this essentially an non-issue.
>
>
> /Tony
> ###########################################
>
> This message has been scanned by F-Secure Anti-Virus for Microsoft
> Exchange.
> For more information, connect to http://www.F-Secure.com/
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.