David Brown wrote:
Hi all,
Does anyone here use the facilities in C-Spy, Quadravox, etc. to get a
concise display of all the registers in a peripheral? People are asking
me if this can be provided in the mspgcc toolchain. Well, of course it
can, by modifying insight, GVD, or whatever. However, is it worth it?
I have a lousy memory, so I have to look up locations every time I want
to inspect something. I still don't find the C-Spy display very useful,
though. They have done only the minimum they could. They don't group
registers together in a meaningful way, to make it easier to visualise a
peripheral's state. More importantly. they don't break down all the bit
fields, which might be quite useful. Something like the attached example
might be somewhat useful. It could be quite pretty too, with tasteful
colouring :-)
Any input appreciated (well legal, decent, honest, truthful input at
least)..
Regards,
Steve
I use the peripheral views of debuggers for the various micros I regularly
work with. They can be very useful when first getting hardware to work (you
can manually turn outputs on and off, for example - no need for test
programs), and they can be useful when debugging.
Sure, twiddling the ports directly is very useful. However, just being
able to modify memory fulfills that requirement. Having things displayed
specifically as peripheral registers is a matter of convenience. Just
how convenient it really is, I'm not sure.
Regarding the view, you should maybe have a look at some screenshots from
AVR Studio - they have quite neat tree-based layout, with little checkboxes
for individual bits.
I couldn't find any screen shots, so I downloaded and installed AVR
studio. Without a target it won't do very much, though. I assume what
they have is something like my HTML example, but allowing you to modify
the content. Is that right? In a real implementation I would expect to
do that.
When making something like this, remember that some registers are affected
by reading - I don't think access through the jtag port activates the
side-effects, but it's worth checking (I'm thinking of things like the uart
receive register).
The JTAG facility should spirit away the data without making any status
changes to the processor. I think that means reads are unconditionally
OK. I'm not sure about writes by JTAG, though. I should check if there
are circumstances where the fact a register was not actually written
means the peripheral does not acknowledge the register contents have
changed. There might be potential there for some very confusing
behaviour. :-)
Is it possible for more than one program to attach to rproxy at the same
time? For example, could you have gdb running and a nice little
python/tkinter program connected to show these registers?
Not right now. I think doing so might be rather difficult. How would you
ensure the two debuggers never step on each other's toes? My HTML
example of a register display was produced by a page of code I put
together while considering a web browser as debugger approach. That is,
basically doing what you suggest, and having a simple web server allow
memory to be inspected and modified in a pretty way through a browser.
There is a company that does a whole IDE built out of Mozilla, but I've
never seen it. I have no idea how well that approach plays out. Lots of
things look good, until you get bogged down in the details.
Regards,
Steve
