Porting Contiki To The TI MSP430 Launchpad

For many years Contiki has been one of the main choices when it came to choosing an IPv6 over Low power Wireless Personal Area Networks stack (aka 6LoWPAN). It is developed by a world-wide team of developers with contributions from Atmel, Cisco, ETH, etc… and is open source. As most platforms to which Contiki has been ported are quite expensive, [Marcus] decided to bring the operating system to the TI Launchpad. For our readers that don’t know, the latter is based on a msp430g2452/2553 microcontroller, which only have 256/512 bytes of RAM and 16kB of ROM. As a side note, Contiki typically requires 10k RAM and 30k ROM.

[Marcus] therefore had to remove several features from Contiki: queue-buffering, energy estimation and regrettably uIP. His test setup (shown above) uses the TI CC2500 radio that can be found for less than $2 on Aliexpress, for which he wrote radio drivers from scratch. He also coded his own radio duty-cicling layer, as the one included in Contiki was too big.

16 thoughts on “Porting Contiki To The TI MSP430 Launchpad

  1. The new MSP430F5529 launchpad is much better suited for running Contiki. Thingsquare seems to be partnering with TI, so if Contiki is what you want, then it seems like an easy decision to go with the larger F5 launchpad.

    1. Yeah, goes without saying that larger mcus are better suited if you want large applications, lots of drivers and features etc. The rationale for this port is that you can leverage Contiki with all the benefits it reaps, even on this small mcu. Now, you get a familiar API for timers and sensors etc, code reusability between platforms, no need to copy/paste ADC drivers for the hundreth time etc. Just use the stuff we are used to in Contiki – etimer_set(…), leds_on(LEDS_RED), unicast_send(…) etc.

      1. All the benefits except uIP and RPL/15.4, which seem like the most compelling reasons to use Contiki. There are many, many MCU OSes, so the OS-level features of Contiki are not unique anymore.

        1. Well, yeah, having IPv6, RPL etc on it was never the intention. If you buy a Vespa you are likely happy that you can move faster than on foot, but you would probably realize from the onset that it’s not a proper choice for the Silverstone circuit (F1), right? And the property of moving faster than on foot is not unique to Vespa but still makes the beautiful little moped a useful tool ;)

          We do have the Rime stack in this port though, with unicast and broadcast (and thus all other communication primitives, like network flood), addressing, etc. Just no rimestats, they are gone.

  2. Could it be ported to a TI-99/4A? Those had only 256 bytes of RAM directly accessible by the CPU, plus the spacious 16K of VDP RAM, and another 32K (if the expansion was added) RAM accessible by Extended BASIC and assembly/machine code programs.

      1. The TI-99 doesn’t need drivers. They’re built into the peripherals and called Device Service Routines or DSRs. Plug in a device and its functions are made available as new system calls in a specific memory space. For example, the system in the console knows nothing about disk controllers. Plug in a disk controller and its commands for saving, loading and everything else it does are available. Same deal with the Speech Synthesizer.

        For example BASIC and Extended BASIC don’t have built in code for the speech synth, but with it plugged in the SAY call is available and from the command line or in a program CALL SAY can be used. Unplug the speech and trying CALL SAY returns an error because there’s nothing to CALL.

        There are of course ways to access this via assembly language, usually with extra features and functions not available to BASIC. Programs can be hard coded to only use certain hardware, which has resulted in them being unable to use other peripherals. TI was the worst at that, with some cartridges only able to print to TI’s own printers.

        All the peripherals TI made are very well documented, so are most of the 3rd party ones, and new ones have been made that nobody was even close to dreaming up over 30 years ago.

        Such a system would be much less expensive to implement now, put a flash chip on every device, with Windows, Mac and Linux drivers on it and a standard way to automatically copy them to the host and install, or it could be done like TI did where the driver runs from the chip on the device so if it’s removed there’s no trace it was ever connected.

        But instead we got things like how USB works with the host having to have support built in for multiple device classes and even with XP and later some devices (especially printers) still need many megabytes of software installed just for them.

        Instead of IBM and Microsoft copying Apple, and Apple copying them, they both should have copied Texas Instruments’ best concept.

    1. There are plenty, but Aliexpress search is pretty crappy. You need the proper keywords. Search for “cc2500 module”. I get eg one with 10 modules for 1.83$ each, including shipping. Don’t know what you mean with ‘shipping hoax’, low cost and high shipping?

      The reason these are so cheap is likely due to them being used in the Rock band/sing star/sth -controllers or guitar.

      1. “Don’t know what you mean with ‘shipping hoax’, low cost and high shipping?”

        i don’t know if ‘ast’ just made that term up or if it’s a common one that you and I are the last two peopl on Earth not to know but I like it and I will use it now. Thanks ast!

  3. How about naming the guy who created Contiki (Adam Dunkels, fwiw) and/or his institute at that time (SICS, Sweden) instead of listing three somewhat involved companies? A bit more credit where credit is due, please.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.