Back from holidays, I think I have found why we have these nasty failures on MSP430-based platforms, and how to fix them to -- at last -- make MSP430 a *reliable* platform for RIOT: see PR #1618 and #1619.
With these modifications, the hwtimer_wait test (cf. issue #426) is now a success on both TelosB and Z1! Plus, my tests with an experimental MAC protocol don't suffer anymore from the "random" crashes that plagued them until now.
Comments (and tests on other MSP430 platforms: I only have access to TelosB and Zolertia Z1) are welcome.
Well, if I understand correctly PR #1618 comments, your tests on msb430 and chronos have succeeded...
On my side, I have made a Cooja simulation with 11 virtual Zolertia Z1 motes exchanging data packets (10 per second each) during 1 hour without any crash. That means almost 360,000 802.15.4 packets exchanged!
I think that we can now begin to consider the MSP430-based devices as stable, "production-ready" platforms. Yay!
The G2553 and G2452 devices are not technically much different from the F1611 and F2617 we currently support.
The main problem with the chips you mention is the memory space; taken from TI manuals:
* G2553 : 16 Kb Flash ROM, 512 bytes RAM
* G2452 : 8 Kb Flash ROM, 256 bytes RAM
Having less than 1 Kb of RAM is clearly a show-stopper here: since RIOT is a true multitasking OS, you need to have a certain amount of RAM (circa 200 bytes) per task (thread), plus half a kilobyte for the interrupt-management system.
As it is said on RIOT presentation page (http://www.riot-os.org/), you need a device with at least 2 Kb of RAM if you really want to use RIOT OS. As a matter of fact, this is true with every OS out there (even TinyOS needs around 1 Kb RAM to be used correctly).
As comparison, the MSP430 device we currently support have these characteristics:
* F1611: 48 Kb Flash ROM, 10 Kb RAM
* F1612: 55 Kb Flash ROM, 5 Kb RAM
* F2617: 92 Kb Flash ROM, 8 Kb RAM
* F6137: 32 Kb Flash ROM, 4 Kb RAM
The use of a complete network stack (to support IoT, which is the main field of application of RIOT) makes the use of these high-end devices necessary.
If you forget the network stack, and only use the core, having at least 2 Kb is still an absolute necessity (4 Kb RAM being strongly recommended).
I'm afraid the introductory/low-end devices you mention are definitely not powerful enough for RIOT (nor another OS)...
Maybe could you get some (used) Sky/TelosB devices -- these are legacy, cheap devices -- if you want to try RIOT?
the below mentioned board should work just fine with RIOT - the porting effort left to do is as Kevin mentioned the implementation of the peripheral drivers. We also planned support for the Teensy 3.1 board [1], which uses a very similar MCU. Thomas once started this work, but I don't know how far he got (since it's his side project...).
Where can I find the Teensy porting effort?
I have been working on porting RIOT to the K60 in my spare time. Both the K20 and the K60 are Freescale ARM Cortex M4 MCUs and I think it would probably be worthwhile to share code between us. I have based my port off the stm32f4 and stm32f1 cpus, stm32f4discovery and iot-lab_m3 board implementations but that’s mostly only the code skeleton since all peripherals are different.
So far GPIO, timer (PIT), UART is working. I am currently working on the SPI. The hello world example works on my Mulle board.
I have not made any meaningful commit messages because I did not think I would share it before finishing the work. I intend to rebase and squash them all when I have something somewhat better working. I do not know when I will have time to finish this port since I am doing it in my free time.
Anyway, I know in RIOT you guys are not exactly looking for new features, however, it's enough to implement a simple file system mainly for data-logging purposes in IoT.
Another alternative would be the MT7681 at similar price [1][2].
There is an OpenSource toolchain for the Andes CPU [3], but I doubt it
covers the wifi part or this SoC in particular - otherwise it'd be
possible to port RIOT to it for a one-chip solution (and for everyone
who thinks ARM is getting boring).
I’m not positive but I don’t believe that the mainline Contiki tree includes support for any version of FAT though I think that there may be some non-mainline forks that have implemented it. I know they implement their own simple log structured file system called Coffee. FAT may be ubiquitous but it’s likely one of the least optimal options for writing to flash. This is especially true when you’re writing to raw NAND devices that contain no wear leveling, garbage collection, compression, or other niceties in hardware (this is far less of an issue if writing to microSD cards).
Has anyone taken a look around at the VFS, file system, and FTL implementations in other suitably licensed (e.g. LGPL, MIT, BSD) systems? Contiki (BSD) has their Coffee file system and CFS layer. NuttX (BSD) has what looks like a fairly impressive VFS layer with support for a few log type systems, FAT12/16/32, FTL, ROMFS, NFS, bind mounts, and an ELF loader.
Hi,
there was actually some discussion in the last student software project here at Freie Universität Berlin (but sadly no implementation yet, since RIOT lacks to date some general interface to access file-like objects). The results were in general: FAT (as Adam previously stated in part) a) is ridden from ballasts of past specification, b) is not suitable for for flash, and c) weird regarding licensing (and propably incompatible to RIOT), since MS is somehow still involved. So they looked at NuttX and CFS (among others), too and found CFS as the most suitable and it is to assume, that since Contiki is very modular as well, that it is easily portable (when we have some genaral file interface, which hopefully will be easier to realize when Kaspar’s IPC change is finally there).
Cheers,
Martine
PS: There are already fd-like PIDs in RIOT [1], but since the current situation is that 1 communication end-point (read this as fd, socket, whatever) equals 1 thread (which will change in the future), this is just not feasible.
