[En-Nut-Discussion] Preprocessor and Port Definitions
Alexander Baranov
baranov at intech21.com
Mon Jan 24 15:36:10 CET 2005
----- Original Message -----
From: "Harald Kipp" <harald.kipp at egnite.de>
To: <en-nut-discussion at egnite.de>
Sent: Friday, January 21, 2005 4:25 AM
Subject: [En-Nut-Discussion] Preprocessor and Port Definitions
> Hi all,
>
> Some time ago the avr-libc maintainers changed port
> definitions from simple
> #define PORTA 0x1B
> to
> #define PORTA _SFR_IO8(0x1B)
> in order to support
> PORTA = 0;
>
> IMHO this expression is highly non-portable compared to
> outb(PORTA, 0);
> because on some platforms (Intel x86) ports are not
> memory mapped. However, to some extend I agree with them,
> that port access isn't generally portable. For Nut/OS
> I'd like to stick with outb(), which makes emulation
> much easier. But that's not the point.
>
> The Configurator offers port configuration. I'd like
> to avoid, that the user has to configure both, PORT/PIN
> and DDR. Unfortunately there seems to be no good solution
> to find the DDR for the PORT/PIN.
> #if RTL_RESET_PORT == PORTA
> #define RTL_RESET_DDR DDRA
> doesn't work after including avr/io.h, because it finally
> results in
> #if (*(volatile unsigned char *)(PORTA)) == (*(volatile unsigned char
> *)(PORTA))
> which can't be evaluated by the preprocessor.
>
> In one of the last changes I did, avr/io.h is included
> _after_ evaluation of the port macros. This works, but
> forcing this strict header file sequence isn't nice.
> Beside that, it is still not possible to use
> #if RTL_RESET_PORT == PORTA
> within the code.
>
> I already ran into trouble with the included C files.
>
> (I know, that including C files is bad, but without
> the Configurator tool creating Makefiles based
> on the configuration, there was no other good solution
> to avoid source or Makefiles with 99% duplicate lines or
> contaminating the sources with preprocessor conditionals.
> It's a pain to keep such files up to date. With the
> Configurator it's now easy to split files into hardware
> independent and depended modules.)
>
> The alternatives I can think of are
>
> 1. Let the configurator define AVRPORTA instead of PORTA
> #if RTL_RESET_AVRPORT == AVRPORTA
> #define RTL_RESET_PORT PORTA
> #define RTL_RESET_DDR DDRA
>
> 2. Using our own avr/io.h with the traditional definitions.
> This would force programmers to use
> outb(PORT, val);
> instead of
> PORT = val;
>
> I vote for version 1. Is there another way I missed?
>
> Harald
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>
>
Well, does the version 1 mean that I will have to revise my program and
replace the all the deprecated sbi-s and outb-s commands with the new ones?
If yes, and if I am doomed to do it, maybe it's better to join avr-libc
solution?
Alexander
More information about the En-Nut-Discussion
mailing list