rtel wrote on Sunday, April 23, 2006:
> - forgive my n00bishness: what’s it that isn’t portable about the (atmel) headers?
> and what’s the
> rationale behind using macros vs inlines?
I forget exactly as it was some time ago, but the headers:
+ Use inlines, which is not portable to many embedded C compilers, although I think GCC could cope quite easily. I think there was some header file inclusion ordering problem though. Try using one of the inline header file function in your GCC project and see what errors/warnings are generated.
+ Overlays structures onto peripheral register memory addresses. Again this is not guaranteed to be portable, but may still work ok. It depends on structure alignment and padding, etc. introducted by the compiler.
> - fully ported headers for gcc (or even better, uniform headers for all compilers,
> as far as possible) would be a great thing. as is, it’s quite difficult to port
> a demo for the same board to another compiler when one doesn’t know all the
> reasoning behind the header differences etc.
If you are volunteering
These headers are massive, some of the largest files within the zip download.
> - right now, lib_AT91SAM7X256.h is not usable in the gcc version, be it only
> because of that AT91F_AIC_ConfigureIt argument stuff. (and actually, the lwIP
> demo for rowley/gcc doesn’t use it, while the uIP demo for IAR does).
>
> - about the redundancy of the first argument: is that gcc-specific or is it
> also redundant in iar? would there be a problem in removing it from the iar
> version as well or leaving it in the gcc version so as to have the same
> prototype?
The first parameter is a pointer to the emac peripheral. As there is only one emac peripheral the pointer can just be a constant, it can never be anywhere else. This is the same for all compilers but not all peripherals. For example if there are two UARTs then you have to pass a pointer to the UART you want to use, but as there is only a single EMAC it is not necessary.
> If i want to build the uip demo with gcc, should i ditch the 1st argument from
> the calls to AT91F_AIC_ConfigureIt?
Try using the same headers as included with the IAR demo and see what happens. Other than that, the choice is yours.
> - no, i’m not the one you sent the alternative iar/uip demo to. (actually, i
> don’t have iar)
The demo will work with the free 32K KickStart version that you can download from the IAR WEB site, but you would also need the J-Link interface. It might be useful just as a reference during your porting.
> - my aim is to port the uIP demo from iar to plain gcc. now just in order to
> not reinvent the wheel (as you write “I’m using Rowley” in an other post): do
> you by any chance have the uIP demo for rowley too? cause that would be much
> easier to get to build with gcc than the iar version.
I only have:
+ lwIP demo for plain GCC targeted at SAM7X, or
+ uIP demo using GCC targeted at LPC2000.
Other than the library thing, porting from IAR to GCC should be fairly straight forward (?). Its just a matter of getting the functions defined in the Atmel headers to compiler and run under GCC, or rewriting the parts that you want in a GCC friendly way, as per the inlines that have been changed to #defines.
>
> - as you mention a slash/backslash thing, that reminds me of a couple type hurdles
> i encountered when trying to build the (iar) uip demo with gcc (on linux): there
> probably isn’t any letter case distinction for filenames on windows, but posix
> systems make a difference between “board.h” and “Board.h” (FreeRTOSConfig.h,
> line 34) or between “emac.h” and Emac.h (line 74 of EMAC/SAM7_EMAC.h)
> would be easier for non-windows users if the include matched the filename.
Not the first time I have managed to do that. I will straighten those two out now.
Regards.