#19 watch command in cli/command file

open
nobody
None
5
2006-12-29
2006-12-29
wibix
No

A "add to watch window" command would be nice in the command file (and/or cli). Just to make sure you understand what I mean. The syntax might be:
"watch add 0x21" or with an additional description
"watch add 0x21 key_state".

Discussion

  • Nobody/Anonymous

    Logged In: NO

    good idea, however are you sure you aren't referring to the breakpoint stuff?

     
  • wibix

    wibix - 2007-02-26

    Logged In: YES
    user_id=1504976
    Originator: YES

    no, no: the watch window. when a breakpoint is hit it's required to see what a certain register contains. and if it is in the watch window it is much easier to find. a symbolic name assigned to it makes it even easier.

     
  • J.R. Heisey

    J.R. Heisey - 2007-02-26

    Logged In: YES
    user_id=1204660
    Originator: NO

    A few weeks ago I started working on a new way for a separate module to dynamically add a new command to the cli. Having the the GUI add a 'watch' command may be a good example of how to use the mechanism.

    Other things have preempted this effort. I try to get back to it as soon as I can.

    I don't see how I can assigned this bug to myself.

     
  • Nobody/Anonymous

    Logged In: NO

    > a symbolic name assigned to it makes it even easier.

    agreed, this would certainly be an extremely useful feature-that is, something that would allow gpsim instances to map memory locations to their alias names (TRISA, STATUS, PORTA etc)
    basically, it would be sufficient if for each processor core, there was an API available that provides a pointer to a map of strings which contain the corresponding symbolic name for each given address.
    So that the CLI/GUI would merely interactively query the loaded processor module whether it has a matching symbolic name for an address (if so, retrieve it) or not.

    Speaking more generally, one could even extend the idea somewhat further to allow custom equ macros to be recognized, too - this would probably require dealing with the cod/lst files?
    So, all memory locations and registers that do not have native symbolic names according to the processor's datasheet, could still be provided with a symbolic name, as long as it's been used that way in the assembly file (i.e. "bla equ 0x39" -> if 0x39 has NO matching symbolic name in the processor core, check out the source file for a corresponding equ definition and use that)

    If accompanied by an optionally enhanced register/memory view, this would certainly make it easier to do debugging

    Mike

     
  • Nobody/Anonymous

    Logged In: NO

    @Mike full ack

     
  • Nobody/Anonymous

    Logged In: NO

    the lst files contain all symbols you might be interested in, so it should be possible to reuse that info for the purpose of aliasing hex addresses with a symbolic name for debugging purposes.

     
  • Nobody/Anonymous

    Logged In: NO

    in that case it would be also useful if the CLI could recognize the corresponding tokens (i.e. for the auto-completion to work), so that additional commands to view/modify the addresses using their symbolic names, would become possible, for example:

    du ST[TAB] -> du STATUS

    which would specifically look up the requested address for the symbolic name and only display those contents.

    indeed, if this functionality was available you could provide custom status views (data/memory) for each individual supported PIC, simply by iterating over the map with native (processor-specific symbols) and display each symbolic name together with its current value in hex/binary (or ascii)

     
  • Nobody/Anonymous

    Logged In: NO

    FWIW, we need to take into account that some addresses aren't strictly unique, in that they may point to existing locations - i.e. some file registers are aliased, too.
    Thus, strictly speaking this wouldn't be a simple map containing "one address for one symbol" mapping, but rather "multiple addresses to one symbol".
    This would either need to be reflected in the internal representation of the map, or alternatively the implementation would have to directly query the core for such aliased registers.

    Mike

     
  • Nobody/Anonymous

    Logged In: NO

    note that there is now "break ch" support available in the repository.

     
  • Nobody/Anonymous

    Logged In: NO

    any news about this?

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks