[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Memory IO Registers in DDD was: Makes sense go with DDD ahead?

From: Fabian Scheler
Subject: Re: Memory IO Registers in DDD was: Makes sense go with DDD ahead?
Date: Thu, 12 Jun 2008 08:28:38 +0200

>> - I often work on remote targets (microcontrollers) with memory mapped
>> I/O registers controlling the various peripheral units. It would
>> really be nice if one could browse all these registers in a structured
>> manner (e.g. via menus and submenus), it would be even better if one
>> could also alter these registers. I think that is one of the main
>> advantages that debuggers (like the Trace32 debugger) for embedded
>> systems have. GDB already allows accessing these I/O registers - as
>> long as you know the address, so a clever interface might be really
>> helpful at this point.

> That is from my point of few not the job of ddd. If you have a simple struct
> defined with all the IO registers of the device you could display them
> simply by watching the struct content. There is really no difference in IO
> registers and any other memory structure.

Well, of course, doing this manually is possible, but it is annoying.
Furthermore Trace32 also groups the relevant bits in these registers,
again this possible, too, but still annoying. So IMO it would really
be a nice feature if it was offered by ddd.

> But sometimes watching IO regisers
> change the value, like reading uart data input registers will remove data
> from the peripheral which is also done if you watch on some targets through
> jtag into the device. Some registers should be hidden in this case. Any idea
> how this could performed with actual ddd? Lauterbach Trace 32 is very good
> in this case. Maybe we could add some functionality from this.

OK, a non-destructive read definitely would be the best choice here,
but the hardware not always gives you the ability to do that ... but
you can reflect that fact manually in your data structures ;-)

Ciao, Fabian

reply via email to

[Prev in Thread] Current Thread [Next in Thread]