Hi all, I’m trying to port Demo/uIP_Demo_IAR_ARM7 from IAR to plain GCC. I stumbled across some problematic differences in the basic headers between the header files in Source/portable/GCC/ARM7_AT91SAM7S and the IAR equivalent. most disturbingly, in lib_AT91SAM7X256.h, the macro AT91F_AIC_ConfigureIt has lacks the (first) argument AT91PS_AIC pAic in the header for GCC, though the type AT91PS_AIC is defined in the GCC "version" of AT91SAM7X256.h as well. Is there any reason why this first argument wouldn’t be there in the header for GCC? if so, what is it?

The headers were not fully ported across to GCC.  They are not written (by Atmel) in a portable way which is a pain.  The library functions used by the GCC demo have been modified to be macros rather than inlines.  As the first parameter was redundant it was simply removed. If you are the person I sent the alternative IAR/uIP demo to (the one with the submit button on the served pages so data can be sent back to the SAM7X), then I have just discovered that this will not work with FireFox.  I downloaded FireFox recently to look at the reported lwIP demo issue and also tried it with the (alternate) uIP demo.  The problem is simply that the backslashes in the form are the wrong way around.  While IE corrects them automatically, FireFox does not.  If you would like an update then let me know, it is just a very minor change in the html to get it working with FireFox. Regards.

- forgive my n00bishness: what’s it that isn’t portable about the (atmel) headers? and what’s the rationale behind using macros vs inlines? - 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. - 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? If i want to build the uip demo with gcc, should i  ditch the 1st argument from the calls to AT91F_AIC_ConfigureIt? - no, i’m not the one you sent the alternative iar/uip demo to. (actually, i don’t have iar) - 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. - 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. Regards

> – 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.