[mc1322x] My first application

[Andrew Pullin]

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?

> Dean is using a codesourcery chain for python-on-a-chip:
> $ git clone http://github.com/jsnyder/arm-eabi-toolchain.git
>
> It has a problem with my funny line in start.S:
>
>          bl _rom_data_init+.-base
>
> where I replaced it with:
>
>         ldr r12,=_rom_data_init
>         mov lr,pc
>         bx  r12
>
> I guess you didn't have this problem?
>    
I think I did have that problem? If you use the latest version, 2010-q1, 
it segfaults on trying to assemble that file. The usual response from 
CodeSourcery is, "Our business model is that you pay us to fix bugs in 
GCC". Which is fine, but it stymies most people pretty quickly. I'm 
pretty sure that 2008-q1 version is the one I settled on after trying a 
few, and it assembles start.S / start-romvars.s without any problems.

>> 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
>>      
> Along these lines, the contiki port now uses Contiki's printf (and
> company) in cpu/arm/common/dbg-io --- I plan to pull these into
> libmc1322x as they are pretty good (and BSD licensed).
>
> We had to modify _write_r in syscalls.c to get newlib's printf to work
> in python-on-a-chip... you didn't have to do that?
>    
Nope. I'm not even familiar with syscalls, and alot of this OS design, 
but it did work. That is, by removing the STDERR declaration and the 
stub functions in printf.c in libmc1322x, the libmc1322x tests build and 
appears to work on actual hardware. I don't think I've tried it with 
Contiki yet, though.
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.

> Also, they are using your red-bsl script over there with some
> changes... I suppose really the whole point of this reply is to tell
> people to checkout the python-on-chip port!
>    
> -Mar.
>    
Yes, I will  have to take a look at that project. I did red-bsl because 
an equivalent thing exists for the Tmote-Sky's, the tos-bsl.py program. 
The easier it is to get the code onto the platform, the easier it'll be 
for people to adopt that platform. Although everyone is talking about 
Cortex M3 these days, not ARM7.... so....?

-Andrew