Making MultiWii portable - how?

[itain]

Probably people are already working on it, but I do not see related forum activity (have I missed anything?).

Here is my suggestion.

I have looked through the code and done some experimenting. Here is how I think making MultiWii portable can be done.

Step zero: Some cleanup. This could be done later but I think it's better to start with less warnings than we have now. (arduino does not show these warnings but I do see them when compiling using Makefile)
Mainly, some gps_ and nav_ variables could be under #if GPS.
Have all functions prototyped (add void to parameterless functions).

Step one: Move code from .ino files to .c and .h files. Every .ino file renamed to .c. Variable and function declarations can be moved to .h file. Function definitions and variable initialization must stay in .c files.
A common MultiWii.h can include Arduino.h and all the shared definitions.
Many static variables and function should become unstatic.
Some rearrangement is required.
inlined functions can be moved to separate .h files that are included only where they are used.
A single .ino file must be added to support compilation under arduino. Actually it can be empty if we have either main, or setup and loop in .c files.

possible gotchas:
a. Look for sizeof on initialized arrays and strings! sizeof will not work correctly if initialization and usage are in different C files.
b. in Output.ino
uint8_t PWM_PIN[8] = {9,10,11,3,6,5,A2,12};
This kind of initialization is invalid in C because A2 is not considerd a compile-time constant. (It will compile in C++). I suggest moving these initializations into the only function that's using them.

I estimate that step one could take quite intensive two or three days of a single experienced programmer.
At the end of step one everything should compile and run, still under arduino.
When compiled outside arduino it is desirable to have 0 errors and 0 warnings!

Step two:
Actions can be paralleled...
a. Splitting C files can cost in some missing optimizations. Estimate how painful
it is, and provide solutions where required.
b. Testing of all functions and features.

Step three:
Further separate (or #ifdef) ATMega and arduino dependent code. Some estimates say it's no more than 15% of all code, but now it's spread around most files.

Step four:
First port to new architecture. Actually I suggest porting to non-arduino ATMega (that should be easy). Some functions (micros, millis) must be implemented in every supported architecture. Other (pinMode?) may be avoided. Another architecture I'm looking at is the ATXMega. It is a similar CPU as the ATMega abut all the devices are different.

Step five:
At this point, porting to new architectures is possible but not easy. This is because there is no definition of an abstract interface for some mandatory devices like usart, I2C and PWM.
Also, variable sizes may be inconsistent between architectures, or chosen size may not be optimal (on ARM arch, uint8_t may work but it may be more expensive than uint32_t).
After reviewing several architectures (and possibly already implemented ports) define a common, efficient interface that every architecture must implement in order to be supported by MultiWii.

-- Itai

[Hamburger]

Look in 32bit general discussions