avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] Bit number/mask, Part 3000


From: Ned Konz
Subject: Re: [avr-libc-dev] Bit number/mask, Part 3000
Date: Wed, 5 Apr 2006 12:49:58 -0700


On Apr 4, 2006, at 9:21 PM, Markus Lampert wrote:

Hi everyone,

Since the discussion about bit masks (C-style) vs. bit numbers (ASM- style) seems to come up every now and then, here are my thoughts for what they're
worth:

Atmel opted for the bit numbers for whatever reasons. That's that and it's moot to argue about it. The gcc port for AVR's chose early on to be as compatible to Atmel's lead as possible. That's also history. Good or bad, that's where we
are.

I personally agree with Joerg that using bit masks would be the 'natural' way in C (and all other non-assembler languages I know). But, there are these guys who still want to do assembler coding, at least every now and then (including myself). And nobody wants to maintain 2 sets of header files, which is a good
idea.

But the bit masks can be easily generated from the existing ioXXX.h files, letting the compiler do the brunt work, as Eric pointed out. The generation can be integrated with the build process and nobody has to maintain them separately. All that is needed is a little convention (already in place) during
the definition of the bit numbers.

I've attached a bash script that creates a
#define _XXXX _BV(XXXX)
for each XXXX that represents a bit number. Think of it as a proof of concept.


You don't even have to go that far. You can still be compatible without having to use different names. *That* is the best of all possible worlds <g>.

I've attached a proof-of-concept that shows how the same file can be used for either style (bitnums or bitmasks) in C, and also as bitnums in assembler, and still allow unmodified old source code to work.

I've also shown one way of doing it in C++ (using templates so that we get tight code generation), but I couldn't think of a clean way to have named registers like I wanted, rather than #defines for C++, so there would be a separate section (or perhaps a separate file, included, which would make it easier to maintain) with a slightly different syntax. Of course, this could be automatically generated from the original headers.

I preferred to be able to write with the same syntax in C++ so I could copy my source code over. The C++ is just a quick hack and is not complete (or probably even correct!), but it shows the code generation and syntax.

The way I did it retains backward compatibility with older sources (in C, C++, or assembly language), and lets you switch at will to also being able to use the newer style in C just using a single #define.

That is, you can still use the _BV(num) expressions transparently, but if you define NEW_STYLE_PORTBITS (or whatever it's called) then you can write *either*:

the old style:
TWCR |= (_BV(TWINT) | _BV(TWEA));

or the simplified usage:
TWCR |= (TWINT | TWEA);

even in the same program, and we can use the same set of defines for assembly language as well.

That way you don't have to use new names.

Attachment: hackio.tar.gz
Description: GNU Zip compressed data




--
Ned Konz
MetaMagix embedded consulting
address@hidden



reply via email to

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