[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 |
Hi
I don't see any activity on the list, so I hope someone is there.
Four points about the library:
1)
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
{
public:
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
defined.
2)
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?
3)
The setjmp.h header file is not C++ compatible (no extern "C++"
declaration), is this deliberate?
4)
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
- [avr-libc-dev] Port and Memory Mapped Register Definitions,
Bill Somerville <=