[Top][All Lists]

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

[avr-libc-dev] Port and Memory Mapped Register Definitions

From: Bill Somerville
Subject: [avr-libc-dev] Port and Memory Mapped Register Definitions
Date: Fri, 27 Sep 2002 15:05:08 +0100


I don't see any activity on the list, so I hope someone is there.

Four points about the library:

Is there any reason why the above should not be defined along the
following lines:

#define REG_ADDR 0xnn
#define REG _SFR_IO8(REG_ADDR)

rather than the direct:

#define REG _SFR_IO8(0xnn)

The reason being to enable the REG_ADDR macro to be passed as a C++
template parameter to a template class like:

template< const uint8_t Port_addr, const uint8_t Ddr_addr >
class IOPort
      IOPort( uint8_t direction_flags )
          *( volatile uint8_t * const )Ddr_addr = direction_flags;
      IOPort& operator=( uint8_t value )
         *( volatile uint8_t * const )Port_addr = value;
      operator volatile uint8_t()
         return *( volatile uint8_t * const )Port_addr;

Used like:

IOPort< PORTA, DDRA > port_a( 0xff );

port_a = port_a & 0xf0 | ~i & 0x0f; // put low nibble of i on port a

This then allows constructs like mutex guarded ports to be easily

It appears that outb() and inb() always use memory mapped i/o ports
rather than registers if possible - is this true and if so why?

The setjmp.h header file is not C++ compatible (no extern "C++"
declaration), is this deliberate?

Given that g++ generates avr code and gcrt1.S is now C++ compatible, it
would be nice to have a very basic C++ library with the various
std::new, std::delete, and std::set_new_handler fns defined, or at least
the nothrow versions.

Bill Somerville

reply via email to

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