[mc1322x] My first application

[Mariano Alvira]

On Fri, Jun 04, 2010 at 01:17:02PM -0700, Andrew Pullin wrote:
> On 6/4/2010 12:29 PM, Mariano Alvira wrote:
>> On Fri, Jun 04, 2010 at 12:13:48PM -0700, Andrew Pullin wrote:
>>    
>>> I don't mean to undercut Mariano's wonderful work in getting this all
>>> put together with OpenEmbedded, but:
>>>      
>> Haha, don't worry about that! It took me a day to get that
>> together. Please, undercut away!
>>    
> In that case, you should consider switching the mc1322x project to the  
> CodeSourcery toolchain. It seems like it's a lot more targeted to bare  
> metal development. Sure, there are bugs, but I think it lowers the entry  
> barrier. That's part of how the Tmote-Sky platform got widespread: there  
> was a straightforward binary toolchain available for it (as RPM's).
> Of course, there's a lot of details about syscalls/exception  
> handlers/etc that I've managed to ignore so far, so perhaps there's a  
> definite reason why a linux-targeted toolchain is better?

There shouldn't be a reason to use one over the other --- that is, I
don't see why the code can't be written to work with both. At
somepoint I'll have the Makefile look for either toolchain. I plan to
test with the CS toolchains as well (now that I have a sane one
built!)

I plan to pull in the dbg-io from Contiki into libmc1322x. It's much
better and will be independent of which libc you are using. 

We can also probably change the OE config to build a 'none' toolchain
instead of 'linux' pretty easily. I only used that because I had been
using OE for a different project when I started the mc1322x work.


>>> There's a couple little edits you have to do to the source, too:
>>> - remove the STDERR declaration from printf.c , it's implicity declared
>>> in newlib

That should probably be pulled out into it's own test, float.c anyway.

But before that, the Contiki's dbg-io should be pulled in. 

> At some earlier time, I claimed that %f worked in newlib's printf ... I  
> don't know why I said that, becasue looking at it now, it definitely  
> doesn't. So I rescind that.

Hahha, ok. It's easy to get twisted around testing all this
stuff. It's happened to me plenty!

> Although everyone is talking about Cortex M3 these days, not
> ARM7.... so....?

The Cortexs are the next thing. I'm planning to do hardware and
Contiki support for the STM32W/EM351 --- to stay relevant. The ARM7
and mc13224v will be around for a while though. 

The RF design is not as easy as with the mc13224v. The design will be
more expensive (needs a balun or a different antenna and a matching
network.)

It also has a serial bootloader and JTAG --- so we won't have to
finish implementing SWD into OpenOCD.

And there will be reversing to do...

-Mar.