[mc1322x] "atoi" oversize

[Andrew Pullin]

  On 7/2/2010 11:04 AM, Mariano Alvira wrote:
> On Fri, Jul 02, 2010 at 10:42:10AM -0700, Andrew Pullin wrote:
>>   I'll recommend the CodeSourcery toolchain, as I have before. I think
>> it's a lot more straightforward to use than the whole BitBake ordeal!
>> There are a couple of minor issues, but overall, it seems to work OK.
>> And it uses newlib, so an example that uses atoi() ends up being only
>> 2452 bytes .
>>
>> Someone should really do a writeup for the website on how to get the
>> CodeSourcery toolchain working with the project ...
> I found the toolchain Dean found to be simple to setup:
>
> git clone http://github.com/jsnyder/arm-eabi-toolchain.git
>
> There is a readme or something in there that has some trivial
> instructions. I'm sure that the changes (if any really) to Contiki and
> libmc1322x are minor. I've already committed the fix to start.S. I'm
> busy right now working on new hardware (good things in the works) ---
> so patches along these lines would be greatly appreciated!
>
> -Mar.
>
Bleh! No building! Well, I understand the motivation behind it, 
especially when working with new chips, and odd chips (like this whole 
reverse engineered ROM setup ). Of course, there might be something 
major that I'm missing here; honestly, I've used IAR and Keil more than 
GNU tools.
Plus CodeSourcery's toolchain is dead easy to install, doesn't require 
cygwin or mingw, which are both nightmares, and includes a version of 
Make for windows platforms, which is pretty useful. If/when we teach 
another Sensor Networks class here, I think I'd force everyone to use 
the CS binary toolchain.

While we're on the topic, I'm actually super curious what the problem 
was with start.S, as a learning exercise. Presumably you are talking 
about something that caused the newer versions of the CS toolchain to 
segfault when try to assemble?

And can you say anything about the new hardware? Cortex M3?

- Andrew