I am currently working on the creation of a RIOT port on Zolertia Z1.
Since this platform is based on a family-2 MSP430 (F2617) --- a kind of MCU not yet used in any current port in RIOT ---, I stumbled upon inconsistencies with the already included header files.
Instead of adding one more #ifdef case for including the correct headers, I think we can just include <msp430.h> in all the concerned files : this is a generic file that includes the correct specific headers when the right symbol is defined.
Practically, following my idea, we would add lines like this in boards definitions:
#define __MSP430F1611__
- in telosb/include/board.h, wsn430*/include/board.h,
#define __MSP430F1612__
- in msb430/include/board.h,
#define __CC430F6137__
- in chronos/include/board.h,
#define __MSP430F2617__
- in z1/include/board.h (file I am creating in my new port).
and in generic MSP430 files (in the "core" of RIOT), we would only add these "unconditional lines":
#include "board.h"
#include <msp430.h>
This would simplify the source files, by reducing the number of ifdefs, and allow an easier integration for any future platform based on (current or future) MSP430 devices.
I am currently working on the creation of a RIOT port on Zolertia Z1.
Awesome!
Instead of adding one more #ifdef case for including the correct
headers, I think we can just include <msp430.h> in all the concerned
files : this is a generic file that includes the correct specific
headers when the right symbol is defined.
Since this platform is based on a family-2 MSP430 (F2617) --- a kind of MCU
not yet used in any current port in RIOT ---, I stumbled upon
inconsistencies with the already included header files.
I guess there are even more inconsistencies in board and cpu. Hauke was so
kind to create an overview about the current state of board and cpu headers
and the according implementations. He'll probably propose a new version of the
hardware interface that is more consistent and easier to understand.
Instead of adding one more #ifdef case for including the correct headers, I
think we can just include <msp430.h> in all the concerned files : this is a
generic file that includes the correct specific headers when the right
symbol is defined.
Practically, following my idea, we would add lines like this in boards
definitions:
#define __MSP430F1611__
- in telosb/include/board.h, wsn430*/include/board.h,
#define __MSP430F1612__
- in msb430/include/board.h,
#define __CC430F6137__
- in chronos/include/board.h,
#define __MSP430F2617__
- in z1/include/board.h (file I am creating in my new port).
and in generic MSP430 files (in the "core" of RIOT), we would only add these
"unconditional lines":
#include "board.h"
#include <msp430.h>
This would simplify the source files, by reducing the number of ifdefs, and
allow an easier integration for any future platform based on (current or
future) MSP430 devices.
As a first step, I created the attached overview of interfaces defined in the kernel and the location of their implementation. It turned out however, that the sketched interfaces are not quite complete, some implicit calls between core and cpu (e.g. thread_yield()) are missing. Also some ‘backwards interfaces’ are not in that list, these concern some defines made by cpu or board and are used in the core. I am currently working on cleaning up the interfaces and also writing on a guideline for how to port riot to a new platform. I have already split the kernels interfaces into two groups, one containing all the stuff that is used internally or by driver and user code and one group that collects all interfaces that need to be implemented for each target cpu. The code is unfortunately not yet in a stage that allows to create a pull request, but I hope I will present it some point next week for review… Strongly agree on this one (thats why I started to clean up the interfaces in the first part…)! Cheers, Hauke
Since this platform is based on a family-2 MSP430 (F2617) --- a kind of MCU
not yet used in any current port in RIOT ---, I stumbled upon
inconsistencies with the already included header files.
I guess there are even more inconsistencies in board and cpu. Hauke was so
kind to create an overview about the current state of board and cpu headers
and the according implementations. He'll probably propose a new version of the
hardware interface that is more consistent and easier to understand.
I will sure look for it ; but with the modifications I proposed last week, I can go on and produce a first version of the Z1 port.
Maybe the term 'inconsistency' wasn't adequate... I meant that the MSP430F2617 present in the Zolertia has a very different way to handle UART/I2C/SPI communication than the MSPx16x already supported in current platforms, and thus I had to modify the way headers are included so as to include the definitions specific to that new MCU.
And then, I thought...
Instead of adding one more #ifdef case for including the correct headers, I
think we can just include <msp430.h> in all the concerned files : this is a
generic file that includes the correct specific headers when the right
symbol is defined.
What do you think?
+1
I've made the modifications and submitted a pull request in RIOT master repository (PR #408). Hope this will be useful.