gnupic: Re: [gnupic] about data tables and shared variables
Subject:
Re: [gnupic] about data tables and shared variables
From:
Robert Pearce ####@####.####
Date:
30 Aug 2008 23:18:34 -0000
Message-Id: <MnndXkZv3cuIFwIc@daniel.huneausware.local>
On Sat, 30 Aug 2008, Lope Vega ####@####.#### wrote :
>
>My problem is that if I define a udata_shr block let's say in my main
>file:
>
>myvars udata_shr
>my_global_var res 1
>
>Then, whenever I try to use it on other module I get an "`my_global_var
>symbol is undefined" message, and I haven't seen some sort of "global"
>or "extern" directive I should use so as to let my other module know
>that was a variable declared as shared within the main one.
>
As Jeff said, the owner needs to declare the variable global and all the
clients need to declare it extern
However, looking through this thread I've just had a nasty hunch that
maybe you're getting confused about "share" memory. Forgive me if I'm
wrongly impugning you, but...
There are three classifications of RAM that the linker worries about,
and two classes of data that goes in them. On the latter, "udata" is
uninitialised (or commonly set to zero at start) and will be declared
using "res" directives, whereas "idata" is initialised (providing you've
written the necessary start-up code) and will be declared using "db" or
"dw". But it's the former that's of interest here.
Normal RAM, declared with a "udata" or "idata" directive, is single
instance memory, where each variable declared within it exists exactly
once and each memory location appears in one variable. For most
variables, especially globals, this is what you want.
Variables declared in a block defined as "udata_shr" are shared memory.
This does NOT mean the variables are shared with other files (that's
what "global" means). In fact it's probably quite the opposite. What it
means is that the RAM location occupied by the variable may well be
shared by another variable in a different file. So you'd only want to
use this for space saving, and the variables you'd put there will be
local temporary results or, perhaps, library function arguments.
The third type of RAM is probably of little interest (much more relevant
on 14-bit cores). This is "udata_ovr" memory, which is "overlayed". This
means that the RAM it represents exists in several banks, or from a full
memory map perspective it's shadowed at different addresses. Typically
you would use this for saving working registers in an ISR, because you
don't need to know the state of the register page select bits before
accessing it. Since the 18F core uses a different approach to RAM bank
selection, overlay regions are not relevant.
--
Rob Pearce http://www.bdt-home.demon.co.uk
The contents of this | Windows NT crashed.
message are purely | I am the Blue Screen of Death.
my opinion. Don't | No one hears your screams.
believe a word. |
