[mc1322x] My first application

[Daniel Berenguer]

I finally made the OpenEmbedded toolchain work. mc1322x-oe now resides
in /home/user whilst the rest of directories (libmc1322x, contiki and
linux serialdev) are elsewhere. libmc1322x seems to be hard-pointing
to /home/ser/mc1322x and a grep of the current makefiles should indeed
help. BTW, I prefer to stop tinkering the toolchain :-)

Setting up (setup.sh) the openembedded overlay is the trickiest step
IMO. But once completed, the rest of the install runs quite smooth.

Thanks for your help!

Daniel.


On 4 June 2010 22:17, Andrew Pullin <pullin at berkeley.edu> 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?
>
>> 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
>