[mc1322x] My first application

[Daniel Berenguer]

I installed the OE toolchain on a second Ubuntu PC without problems.
It's just an issue of installing mc1322x-oe in /home/user and the rest
of packages wherever you want.

Daniel.

On 5 June 2010 11:03, Daniel Berenguer <dberenguer at usapiens.com> wrote:
> 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
>>
>