about data tables and shared variables

[Lope Vega]

Hello again guys,

First of all, do you recall in my last message when I said all the problems dissapeared for me as soon as I grounded RB3? My mistake, I was tryin to refer to RB5, which I've even read within the specs, should be grounded whether it's not being used.

Said and solved that, I'm running into two problems I cannot cope with, and for which I'd be glad to hear anything about.

One of them is about data tables. I'm trying to drive 3 7-segment displays which I've got multiplexed. Since I don't really yet understand table reads/writes, and haven't seen an example which adequates to what I'm doing, I thought on using `computed gotos':

; make sure they're placed at the begining of a page
my_table_code  code  0x200

my_table:
  addwf pcl, f
  retlw b'01000000' ; number 0
  ......            ; number 1

display:
  ; call my table, which will use the value on the `w' register
  call my_table
  ; actually display the number
  movwf latb
  ; and return
  retlw 0x0

The problem I'm having is that the PC gets lost.

Though I've been reading within the piclist's archives about how to solve it (working arround with PCLATH), I haven't been able to, so if anyone knows of some example code about this, or about using table reads I can apply to this, or even could write some example code I could start off with, that would be great.

The other problem I'm finding is about shared variables, which would make my life much easier. I have changed the line:

DATABANK   NAME=usb4       START=0x400          END=0x4FF          PROTECTED

within the default linker script for the pic18f4550, with:
SHAREBANK  NAME=usb4       START=0x400          END=0x4FF

I've read the specs says it is risky at best to do this (because of dynamic buffers' allocation policy it claims) but I won't be using USB by now, and any of the ways, as far as I can tell the problem I'm having hasn't got nothing to do with it, as I've tried with other script's lines.

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.

Any comments appreciated,

Many Thanks.



__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.es


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Noel Henson]

I've had some trouble in the past with this. Don't know if this will help
but try placing a NOP after the addwf PCL,f. The other thing you will want
to check is to make sure that your table does not cross a 256-byte
boundary. If it does, you could actually be branching to to before the
beginning of the table when you access table values that are above the next
256-byte boundary.

I hope this helps,

Noel

On Saturday 30 August 2008, Lope Vega wrote:

> Hello again guys,
>
> First of all, do you recall in my last message when I said all the
> problems dissapeared for me as soon as I grounded RB3? My mistake, I was
> tryin to refer to RB5, which I've even read within the specs, should be
> grounded whether it's not being used.
>
> Said and solved that, I'm running into two problems I cannot cope with,
> and for which I'd be glad to hear anything about.
>
> One of them is about data tables. I'm trying to drive 3 7-segment
> displays which I've got multiplexed. Since I don't really yet understand
> table reads/writes, and haven't seen an example which adequates to what
> I'm doing, I thought on using `computed gotos':
>
> ; make sure they're placed at the begining of a page
> my_table_code  code  0x200
>
> my_table:
>   addwf pcl, f
>   retlw b'01000000' ; number 0
>   ......            ; number 1
>
> display:
>   ; call my table, which will use the value on the `w' register
>   call my_table
>   ; actually display the number
>   movwf latb
>   ; and return
>   retlw 0x0
>
> The problem I'm having is that the PC gets lost.
>
> Though I've been reading within the piclist's archives about how to
> solve it (working arround with PCLATH), I haven't been able to, so if
> anyone knows of some example code about this, or about using table reads
> I can apply to this, or even could write some example code I could start
> off with, that would be great.
>
> The other problem I'm finding is about shared variables, which would
> make my life much easier. I have changed the line:
>
> DATABANK   NAME=usb4       START=0x400          END=0x4FF        
> PROTECTED
>
> within the default linker script for the pic18f4550, with:
> SHAREBANK  NAME=usb4       START=0x400          END=0x4FF
>
> I've read the specs says it is risky at best to do this (because of
> dynamic buffers' allocation policy it claims) but I won't be using USB
> by now, and any of the ways, as far as I can tell the problem I'm having
> hasn't got nothing to do with it, as I've tried with other script's
> lines.
>
> 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.
>
> Any comments appreciated,
>
> Many Thanks.
>
>
>
> __________________________________________________
> Correo Yahoo!
> Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> Regístrate ya - http://correo.yahoo.es
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Jerry Zdenek]

The CALL instruction doesn't update PCLATH.  So when you add W to PCL,
PC[15:8] gets whatever is left in PCLATH, causing you to jump apparently
randomly.  Set PCLATH  first and you should be fine.  You should also
make sure PCLATU is cleared just in case it got changed, as that gets
fed into PC as well.

This should work (but I haven't tried it):

  my_table_code  code  0x200

  my_table:

    movwf  temp_var

    clrf  PCLATU
    movlw HIGH my_table
    movwf PCLATH

    movf tmp_var,W

    addwf pcl, f
    retlw b'01000000' ; number 0
    ....

As for your second problem, at least in MPASM, you need to declare your
variable global as such:
    GLOBAL my_global_var

And then when you use it:
    extern my_global_var

Jerry


Noel Henson wrote:

> I've had some trouble in the past with this. Don't know if this will help
> but try placing a NOP after the addwf PCL,f. The other thing you will want
> to check is to make sure that your table does not cross a 256-byte
> boundary. If it does, you could actually be branching to to before the
> beginning of the table when you access table values that are above the next
> 256-byte boundary.
>
> I hope this helps,
>
> Noel
>
> On Saturday 30 August 2008, Lope Vega wrote:
>> Hello again guys,
>>
>> First of all, do you recall in my last message when I said all the
>> problems dissapeared for me as soon as I grounded RB3? My mistake, I was
>> tryin to refer to RB5, which I've even read within the specs, should be
>> grounded whether it's not being used.
>>
>> Said and solved that, I'm running into two problems I cannot cope with,
>> and for which I'd be glad to hear anything about.
>>
>> One of them is about data tables. I'm trying to drive 3 7-segment
>> displays which I've got multiplexed. Since I don't really yet understand
>> table reads/writes, and haven't seen an example which adequates to what
>> I'm doing, I thought on using `computed gotos':
>>
>> ; make sure they're placed at the begining of a page
>> my_table_code  code  0x200
>>
>> my_table:
>>   addwf pcl, f
>>   retlw b'01000000' ; number 0
>>   ......            ; number 1
>>
>> display:
>>   ; call my table, which will use the value on the `w' register
>>   call my_table
>>   ; actually display the number
>>   movwf latb
>>   ; and return
>>   retlw 0x0
>>
>> The problem I'm having is that the PC gets lost.
>>
>> Though I've been reading within the piclist's archives about how to
>> solve it (working arround with PCLATH), I haven't been able to, so if
>> anyone knows of some example code about this, or about using table reads
>> I can apply to this, or even could write some example code I could start
>> off with, that would be great.
>>
>> The other problem I'm finding is about shared variables, which would
>> make my life much easier. I have changed the line:
>>
>> DATABANK   NAME=usb4       START=0x400          END=0x4FF        
>> PROTECTED
>>
>> within the default linker script for the pic18f4550, with:
>> SHAREBANK  NAME=usb4       START=0x400          END=0x4FF
>>
>> I've read the specs says it is risky at best to do this (because of
>> dynamic buffers' allocation policy it claims) but I won't be using USB
>> by now, and any of the ways, as far as I can tell the problem I'm having
>> hasn't got nothing to do with it, as I've tried with other script's
>> lines.
>>
>> 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.
>>
>> Any comments appreciated,
>>
>> Many Thanks.
>>
>>
>>
>> __________________________________________________
>> Correo Yahoo!
>> Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
>> Regístrate ya - http://correo.yahoo.es
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: gnupic-unsubscribe@...
>> For additional commands, e-mail: gnupic-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Lope Vega]

Thanks a lot guys,

I've got it now more or less solved.

Also, the problem with shared variables was solved as you pointed out Jerry, my fault was placing the `global digit' before it's declaration itself, as I also tried what you said before.

Just beg me another question, though.

What I'm trying to do is to have a switch counting till 100, which after reached, will get set back to 0; all of this while being displayed whatever the current value of the counter variable on these three seven segment displays.

My question is about how to handle it. Should I place on my main function the debouncing routine for the switch, and then perhaps an interrupt for timer0 so the actual `count' will get displayed all the time? or would be better the opossite way, or anyother I can't think of?

I haven't got a clue on how structure the program to handle this while not letting it get blocked either, because of waiting for debouncing (display flickers), or for updating the display (not giving the switch the priority it deserves).

Many thanks,


--- El sáb, 30/8/08, Jerry Zdenek <zdenekjs@...> escribió:

> De: Jerry Zdenek <zdenekjs@...>
> Asunto: Re: [gnupic] about data tables and shared variables
> Para: gnupic@...
> Fecha: sábado, 30 agosto, 2008 5:55
> The CALL instruction doesn't update PCLATH.  So when you
> add W to PCL,
> PC[15:8] gets whatever is left in PCLATH, causing you to
> jump apparently
> randomly.  Set PCLATH  first and you should be fine.  You
> should also
> make sure PCLATU is cleared just in case it got changed, as
> that gets
> fed into PC as well.
>
> This should work (but I haven't tried it):
>
>   my_table_code  code  0x200
>
>   my_table:
>
>     movwf  temp_var
>
>     clrf  PCLATU
>     movlw HIGH my_table
>     movwf PCLATH
>
>     movf tmp_var,W
>
>     addwf pcl, f
>     retlw b'01000000' ; number 0
>     ....
>
> As for your second problem, at least in MPASM, you need to
> declare your
> variable global as such:
>     GLOBAL my_global_var
>
> And then when you use it:
>     extern my_global_var
>
> Jerry
>
>
> Noel Henson wrote:
> > I've had some trouble in the past with this.
> Don't know if this will help
> > but try placing a NOP after the addwf PCL,f. The other
> thing you will want
> > to check is to make sure that your table does not
> cross a 256-byte
> > boundary. If it does, you could actually be branching
> to to before the
> > beginning of the table when you access table values
> that are above the next
> > 256-byte boundary.
> >
> > I hope this helps,
> >
> > Noel
> >
> > On Saturday 30 August 2008, Lope Vega wrote:
> >> Hello again guys,
> >>
> >> First of all, do you recall in my last message
> when I said all the
> >> problems dissapeared for me as soon as I grounded
> RB3? My mistake, I was
> >> tryin to refer to RB5, which I've even read
> within the specs, should be
> >> grounded whether it's not being used.
> >>
> >> Said and solved that, I'm running into two
> problems I cannot cope with,
> >> and for which I'd be glad to hear anything
> about.
> >>
> >> One of them is about data tables. I'm trying
> to drive 3 7-segment
> >> displays which I've got multiplexed. Since I
> don't really yet understand
> >> table reads/writes, and haven't seen an
> example which adequates to what
> >> I'm doing, I thought on using `computed
> gotos':
> >>
> >> ; make sure they're placed at the begining of
> a page
> >> my_table_code  code  0x200
> >>
> >> my_table:
> >>   addwf pcl, f
> >>   retlw b'01000000' ; number 0
> >>   ......            ; number 1
> >>
> >> display:
> >>   ; call my table, which will use the value on the
> `w' register
> >>   call my_table
> >>   ; actually display the number
> >>   movwf latb
> >>   ; and return
> >>   retlw 0x0
> >>
> >> The problem I'm having is that the PC gets
> lost.
> >>
> >> Though I've been reading within the
> piclist's archives about how to
> >> solve it (working arround with PCLATH), I
> haven't been able to, so if
> >> anyone knows of some example code about this, or
> about using table reads
> >> I can apply to this, or even could write some
> example code I could start
> >> off with, that would be great.
> >>
> >> The other problem I'm finding is about shared
> variables, which would
> >> make my life much easier. I have changed the line:
> >>
> >> DATABANK   NAME=usb4       START=0x400        
> END=0x4FF        
> >> PROTECTED
> >>
> >> within the default linker script for the
> pic18f4550, with:
> >> SHAREBANK  NAME=usb4       START=0x400        
> END=0x4FF
> >>
> >> I've read the specs says it is risky at best
> to do this (because of
> >> dynamic buffers' allocation policy it claims)
> but I won't be using USB
> >> by now, and any of the ways, as far as I can tell
> the problem I'm having
> >> hasn't got nothing to do with it, as I've
> tried with other script's
> >> lines.
> >>
> >> 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.
> >>
> >> Any comments appreciated,
> >>
> >> Many Thanks.
> >>
> >>
> >>
> >> __________________________________________________
> >> Correo Yahoo!
> >> Espacio para todos tus mensajes, antivirus y
> antispam ¡gratis!
> >> Regístrate ya - http://correo.yahoo.es
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> gnupic-unsubscribe@...
> >> For additional commands, e-mail:
> gnupic-help@...
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail:
> gnupic-help@...

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.es


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Lope Vega wrote:
> My question is about how to handle it.

A matter of taste really.

I suggest having main scanning over the LEDs and to have an
interrupt-on-change for the switch input. When the switch interrupt
fires, start timer 0. If another switch interrupt fires then restart
timer 0. When the timer 0 interrupt fires the input has been
debounced so update the values that main displays on the LEDs.

This does not scale for many inputs but if you only want one input
it's a simple solution. You can of course add a little multiplexing
code to allow handling more inputs.


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Lope Vega]

Thanks a lot for those quick and wise replies guys,

Well, my goal is to have four switches in total, as follows:

* one as the counter (which increments it each valid pulse).
* for the last three: one adds, other substracts, and the last enters/exit editing mode. These would add and substract from let's say a variable called `target' which would always be the number the counter should count up to.

What I'd love to do is to have the display running as normal (not difficult on it's own), but when the enter/exit button is pressed, the displays' refreshing rate would become slower, thus, blinking while showing the value of `target' to be (or not) modified.

Then, one could set new value and press the enter/exit button (or also let it take effect through a timeout), which would since then take effect.

That way, which makes everything twice as complex, I shouldn't need to hardcode the `target' value on the pic. While it will usually be 100, on rare ocassions I might need it to be 90.

Once `target' has been reached, a stepper motor to move 90  degrees forward, wait till another valid pulse has been seen, and then return it to it's initial position.

This is for a machine up in my family's factory where I'm trying to get rid of a pneumatic piston/electro-valve system driven by an omrom digital counter, which, perhaps because of vibrations, uses to get rendered unusable quite often, and they are quite expensive (about 300 euros).

Appart from that, the fact of being based on pneumatic with no apparent reason (both the torque needed and the length of the automatism is very little), implies having an air-compressor being turned on all the time. In this case, that air-compressor consumes about twice than the machine itself, so I'm seeing it as not worthy at all as the times goes by.
 
So I guess what you suggested is the right way to go. I just setup interrupts for the buttons, and when one is seen, I could discard if not applicable (i.e: the `add' button was pressed but the device hasn't fallen into `editing mode' [the enter/exit button wasn't pressed]), etc.

Once I get more experience, I'd also like to see the variable `counter' being updated in rom (after each valid pulse), though I guess I should use an external eeprom so I'm not killing the pic (due to the "limited" number of times one can write to it). That way I should just need to desolder the external eeprom, and replace it by a new one when it gets exhausted. Also, the `target' variable would be saved.

That would be a great advantage because by turning the machine on, it could remember not only the last `target' assigned, but the last count it got, so it can continue from there without any need of human intervention, which could even result in erratic behavior if forgotten (i.e: the default target is `100' but today we were producing at 90 units/bag and the labourer forgot to set it up).

By now I'll more than happy if being able to letting it work the simplest of the ways. If I do the pcb properly, I can always take the chipset out and upgrade the firmware at home as I get experienced and implement those things I'd like to do.

Anyway, thanks a lot for the comments, I'll continue with this and try to get help or advise from you if I get stuck, which I expect to happen unfortunately.

Many Thanks,


--- El sáb, 30/8/08, Peter Stuge <peter@...> escribió:

> De: Peter Stuge <peter@...>
> Asunto: Re: [gnupic] about data tables and shared variables
> Para: gnupic@...
> Fecha: sábado, 30 agosto, 2008 7:22
> Lope Vega wrote:
> > My question is about how to handle it.
>
> A matter of taste really.
>
> I suggest having main scanning over the LEDs and to have an
> interrupt-on-change for the switch input. When the switch
> interrupt
> fires, start timer 0. If another switch interrupt fires
> then restart
> timer 0. When the timer 0 interrupt fires the input has
> been
> debounced so update the values that main displays on the
> LEDs.
>
> This does not scale for many inputs but if you only want
> one input
> it's a simple solution. You can of course add a little
> multiplexing
> code to allow handling more inputs.
>
>
> //Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail:
> gnupic-help@...

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.es


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Lope Vega wrote:
> Once I get more experience, I'd also like to see the variable
> `counter' being updated in rom (after each valid pulse), though I
> guess I should use an external eeprom so I'm not killing the pic
> (due to the "limited" number of times one can write to it).

Depending on your application it may be good enough.

E.g. the 16F690 built-in EEPROM (not flash) typically endures 1M
writes to the same byte.


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Robert Pearce-3]

On Saturday 30 August 2008, Lope Vega wrote:
> One of them is about data tables. I'm trying to drive 3 7-segment displays
> which I've got multiplexed. Since I don't really yet understand table
> reads/writes, and haven't seen an example which adequates to what I'm
> doing, I thought on using `computed gotos':

I notice somebody has already pointed out the need to set PCLATH. Nobody seems
to have mentioned the word/byte addressing thing. Suffice to say that if
you're using an 18F family device then each entry of your retlw table
occupies two addresses, so you probably want to shift W left before adding it
to PCL.

Alternatively you could use table reads. It would look something like this:

read_table:
 movwf  TBLPTRL
 movlw  high(table)
 movwf  TBLPTRH
 clrf   TBLPTRU
 tblrd  *
 movf   TABLAT,w
 return


datapage code 0x200    ; Force the table to a page boundary
 db     b'01000000', b'01111001'        ; 0 and 1
 db     b'00100100', b'00110000'        ; 2 and 3
 .... etc


Note that I've put two values on each line of the data. Unfortunately it
appears that if you define a single byte in the code space then gpasm
allocates a whole word for it. What you want is to allocate a byte per value,
so you need to persuade gpasm to do that by supplying two values per line.

Hope that helps,
Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Robert Pearce-3]

On Sat, 30 Aug 2008, Lope Vega <vega_lope@...> 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.      |

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Robert Pearce-3]

On Sat, 30 Aug 2008, I wrote :
>Variables declared in a block defined as "udata_shr" are shared memory.
<snip>
> This is "udata_ovr" memory, which is "overlayed".

Mea culpa - I misspoke. Specifically while writing from the top of my
head I got the "overlay" and "shared" definitions swapped. Sadly the
GPASM manual gives no explanation at all, and I don't feel entirely
unjustified in suggesting that perhaps Microchip's use of "sharebank" to
denote memory that's duplicated at other addresses is perhaps not the
most intuitive terminology. Especially when they use the word "share" in
their explanation of overlays...

Anyway, the rule is:
   udata_shr means it's shared between bank selections (14-bit devices)
   udata_ovr means it can get overlaid by variables in other files
--
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.      |

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...