Yet another PIC question

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

Reply to
Randy Day
Loading thread data ...

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

Reply to
Mark Fortune

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

Reply to
Randy Day

thanks for the pointer Randy,

Mark

Reply to
Mark Fortune

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

formatting link

Reply to
Mark Fortune
[snip]

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.
Reply to
Randy Day

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

Reply to
cbarn24050
[snip]

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

Reply to
Randy Day

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.

Reply to
cbarn24050
[snip]

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.

Reply to
Randy Day

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.

Often the easiest way with small micros like PICs.

it just

That sort of error will allways mess things up.

I may not be the one

Reply to
cbarn24050

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

[snips for brevity]

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.

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.

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

Reply to
Randy Day

No it wouldn't.

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

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.

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

Reply to
cbarn24050
[snip]

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.

Changes in user specs/requirements comes to mind.

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

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

Reply to
Randy Day

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

leave a space then.

Customers can be a real pain.

Reply to
cbarn24050

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.