Yet another PIC question

[Randy Day]

My project will be using several large tables
of data (2Kb each).

I want to use TBLRD to access the words/bytes,
but I'm unsure how to set up the tables to be
used with TBLRD.

MPASM has a table data structure:

table0 dw 0x00,0x01,0x00,0x02,0x00,0x03
dw 0x00,0x01,0x00,0x02,0x00,0x03
; etc...
table1 dw 0x00,0x01,0x00,0x02,0x00,0x03
dw 0x00,0x01,0x00,0x02,0x00,0x03
; etc...

Since the program is in development, the start
address of the tables will probably change as
the code changes, so I can't really hard code
the locations to put in to TBLPTR. Or can I?

What's the best way to handle this?


Thanks,

Randy

 

[Mark Fortune]

My project will be using several large tables
of data (2Kb each).

I want to use TBLRD to access the words/bytes,
but I'm unsure how to set up the tables to be
used with TBLRD.

MPASM has a table data structure:

table0 dw 0x00,0x01,0x00,0x02,0x00,0x03
dw 0x00,0x01,0x00,0x02,0x00,0x03
; etc...
table1 dw 0x00,0x01,0x00,0x02,0x00,0x03
dw 0x00,0x01,0x00,0x02,0x00,0x03
; etc...

Since the program is in development, the start
address of the tables will probably change as
the code changes, so I can't really hard code
the locations to put in to TBLPTR. Or can I?

What's the best way to handle this?


Thanks,

Randy

Thanks,
You saved me from asking pretty much the same question

*doing my nut in here trying to figure it out*

What pic are you using?

Mark

 

[Randy Day]

My project will be using several large tables
of data (2Kb each).

I want to use TBLRD to access the words/bytes,
but I'm unsure how to set up the tables to be
used with TBLRD.

Never mind; I just discovered the UPPER, HIGH
and LOW keywords.

 

[Mark Fortune]

Never mind; I just discovered the UPPER, HIGH
and LOW keywords.

thanks for the pointer Randy,

Mark

 

[Mark Fortune]

Never mind; I just discovered the UPPER, HIGH
and LOW keywords.

If it helps anyone, myself included, I found this snippet of code that
uses tables and tblrd:

http://www.picbook.com/downloads/asm/CH14.asm

 

[Randy Day]

Mark Fortune wrote:

[snip]

Thanks,
You saved me from asking pretty much the same question

*doing my nut in here trying to figure it out*

What pic are you using?

Mark

PIC18F2455. Nice little unit, USB capable and up
to 48MHz clock[1].

See my posting history in the group; there've been
a few discussions on the finer points of getting
one working properly.

[1] for instance, the docs say in order to use the
USB, your max clock is 24MHz.

 

[[email protected]]

My project will be using several large tables
of data (2Kb each).

I want to use TBLRD to access the words/bytes,
but I'm unsure how to set up the tables to be
used with TBLRD.

MPASM has a table data structure:

table0 dw 0x00,0x01,0x00,0x02,0x00,0x03
dw 0x00,0x01,0x00,0x02,0x00,0x03
; etc...
table1 dw 0x00,0x01,0x00,0x02,0x00,0x03
dw 0x00,0x01,0x00,0x02,0x00,0x03
; etc...

Since the program is in development, the start
address of the tables will probably change as
the code changes, so I can't really hard code
the locations to put in to TBLPTR. Or can I?

What's the best way to handle this?


Thanks,

Randy

Put your tables at the highest end of the memory that way the start
address cant change unless you change processor.

 

[Randy Day]

[email protected] wrote:

[snip]

Put your tables at the highest end of the memory that way the start
address cant change unless you change processor.

Thanks for the reply. That is what I would
have had to do, and for various reasons
wanted to avoid.

I found the UPPER, HIGH and LOW keywords
shortly after I posted this, and they seem
to be a more flexible alternative.

Randy

 

[[email protected]]

[email protected] wrote:

[snip]

Put your tables at the highest end of the memory that way the start
address cant change unless you change processor.

Thanks for the reply. That is what I would
have had to do, and for various reasons
wanted to avoid.

Any reason why? You can put the tables at the begining (after the
interrupt vectors) and the code behind them, that also keeps them
static.

 

[Randy Day]

[email protected] wrote:

[snip]

Any reason why? You can put the tables at the begining (after the
interrupt vectors) and the code behind them, that also keeps them
static.

Mostly (at this point) to avoid having to scroll
back and forth past 1000 lines of tables while
developing the code. I'm sure there's a way to
use an include file in an .asm, but I haven't
looked for it yet.

Plus I have a philosophical problem with having
somthing static like that in my program; it just
seems to vulnerable to getting f^#*$d up if a
line of code or a variable declaration gets
placed where it shouldn't. I may not be the one
maintaining the code in the future.

I have some position-dependent variables in a
CBLOCK declaration already, and I'm uncomfortable
with *that; it's going to get changed.

 

[[email protected]]

[email protected] wrote:

[snip]

Any reason why?

Mostly (at this point) to avoid having to scroll
back and forth past 1000 lines of tables while
developing the code. I'm sure there's a way to
use an include file in an .asm, but I haven't
looked for it yet.

If you put them at the end then you dont have to scroll past them. The
only instruction that comes after is the .end instruction.

Plus I have a philosophical problem with having
somthing static like that in my program;

Often the easiest way with small micros like PICs.

it just

seems to vulnerable to getting f^#*$d up if a
line of code or a variable declaration gets
placed where it shouldn't.

That sort of error will allways mess things up.

I may not be the one

 

[Randy Day]

[email protected] wrote:

I used to work with a C. Barnes. That
wouldn't be you, would it?

[snips for brevity]

If you put them at the end then you dont have to scroll past them. The
only instruction that comes after is the .end instruction.

That still leaves us with the problem of
recalculating the table address(es) each
time we add/delete a line of code, then
going to the relevant subroutine and
updating. We *did* put the static
references in a sub, rather than scatter
them through the code, didn't we?

Same thing happens if one or more tables
changes size...

I say let the computer do its job.

Often the easiest way with small micros like PICs.

Disagree. It's quick, dirty, even necessary
in real-time apps where every clock cycle
counts, but the IDE gives us the tools to
let the computer track where the data is.
It's better at it than we are.

Easy up front =/= easy over the long term.

That sort of error will allways mess things up.

Granted. We should still make it harder for
them to do so.

 

[[email protected]]

[email protected] wrote:

I used to work with a C. Barnes. That
wouldn't be you, would it?

No it wouldn't.

[snips for brevity]

If you put them at the end then you dont have to scroll past them. The
only instruction that comes after is the .end instruction.

That still leaves us with the problem of
recalculating the table address(es) each
time we add/delete a line of code, then
going to the relevant subroutine and
updating.

No it wouldnt, you fix the table at the end of the memory with an org.
instruction. It can never move after that. Unless YOU move it. it's not
so important with pic18 devices but it sure saves a lot of headaches
with the pic16 chips.


We *did* put the static

references in a sub, rather than scatter
them through the code, didn't we?

Same thing happens if one or more tables
changes size...

Well possibly but why would your table change size? In any event you
give the table start a label and the calling routines use it so if you
move it the calling routines still know where it is.


I cant (wont) argue with your preferences.

Disagree. It's quick, dirty, even necessary
in real-time apps where every clock cycle
counts, but the IDE gives us the tools to
let the computer track where the data is.
It's better at it than we are.

I think you may have missunderstood what I meant, or do you put your
variables on a stack?

 

[Randy Day]

[email protected] wrote:

[snip]

No it wouldnt, you fix the table at the end of the memory with an org.
instruction. It can never move after that. Unless YOU move it. it's not
so important with pic18 devices but it sure saves a lot of headaches
with the pic16 chips.

Agreed, as long as code bloat doesn't force a
move. Then again, if that happens, we probably
picked the wrong micro for the job, so your
point still stands.

If we don't have each table in a separate org
with space in between, we're still vulnerable
to table size changes, though. See below.

Well possibly but why would your table change size? In any event you

Changes in user specs/requirements comes to mind.

give the table start a label and the calling routines use it so if you
move it the calling routines still know where it is.

Which pretty much brings us back to what I was
advocating when this all started.

I think you may have missunderstood what I meant, or do you put your
variables on a stack?

That's entirely possible, and no I don't.

 

[[email protected]]

[email protected] wrote:

[snip]

No it wouldnt, you fix the table at the end of the memory with an org.
instruction. It can never move after that. Unless YOU move it. it's not
so important with pic18 devices but it sure saves a lot of headaches
with the pic16 chips.

Agreed, as long as code bloat doesn't force a
move. Then again, if that happens, we probably
picked the wrong micro for the job, so your
point still stands.

You sure have, since you have now run out of memory space.

If we don't have each table in a separate org
with space in between, we're still vulnerable
to table size changes, though. See below.

leave a space then.

Changes in user specs/requirements comes to mind.

Customers can be a real pain.