Connect with us

Yet another PIC question

Discussion in 'Electronic Basics' started by Randy Day, Aug 9, 2006.

Scroll to continue with content
  1. Randy Day

    Randy Day Guest

    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?


  2. Mark Fortune

    Mark Fortune Guest

    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?

  3. Randy Day

    Randy Day Guest

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

    Mark Fortune Guest

    thanks for the pointer Randy,

  5. Mark Fortune

    Mark Fortune Guest

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

    Randy Day Guest

    Mark Fortune wrote:

    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.
  7. Guest

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

    Randy Day Guest


    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.

  9. Guest

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

    Randy Day Guest


    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.
  11. Guest

    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
  12. Randy Day

    Randy Day Guest


    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. ;)
  13. Guest

    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?
  14. Randy Day

    Randy Day Guest


    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.
  15. Guest

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

    leave a space then.
    Customers can be a real pain.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day