ubrr vs. ubrr0, u2x vs. u2x0, udr vs. udr0, etc.

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a compatibility mode for gcc which will translate the register names for the 0-th serial port to their older names (without the 0) or vice-versa? I think this would be helpful when writing serial port routines which could be used with either the atmega8 or atmega48, for instance.

Or, is there another good solution to this problem? It seems a waste to have to maintain two different code bases just because of a systematic naming difference.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not that I'm aware of. The avc-libc library (part of GCC) uses Atmel's .xml part descriptions (part of AVR Studio) as the canonical name for registers.

You can look at Pascal Stang's AVRLIB library for some ideas about how to code a library that is compatible across AVR parts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My solution is to create another level of #define mapping in a local .h file:

#if MCU==
#define REALLY_GOOD_NAME_FOR_UBBR UBBR0
#else
...

And then code my program with REALLY_GOOD_NAMEs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's similiar to what Pascal Stang does in his library. Though, now I'll know what the acronym RGNF stands for ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

RGNF

? Reject Gnu--Not Friendly?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use macros-
http://www.mtcnet.net/~henryvm/A...
(first part of define section)

I can compile for a mega8, mega16, meag32, mega88, mega64, mega168, etc. with no changes.

The mega64 causes a problem with my macros, because it has both the 'older' names and the 'newer' names. So I undefine the older names for the '64. That could be eliminated if I could get my concat macros to stringify the arguments instead of expanding them first.