Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

different prototypes to AT91F_AIC_ConfigureIt

Posted by Rainer on April 23, 2006
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?

RE: different prototypes to AT91F_AIC_Configu

Posted by Richard on April 23, 2006
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.

RE: different prototypes to AT91F_AIC_Configu

Posted by Rainer on 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?

- 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

RE: different prototypes to AT91F_AIC_Configu

Posted by Richard on 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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists