[mc1322x] Contiki tree resync

[Mariano Alvira]

On Thu, Oct 29, 2009 at 11:00:42PM -0400, Jon Smirl wrote:
> 
> It would be best to sync up with Contiki CVS once every week or so.
> It's not that we need the code from Contiki that often, it's so that
> we'll quickly become aware of changes to Contiki that could render
> this code unmergable.
> 
> If you'd been syncing once a week you would have quickly noticed the
> CVS keyword expansion issue. I was already familiar with the problems
> caused by keyword expansion and knew how to fix it.

Well unfortunately the phrase "If you'd been <...> you would have
<...>" matches to a lot of things in this project let alone in my
life. But certainly we both agree that more syncs are better than no
syncs (which was the real issue with the keywords --- that and
somebody decided that the "highly recommended option -k" for git
cvsimport should be off by default). I'm open to suggestions on how to
streamline this and get more people involved. I won't be stingy with
server access.

But back to the syncing and merging... the merges should be
trivial. All our stuff should be in contiki/cpu/mc1322x and
contiki/platform/mc1322x. For the most part, the newest version of
files outside of these should always be taken. For the places where
this isn't true we either need to eliminate them on our end (e.g. the
quick hacks that I did --- see conflicts in examples) or, if they
result from a lack of generality on Contiki's side, then we need to
push a fix upstream. As far as I know the only change in the later
category is to contiki/core/sys/rtimer.h, which now that I'm looking
at it, still probably has issues with the type casting.

With that said, however, there are many things in Contiki that are not
generalized enough to work over all platforms. (e.g. coffee, sd card
drive, energest --- I'm sure there are more). There are also missing
things that are, in my opinion, essential and people hack around them
in a way that only works for their platform (e.g channel changing,
power level, CPU sleep, etc...). I feel this is the big
merging/syncing issue that is preventing a lot of progress.

As an easy example of this, take channel changing. Right now that is a
platform hack ("If I had been <less lazy> then I wouldn't have <to
write this example>"). The less lazy thing would be to add this to the
contiki radio driver (a straighforward thing to do) and push that
change upstream.

For a hard example, take CPU sleeping, which is essential to make a
low power sensor node. This is hard to generalize across
platforms. Every processor sleeps differently and has different
capabilities. Even the mc1322x has four major modes + plus a bucket of
minor options + many differnet ways to wake up. (sleep vs. doze and
CPU retention vs no retention). So what are we to do? The C64 guys
certianly don't care. And most of the Sky guys seem to be happy with
just turing off the radio, but that only gets you to the mA range of
average current --- not the tens of uA you need to really make a good
sensor.

All that aside, and back to the merging issue --- without a set of
tests there is nothing to say that the merge is any good. Contiki
lacks this. Time spent on a set of contiki apps designed to test core
Contiki functions across platforms would be a really well spent. Then
you could generate a list of all the things that work and don't work
for each platform.
 
> You don't need two repositories, use branches.  CVS import should be
> one branch, then your two versions of the code would be two other
> branches. Change your .git/config to push all branch heads.
> 
> [remote "digispeaker"]
>         url = ssh://....
>         fetch = +refs/heads/*:refs/remotes/digispeaker/*
>         push = +refs/heads/*
> 
> When the branches are in the server they'll automatically show in gitweb.

Thanks. I'll look into this.

-Mar.