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".
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> 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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: NO
good idea, however are you sure you aren't referring to the breakpoint stuff?
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.
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.
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
Logged In: NO
@Mike full ack
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.
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)
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
Logged In: NO
note that there is now "break ch" support available in the repository.
Logged In: NO
any news about this?