gnupic: Re: [gnupic] about data tables and shared variables
Subject:
Re: [gnupic] about data tables and shared variables
From:
Noel Henson ####@####.####
Date:
30 Aug 2008 17:40:26 -0000
Message-Id: <200808301038.01897.noel@noels-lab.com>
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: ####@####.####
> For additional commands, e-mail: ####@####.####
--
------------------------------------------------------------------
Noel Henson
www.noels-lab.com Chips, firmware and embedded systems
www.vimoutliner.org Work fast. Think well.
