4 ms·
The Contiki OS Version 3.0 Released
- synchronise 11y agoGreat to see this project is still alive. I know this probably has already been asked, but when can we expect the Commodore 64/128 versions?
- avian 11y agoAccording to source on GitHub, it appears support for Commodore 64 and 128 platforms is part of the 3.0 release. https://github.com/contiki-os/contiki/tree/3.0/platform/c64 https://github.com/contiki-os/contiki/tree/3.0/platform/c64 https://github.com/contiki-os/contiki/tree/3.0/platform/c128 https://github.com/contiki-os/contiki/tree/3.0/platform/c128
- adunk 11y agoThe 6502-based ports (Commodore 64/128, Apple II, etc) are actually still all being built by our regression test framework for every commit we make. The 6502 C compiler is a little harsher on following the C specifications so has saved us on more than a few occasions from making changes that would potentially break on other platforms.
- rmhsilva 11y agoParticularly good to see 802.15.4 link layer encryption (AES128) and seamless IPv4 <> IPv6 translation.
- deleted 11y ago[deleted]
- adunk 11y agoQuickly checked out the report - very cool simulation scenarios of London and New York!
- adunk 11y agoThe Cooja simulator is an integral part of the Contiki distribution: all the automated regression tests are run in Cooja. Cooja is actually very reliable, but because it runs user code in the same process as the simulator in the most high-performance mode (for performance reasons) it is not uncommon for user code to crash the simulator. My guess is that this was the problem in your case, particularly if this was your first significant C project. It is possible to run Cooja in an emulation mode too (but only for the MSP430 microcontroller) where the user and OS code is completely isolated from the simulator process - much more reliable and easier to find bugs that break the user code, but much, much slower.
- justin66 11y ago> It is possible to run Cooja in an emulation mode too (but only for the MSP430 microcontroller) where the user and OS code is completely isolated from the simulator process - much more reliable and easier to find bugs that break the user code, but much, much slower. Given the speed of the average PC, how can this possibly be an issue? It seems pretty surprising.
- bucma 11y agoI'd love to see Contiki run on something like the beagle bone black.
- thenewwazoo 11y agoAgreed. I ended up settling on RTEMS, which isn't an RTOS, exactly, but it might as well be.
- kristoffer 11y agoRTEMS certainly is a real time operating system. It was initially used in missiles and the original meaning is Real Time Executive for Missile Systems. Later adopted for generic military, scientific and space use. I think it is a great open source RTOS. FreeRTOS and Contiki are good but not really comparable. Their focus is on smaller more memory constrained systems.
- pantalaimon 11y agoWhy? Linux covers that kind of hardware so much better already.
- bucma 11y agoBecause it would simply be nice to see something different once in a while. Don't get me wrong, I like Linux... I'm just a bit bored with it.
- plainOldText 11y agoAnother IoT OS I've just discovered http://www.riot-os.org http://www.riot-os.org https://github.com/RIOT-OS/RIOT https://github.com/RIOT-OS/RIOT
- TD-Linux 11y agoI saw their booth at IETF 93. I was pretty impressed - it also looks suitable for a lot of non-IP-networked use cases.
- ausjke 11y agoThis is a great OS indeed for IoT sensors. FreeRTOS has a much larger presence in MCU OS and they also overlap each other.I ended up using FreeRTOS but am always interested in checking out Contiki.
- fra 11y agoI've had mixed results with Contiki in the past. Several of their modules are of extremely poor quality. The coffee filesystem in particular is an un-redeemable mess of bugs. Great OS to experiment with, but I would not recommend building a business on top of Contiki today.
- adunk 11y agoThe trick is as always to know what you are looking for and find the tool with the strengths in the right places. As with any system, Contiki has its strengths and weaknesses. The Coffee file system does its job well for what it was intended for (storing simple files on an on-board serial flash chip), but it seems like it didn't match what you were looking for. Filesystems certainly wasn't a design goal of Contiki, there may be better places to look. If you're looking for a lightweight OS that does low-power IP networking with built-in support for self-healing wireless meshing, I think it is difficult to find an OS that beats Contiki. Take this from someone who has in fact built a business on top of Contiki :)
- fra 11y agoNo, this was not a case of "not meeting my needs". I read your papers and carefully considered whether the design goals worked for me. It was a case of "poorly implemented and poorly tested". I know lwIP is widely used, so I'm sure it's not all this bad. However, that was still a pretty big red flag for me.
- adunk 11y agoA couple of years ago Contiki had a lot of rough parts that were in dire need of a bit of love - something we've worked hard to fix in the past few versions. Version 3.0 is by far the most solid Contiki thus far. Maybe you got stuck in the middle of this Not sure about Coffee in particular though, simply because file systems isn't really the focus of Contiki. Unlike server and desktop OSes, where the file system really is a core item, embedded OSes like Contiki don't depend on them and they are only used by a small subset of applications.