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

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

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


From: Theodore A. Roth
Subject: Re: [avr-libc-dev] Port and Memory Mapped Register Definitions
Date: Fri, 27 Sep 2002 12:19:24 -0700 (PDT)

On Fri, 27 Sep 2002, Bill Somerville wrote:

:)
:) I think the old functionality is fine and should remain for C progs,
:) splitting the definitions into address and addressed object (the
:) register) was only needed because of a C++ quirk.
:)
:) There was a mistake in my template class, I should have added 0x20 to
:) the register address.
:)
:) pauses while RTFM...
:)
:) OK, now I've read the document above I see that using the _SFR_ADDR()
:) macro gets the register address without defining any other macros. I
:) didn't look at this because of the leading underscore, but the
:) documentation implies it's not an implementation macro after all :-)
:)
:) So with this I can use the template above and define:
:)
:) IOPort< _SFR_ADDR( PORTA ), _SFR_ADDR( DDRA ) > port( 0xff );
:)
:) and as a bonus the +0x20 is not required in the template definition
:) either.

Good to avoid the magic numbers. ;-)

:)
:) The code overhead is zero because the template is fully expanded by the
:) compiler in line (at least at -O2 it is).

That's good.

:) > :) 3)
:) > :) The setjmp.h header file is not C++ compatible (no extern "C++"
:) > :) declaration), is this deliberate?
:) >
:) > I don't know the history on this, but I don't see any harm in fixing it.
:) > I'll fix it, but I would like to know if the jmp_buf struct definition
:) > needs to be protected too?
:)
:) Yes, just the usual
:)
:) #ifdef __cplusplus
:) extern "C" {
:) #endif
:)
:) ....
:)
:) #ifdef __cplusplus
:) }
:) #endif
:)
:) stuff around everthing but the header guard.

Done and committed to cvs.

:) I've got versions of new, delete, new_handler, set_new_handler that I
:) use, I'll tidy them up and post them here - they are pretty short and

Don't forget the documentation. I'm a bit inclined to reject new code
submissions that aren't documented or we'll never get the dox done. ;-)

:) simple as they just delegate to malloc() and free(). I'm not sure of the
:) position with exceptions (which is related) with avr-g++, I havn't tried
:) them - I see the compiler turns them off by default. I expect the
:) overhead maybe too much for the smaller acrhitectures. Has anyone tried
:) code with exceptions?

How are exceptions normally implemented?


:) Thanks for the prompt response.

No problem.


Ted Roth





reply via email to

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