Author Topic: Makefile for GNUARM  (Read 11763 times)

Offline cstrahm

  • Newbie
  • *
  • Posts: 9
    • View Profile
Makefile for GNUARM
« on: February 13, 2009, 08:40:46 AM »
Hi:

Just wondering if you already have a regular GCC Makefile, before I spend my time reinventing the wheel.  The one you have in the GNU example does not seem to work with GCC make.exe

Chris.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Makefile for GNUARM
« Reply #1 on: February 13, 2009, 06:27:29 PM »
Hi Chris

I don't know why the make file in the GCC project folder doesn't work for you.
I am presently using Codesourcery g++ Lite for testing - the file is attached (slightly optimized but otherwise the same).

I am calling it with a post processing step in Visual Studio:
cd ..\GNU_LPC23XX [this sets the working directory]
Build_LPC23XX.bat [the bat file to start the build]

The bat file (also in the GCC folder) has the following content:

SET PATH=%PATH%;C:\Program Files\CodeSourcery\Sourcery G++ Lite\bin
cs-make -f make_uTaskerV1.3_GNU_LPC23XX all


This sets the PATH variable so that the GCC binaries are found (if it is already set on the PC as system variable it is not required)
cs-make is the make file used - are you using a different make utility?


Regards

Mark

Offline cstrahm

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Makefile for GNUARM
« Reply #2 on: February 13, 2009, 11:01:24 PM »
I use the make.exe that comes with GCC.  You are calling "cs" which I assume means code soucery whch I assume is some other IDE.  I already have paths into GNUARM/GCC.  The syntax and key words in your makefile appear to be unknown to gcc make.exe.  I'll play with it somemore, but I guess I'll have to create my own makefile.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Makefile for GNUARM
« Reply #3 on: February 13, 2009, 11:39:44 PM »
Hi Chris

I think that the GCC make is basically always the same(?). Yes the cs-make is almost certainly due to the CodeSourcery package.

I just checked the SAM7X project, which does have a Yagarto make file in it. This is the comparison (since I don't remember why it needed separate makes)

Bat - CS GCC
cs-make -f make_uTaskerV1.3_GNU_SAM7X all

Bat - Yagarto
make -f Yagarto_make_uTaskerV1.3_GNU_SAM7X all

So, make instead of cs-make.

Then the make files themselves:

CS GCC
Build\application.o: ..\application.c $(DEPENDS) ..\application.h
      arm-none-eabi-gcc $(C_FLAGS) -I..\..\uTaskerV1.3 -D _GNU -D _HW_SAM7X -g -c -Os ..\application.c -o Build\application.o


Yagarto GCC
Build\application.o: ..\application.c $(DEPENDS) ..\application.h
      arm-elf-gcc $(C_FLAGS) -I..\..\uTaskerV1.3 -D _GNU -D _HW_SAM7X -g -c -Os ..\application.c -o Build\application.o



The difference is in the binary command names: arm-none-eabi-gcc and arm-elf-gcc.

Take a look in your GCC binary file to see how they are named in your version. Then change to suit.
In fact it is better to put the compiler call in a define like


C_FLAGS = arm-elf-gcc

Build\application.o: ..\application.c $(DEPENDS) ..\application.h
      $(CPP) $(C_FLAGS) -I..\..\uTaskerV1.3 -D _GNU -D _HW_SAM7X -g -c -Os ..\application.c -o Build\application.o



Then it is easier to match to the binary in the version.

Regards

Mark


Offline cstrahm

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Makefile for GNUARM
« Reply #4 on: February 14, 2009, 10:34:50 AM »
Yes I changed the lib to arm-elf-gcc and that fixed it.  Thanks.

I added my usual warnings, opt, and debug options.  Your code is pretty clean, but you have a number of local variables defined identical to global names.  Not good practice.  For example, take a look at fnSendHTTP_windows() in HTTP.C.  You have a function parameter defined as "ucPush", and then you define another local variable inside the routine with the same identical name "ucPush".  If you reference "ucPush" later, are you talking about the function parameter or the local variable?  This is needlessly confusing.  I get about 40 warnings most of which could be easily eliminated.

I am most interested to test your TCP/IP stack.  I had been running FreeRTOS.  I ported lwIP-1.3 over, and it has many problems/bugs.  Was not impressed.  Next I ported NicheLite-LPC.  The Niche code is extremely good, but unfortunately it appears to have it's arms tied behind its back in several places deliberately.  Interniche offered to resolve the issue if I purchased their $2400 yearly support.  Not so free after all.  More like bait and switch.

However the Niche stack code is ultra high performance, runs 90-100Mbps TCP with the LPC2468.  Virtually full line speed.  They do several things that are interesting: (a) They use dual sized DMA packet buffers (192 bytes and 1536 bytes).  IP traffic is either ARP/SYN/ACK/... small packets, or large TCP/FTP/... bulk data packets.  They prevent small packets from using up the big buffers. (b) They dynamically allocate the DMA buffers.  For example, rather than having say fixed 4-RX and 4-TX buffers, they have a pool of 8 buffers that can be used entirely for either RX or TX.  They float back and forth dynamically. (c) They have a pure ASM hand coded routine for checksum. (d) they have zero data copy.  Good stuff.  Third generation code. 

Your package seems to have a lot of bang for the buck.  A lot more coverage of different functions and utilities than I expected.  I need to study your files and figure out where everything is at, then port the pins to my product PCB, and mod the PHY code.  A couple questions:

- Does your SPI routines use DMA?
- Does you USB routines use DMA?

Thanks,  Chris.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Makefile for GNUARM
« Reply #5 on: February 14, 2009, 03:38:27 PM »
Hi Chris

I never realized the double use of the ucPush in fnSendHTTP_windows().
However the result is correct. The ucPush passed to the function is used as flag when sending the first TCP frame and, if there are no more frames to be windowed, that was it.
When following frames can be windowed, the ucPush is a local one in the inner loop.
In this case I think that the first variable can be reused and then there is no need to declare it in the inner loop at all. I will make this change and verify it ready for the next release.

It looks as though Interniche have done good work on optimizing the LPC23XX interface to achieve optimum throughput.
Unfortunately the LPC23XX project is not a good one to measure the uTasker by since it doesn't have a huge user community and so only little time is invested (in comparison) in its peripheral set. It is also lacking in various peripherals and no DMA has been used on its serial peripherals due to the fact that DMA RAM is restricted to a certain memory range and would require a special solution. See the following for design notes about such things:

http://www.utasker.com/forum/index.php?topic=109.0
http://www.utasker.com/forum/index.php?topic=136.0
http://www.utasker.com/forum/index.php?topic=128.0

Specifically I found the following notes (not in the forum) about the DMA:

Quote
The LPC23XX contains a dual channel general purpose DMA controller. The controller is highly configurable and supports functions such as converting between little and big-endian memories as well as gather or scatter (using linked lists so that memory doesn’t have to be contiguous).
However the DMA controller doesn’t support UART transfers – it supports SD/MMC, two SSP and I2S interfaces. In addition it doesn’t support all internal memory but rather only the 8k USB memory range (0x7fd00000..0x7fd01fff). It does however support some external memory banks when the device has an external memory interface and external memory is available.
Since the most useful DMA operations in the uTasker project are for memory/memory transfers – uMemcpy() with DMA support and UART transmission, the DMA controller was found not to be very useful. Therefore its implementation has been left out for the time being.


Generally peripherals with DMA support will have an option (usually a define to enable the code and a parameter to switch to the DMA mode). The same is true when double buffering is available (Coldfire has probably best support including DMA based memcpy())

The SPI in the LPC23XX supports only SPI FLASH for file system or other use so there is no generic SPI driver.
Presently there is no USB support on the LPC23X (it is available for Coldfire, SAM7X and will be available in the next Luminary Micro service pack - LP23XX follows next...).

In the LPC23XX development project I2C has been added and also a port interrupt driver (allowing up to  46 different user interrupt routines to be entered, each reacting to an individual port bit change of the specified polarities).

The priority is for driver interface compatibility and in some cases this will lead to less optimum absolute performance in a single point when compared to a different solution. However across the board I would expect the complete project to still collect enough points to be considered a worthy choice for real projects. Also try out the uTasker simulator - this is possibly its biggest plus point!!

Regards

Mark