• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 21 subscribers
  • Views 1768 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Nohau ICE & var's in external RAM & watch window

Dave S.

I can't seem to figure out how to put variables declared via KEIL's
absolute memory access macros (#include <absacc.h>) such as:

#define myVariable HVAR(unsigned int, 0x100000)

into my Nohau (EMUL166PC) ICE's watch window. Can anyone tell me
what I need to do to make this work?

Any help would be greatly appreciated... thanks,
Dave.

  • 0

    Doesn't the C166 compiler support _at_?

    in 

    #define myVariable HVAR(unsigned int, 0x100000)
    myVariable is not a variable, it is simply a name you use while writing your program. When you compile, the preprocessor replaces all instances of myVariable (better written as MY_VARIABLE since you can't take the address of it) with 0x100000). This means it does not show up in the symbol table and thus Nohau will never know of it. If you can use the _at_ directive as we can in C51 then you're all set. E.g.

    unsigned int xdata myVariable _at_ 0x1000;
    Now this will show up in the symbol table and thus you will be able to reference it in Nohau.

    - Mark

  • 0 in reply to Mark Odell

    Unfortunately, C166 doesn't support the _at_.
    I don't know why, and Keil Support couldn't answer this question either.
    The best "work around" you get is 

    #define myVariable HVAR(unsigned int, 0x100000)

    Another suggestion of Keil was, when I had that problem while switching
    from C51 to C166, to put all variables that have to be at specific places
    in a separate file, disable the resorting of variables, and then link that
    file at the address you want. Seemed too much trouble for me, this way
    here you are at least able to define the direct address for your stuff.
    Maybe... <hoping>... one of the next versions of C166 will support our
    C51 _at_, or does anybody else have a better solution for the problem?
    Holger

  • 0 in reply to Holger Warzelhan

    >The best "work around" you get is

    >#define myVariable HVAR(unsigned int, 0x100000)


    I think this is not the best "work around".
    In this case you have no possibilities "watch" or "inspect" by name "myVariable" in
    NOHAU ICE.

    I use next trick:
    - add "debugging" pointer to watched data, for example:

    unsigned int * ptrUI;

    and in NOHAU you can assign any value to "ptrUI" in "Inspect" window, for example:

    ptrUI=0x1000

    Simulteniously in "Watch" window you can see watch (pointed value):

    *prtUI


    You can use pointer to more complex type, not only "unsigned int".


  • 0 in reply to Sergey .

    I use next trick:
    - add "debugging" pointer to watched data, for example:

    unsigned int *ptrUI;
    This is the correct solution, how could we forget the obvious? Thank Sergey.

    - Mark

  • 0 in reply to Mark Odell

    Thanks to all for the help. The solution is really quite cumbersome, but
    it looks like it works.

    After spending many 1000's of $ for what's supposed to be a good ICE,
    what a letdown! Hopefully KEIL will eventually help those of us out who'd
    like to be able to use their ICEs. Does anyone know if BSO Taksing (gasp,
    is it okay to say that here?) or anyone else addresses this better?

    Thanks again,
    Dave Sudolcan

  • 0 in reply to Dave S.

    After spending many 1000's of $ for what's supposed to be a good ICE, what a letdown!

    Whoa! This is not a Nohau or Keil problem (well maybe Keil's in some way, they could've added _at_), it is simply the C language. There is no reason for a #define to ever be placed into the symbol file, I don't know if any tools place the #define name portion into a symbol file. Since the symbol does not really exists (the pre-processor strips it out) the compiler, linker, and debugger simply cannot know about the name you chose to call 0x100000.

    The correct answer is a the properly typed pointer to the location 0x100000. Nohau should let you watch the pointer and what it points to.

    - Mark

  • 0 in reply to Mark Odell

    After spending many 1000's of $ for what's supposed to be a good ICE, what a letdown!<br>
    <br>
    Whoa! This is not a Nohau or Keil problem (well maybe Keil's in some way, they could've added _at_), it is simply the C language. There is no reason for a #define to ever be placed into the symbol file, I don't know if any tools place the #define name portion into a symbol file. Since the symbol does not really exists (the pre-processor strips it out) the compiler, linker, and debugger simply cannot know about the name you chose to call 0x100000.<br>
    <br>
    The correct answer is a the properly typed pointer to the location 0x100000. Nohau should let you watch the pointer and what it points to.<br>
    <br>
    - Mark<br>

  • 0 in reply to Dave S.

    The correct answer is a the properly typed pointer to the location 0x100000. Nohau should let you watch the pointer and what it points to.

    It doesn't? That doesn't sound right. My Signum Systems' USP-51 does. If it's a struct pointer it shows you the struct format too. Sorry to hear that about Nohau, haven't used them in a while.

    BTW, see "Tips for posting" (left) to see the limited HTML tags this forum supports, no <br>'s I'm afraid.

    Regards,

    - Mark