Tag Archives: open source

Further adventures with Contiki OS

Posted by KarlP on 26 June, 2013 None comments

I got the (very) basic things working with my port of Contiki OS to my stm32l discovery and stm32vl discovery boards. It was more painful than I expected, there were some unexpected things, but generally, nothing too complicated. Now, I’m at the point where I was hoping to be, starting to try and use the networking stacks in Contiki OS. I want to use the 6LoWPAN implementation, the RPL implementation, the TCP (v4 and v6) implementations.

And here things unravel very quickly. The docs had lead me to believe that I just needed to implement “rtimers” and it would all start working. Turned out the docs referred to an API 5 years out of date. rtimers only actually support a single timer, so you can’t really actually use them in your own apps, you’re really just providing them for the exclusive use of the radio duty cycling (RDC) code. Of which there are multiple styles.

So, yeah, you don’t need to implement them at all. Think of them as rdc_timer and it all makes a lot more sense. They were presumably only introduced at all as the existing timer code (etimer/ctimer) are based on co-operative multi tasking, and RDC algorithms need relatively hard timing to do the radio strobing.

So, what’s the status of Contiki then? The mailing list gives an interesting picture. You’ve got some very advanced topics being discussed about packet loss modelling and distance calculation methods and tweaking the latest draft of CoAP implementation. Then you’ve got posts about simple things that still aren’t fixed like examples simply not even compiling.

Oh yeah, that’s right, did I mention that? There’s examples that don’t compile. You can apply some “fixes” to make them compile, but they’re clearly not the way the makefiles and the project were intended to be, and no-one who might know is
answering.

Stepping out again, it starts to feel like Contiki OS isn’t really an OS project that you can use as is. It’s an OS that’s an incubator for other projects. TCP and UDP for both ipv4 and v6, with all of it configurable via an undocumented mix of makefile variables and C preprocessor defines. A windowing toolkit, because why wouldn’t I want to VNC to my battery powered wireless sensor node and click on things. (I’m serious, the current tree includes a graphical calculator app and a vnc server) Three different RDC algorithms. Two different CoAP implementations. A rather large and complex java modelling framework. Two different file systems. Two different webservers and a webbrowser. This is all in the same tree, along with support for ~20 platforms with ~6-7 different architectures.

It starts to make a bit more sense when you realise that it all started out as an operating system for a commodore 64, but that doesn’t really excuse it per se. Shit’s broken. Shit aint improving real fast. Back to the two different sorts of threads on the mailing list and it starts making more sense again. There’s the CS research types, using hardware the previous grad student used, with the magic incantations from the previous researcher, working on really interesting science, and Contiki OS is the base. Then there’s people who are looking around for some modern networking stacks to use on a device of their own. These other people currently have a pretty raw deal. It’s like the Contiki itself really, some really neat cutting edge science, with sharks and hot burning sun and no water nor a soul in sight to ask for help.

Fortunately, there does appear to be a few birds in the sky, hinting at land. Contiki OS’s now a github project, and getting actual pulls, rather than just being hidden inside a Swedish University. There’s a bunch of people who seem keen to try and clean up some of the accumulated cruft of ten years of grad projects being dumped into a repository somewhere. Now if only there was a little bit of direction and documentation from central leaders and we could really sail!

Mailers and attached patches

Posted by KarlP on 18 April, 2012 None comments

The patch submission policy to open source projects is about as diverse as the number of projects. One policy that comes up fairly often is, “Email submission to blah-developers@example.org. Entire message plain text only, with patch inline, not as an attachment.” Apparently this is so that someone, somewhere, using some sort of mail agent can review the patch while reading their email, and still save the patch cleanly to be applied.

Projects with this sort of policy tend to enforce it rather fanatically. It also means that the list is often covered in reposts of patches, and complaints, about, “Your mailer has mangled your patch (spaces to tabs or vice versa), please fix it and resend” or, “Your mailer has sent the patch as an attachment instead of inline, please resend.” or even just the friendly, “You’ve sent a html message, don’t do that”

Really? That’s the world we’re living in? What mailer in the world won’t let you view a plain text attachment inline? We’re in some lowest common denominator worldview, where for half the people, the answer is NOT USE their email mailer, but an entirely separate program, just for sending patches. (git-send-email)

One the one hand, yes, this sort of policy keeps out amateurs. It also makes damn sure that no amateur ever gets any better. It makes sure that only previously established members can ever submit anything. It’s one of the least friendly ways of accepting work I’ve ever dealt with. And somehow this is OK. I say we’ve failed, and we’ve failed on purpose, and I don’t understand it.

Updated MRF24J40 arduino driver

Posted by KarlP on 17 December, 2011 3 comments

Thanks to pkarck my changes to improve the C library for Microchip’s MRF24J40 802.15.4 modules has been ported to the Arduino library. I’d written an Arduino library some time ago, but hadn’t been maintaining it as I don’t really deal with Arduino much these days. However, it’s gotten some love :) It’s now easier to use, and has support for the power amplifier on the MRF24J40MB modules, if you’re using those. It also makes some quirks I was dealing with in a mixed xbee/mrf24j40 module environment optional. In general, this collects up some of the various reported issues over the last year or so, and I didn’t have to do anything at all!

This is, “teh awesome”.

Downloads:

Contributing back to Open Source, trials and tribulations

Posted by KarlP on 29 December, 2010 None comments

So, back in March 2010, I started using xbee.py. It turned out not to do much of what I needed really, but it was a good base. The project seemed pretty dead in the water, but I fixed a bug or two, added some logging, and filed a bug with the diffs attached anyway. It wasn’t much, and it wasn’t pretty, but hey, if the project was alive, something would happen right?

And besides, it was now all working just fine for my needs.

Fast forward a few months, and the project has been resurrected by a third party. The code has been almost completely rewritten, and seems to have much fuller support for all the esoteric options I hadn’t needed. Oh, and the reply sent to my bug report never reached me, so I didn’t see any of this until just recently.

Of course, the released version _still_ didn’t have some rather important features I’d added, (it’s in trunk) and because of the rewrite, my diffs were now completely useless. And of course, the API has changed.

So where do I go now? Do I toss my local fork, resync with the “master” and try and get back on the train with the current open source base? Ignore it, and stay with my functional, working, battle tested, but feature limited version? (To be clear, my work mostly requires working with just escaped API mode, tx/rx only. The current xbee python project also supports transparent uart, remote AT commands, and remote IO transfer and ADC readings)

Seems like a bit of a loss all around really :( Should I have tried harder to get in contact with the original developer to get my patches in earlier? How much time should you really spend trying to patch open source software and how much time should you spend using it?

I’m well aware of the massive cost of maintaining local forks, if you actually do want the new features, but sometimes it just doesn’t seem worth it :(

FWIW, my version is still at github, and still very much in use here at home.