[mc1322x] MC1322x, Contiki and Darjeeling

[Daniel Berenguer]

Hi Niels,

I agree in that delivering pre-linked images with all the necessary
stuff (Contiki, RF stacks, DVM, ...) would prevent most end-users from
having to deal with the current complexities of building Darjeeling
for Contiki. MC1322x platforms could then attract a different kind of
programmers: pure java developers reluctantly to work with the
low-level stuff. Of course, a special serial or wireless loader for
the custom java apps would be needed.

In the next days, I plan to look into developing a wireless firmloader
on top of 6LowPAN/UDP. This could be a good companion for the above
purpose I guess.

Daniel.


On 18 June 2010 08:48, Niels Brouwers <niels.brouwers at gmail.com> wrote:
>>> He's kindly compiled a virtual machine for us, mc1322x users, and is
>>> even willing to work in a more serious port once he gets access to
>>> some mc13224-based hardware. He even considered doing a dual port: one
>>> for Contiki+mc1322x and another for libmc1322x+mc1322x. At this
>>> moment, the current compilation should work only under Contiki though.
>
> Compiling Darjeeling right now is complicated because of a couple of things:
>
> 1) It's a mix of C and Java, with some integration between the two
> (i.e C header files generated from the Java 'java.lang' library which
> are needed for the vm).
> 2) The build system needs to work with different architectures
> (msp430, msp430x, avr, arm, x86), platforms (contiki, tinyOS, posix,
> 'bare metal'), and combinations of those.
> 3) The Java code is currently linked into final .elf as a binary blob.
>
> The way I build on Contiki is by obtaining a contiki-[platform].a and
> contiki-[architecture]-main.o by building the hello world example for
> the target platform. Then I copy these files into the Darjeeling build
> system which then takes care of the rest and produces the final
> executable.
>
> Number three is something I want to fix by writing an ISP interface,
> to make it possible to access the program flash of a chip as a block
> device, and write a tiny file system on top. This would make
> over-the-air reprogramming easier, but it would also mean that you
> don't have to re-link the VM to change the Java code, so that we can
> just distribute pre-linked binaries for a given target.
>
>> Neat! Niels, where are you located?
>
> Delft, the Netherlands.
>
> - Niels
>