RE: [avr-gcc-list] port access with avr-gdb

[Theodore A. Roth]

On Thu, 17 Jun 2004, Larry Barello wrote:

> 1. I did the bit fields in all caps simply to mirror the Atmel data sheet.
> I was typing in fast after dinner on Sunday...  Personally, I don't like the
> fact that there is PINC0-7, PINB0-7, etc.  I would be happy with something
> like avr-ioreg.portb.bit0 or something like that.

Going with all lower case would be the way to go I think. I had to do
that to get your test code to compile with including <avr/io.h> anyways.

I'd rather see the following for ports:

  avr_ioreg.portb.b0
  avr_ioreg.portb.b1
  etc.

Atmel is inconsistent with using portb0 or pb0 in the data sheets.

  avr_ioreg.pinc.c0
  avr_ioreg.pinc.c1
  etc.

Do we really need to spell out the name of the bit field in these cases?
If you do, then we should match the datasheet where possible.

>
> 2. special function reg, reading UDR, etc.  Well, you have that problem
> regardless how you access the register, right?

True. There's many ways to shoot yourself in the foot and my feet have a
lot of holes. :-)

The implementation of 'info io_reg' in gdb/avarice has facilities to
protect against doing that.

> The alternative is to have a struct/union for each register, or
> peripheral so you can't accidentally dump the entire struct.  I have
> not used GDB (I wish to change that...) and the struct I posted was a
> quick copy of the Atmel register description page - hence the "all in
> one" nature.

That would work too in the apps, but you'd still have to know the
address of the register to access it via gdb.

>
> 3. collisions between #defines and the struct.  Well, yeah, how to deal with
> that.  I dunno.  I suppose a start would be to make the struct all lower
> case...

Lower case is fine, see above.

>
> I get the feeling that having structs for peripherals & registers makes
> sense and perhaps will work with some modifications.  As for "getting it
> right", maybe #2 also helps here: With each peripheral carefully defined and
> then cast to a proper address pointer it would be easier to get the entire
> map correct.  It would be easier to generate new maps since the vast
> majority of registers, bits and their location in the map are the same from
> processor to processor.  One could just pick & choose which struct to use...
> I think David Brown's examples point the way.

Well, the easiest way to get it right, is to automate it with a script.
Atmel does provide some XML device description files. It would be
possible to parse those and spit out the header with all the #defines
and structure definitions. I haven't looked at the XML files in a while,
but last I looked, they weren't supplied for all devices. It's also
problematic for those without Windows to get the XML out of AvrStudio.

I'm not against the idea of struct/union with bit fields, but I'd like
to have it well thought out before we start blasting away on the header
files. It's going to be a lot of work and once it goes into a stable
release, it's going to be hard to change.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden