-
Notifications
You must be signed in to change notification settings - Fork 4
porting
Great, we now know how to get traffic in and out of the WSN via standard-compliant ways (hooza!). As mentioned before, for the course you will either use a Contiki process on the Edison and communicate with one of the radio chips which we added. Or you can ditch the Edison and work on the MSP430 processor included on board with the radio chips. This would allow you to (maybe) save a lot of battery power, also opens you up to more "traditional" embedded software development.
To achieve this however, we will need to port Contiki to this new platform since there is none for the platform we are using yet. You might want to check the Porting Contiki Paper. We will briefly look into what the neccesary step, to get a working port, are. The overall goal is to be able to compile Contiki applications from the examples/ directory and run them on the provided wsnedi board. Since we also want to communicate with the outside this also requires writing a driver for one of the included radio chips (we can't use both at the same time).
Contiki really is a library with OS-like features (similar to most µC-OSes). So for compilation, you will always included the whole "OS" with your application and create the typical .hex file to directly upload to the µControllers memory. As you have already seen, there is no memory protection between "processes" and no preemptive multi-tasking. Only cooperative multi-tasking, with the neat little C-trick called proto-threads is there. Porting contiki really is just getting a library to work on your platform. The minimum you need to do is provide a timer callback to drive the scheduler.
Remember the target layout of the Contiki. For any target you compile for, there is a respective directory under platform/. In there you will the contiki-conf.h header file, which defines default options for building the contiki library and your application. You also find a Makefile that configures the build process, i.e. which compiler to use, which additional libraries to use, how to link the program, how to generate the .hex file and sometimes how to flash to the target. For the MSP430 target you can copy and modify either the sky or z1 platform files. You will need to create your own wsnedi/ platform directory and modify one of the existing platforms. Also important is the contiki-main.c file which defines the bootup-process of the platform.
Step 1 includes getting a .hex file flashed on your device with the GoodFET programmer, so copy over one of the existing platform and give it a shot...
In this step you need to get contiki to work with the existing hardware by providing a timer module. So read up in the MSP430 datasheet about available timers and choose one for which you can generate an interrupt at 10-100Hz. Luckily somebody figured this out for the MSP430 devices already, so you just need to choose to include the right file from the cpu/msp430/fxxxx directory. The implementation can be found in the clock.c. The interrupt service routing there (ISR) provides the tick timer for driving the scheduler and system.
Now you should be able to build your first Contiki process, and debug that via JTAG. Note, neither a serial port nor any other form of output is routed on the wsnedi board from the msp430 CPU. The only connection is the SPI connection to the Edison, and the JTAG header to the GoodFET.
Here you will need to start from scratch, as there is no contiki driver for the MRF89 or the DWM1000 modules on the wsnedi board. Again you need to configure the build to include your own network driver, which you can put under the platform/net/ directory.