MultiWii

It's more an idea, but I thought I post it here, because it is more a software thing than a feature.

Alex announced that the code should be split into .c/.h files and I am thinking that it would be interesting if some stuff moved to C++ code (like the GPS code and Arduino code in general). By using classes one could "collect" all the hardware specific commands into one class and use it everywhere else (reading sensors, setting motors, timers, analog sensors, etc). Normally that's what Arduino was all about, but MultiWii often ignores those functions for better speed

Anyway ... collect those optimised hardware functions in one class and subclass it for different hardware (e.g. promini, micro, mega, stm32, arm, PC/x86, whatever there is), so MultiWii becomes a truly portable software. One could imagine a version where all the hardware is just simulated to test the logic or a version where the logic runs on hardware, but the sensors and motors are simulated on a PC (HIL)?

Interested?

another layer & C++ code seem to contradict the performance issue we are constantly fighting for (even with tasks like avoiding function calls whereever possible).
It really sounds like an interesting other project, just not MWii. Doing that together with moving to a real computer hardware with a real (realtime?) OS and enough performance to do everything according to todays latest software design and coding approaches. For tiny soc mcu? I doubt it - but I love to be surprised by facts.

Compilers are pretty good these days. There is no harm in replacing those i2c_init() i2_stop() i2c_write() etc functions with equivalent methods from a C++ class. I am willing to test that assumption

Replace the class and everything can run a totally different hardware.

If there is a code size reduction, this maybe a dream come true.

copterrichie wrote:If there is a code size reduction, this maybe a dream come true.

Ideally there should be no difference. It's just an effort to make code more modular so it can be ported more easily (and to implement simulation stuff, that's my motivation).

uha ... ran into a rather big problem ... Arduino really requires all the files to be in the same directory. The only alternative is to use a libraries folder in the sketch folder. Should be ok for an experiment, but can get ugly very quickly

C++ is aids, plain and simple

it is not ... anyway, I had some time and made a small HAL implementation that abstracts all the I2C stuff. It only works for quadx/nanowii configuration, because I was too lazy to replace all the calls to i2c_functions.

Compiled size increases (Leonardo) from 18792 bytes to 19230 bytes when using this abstraction. Might go into the kilobytes region, but I am currently not sure where these bytes are coming from

https://github.com/sebastianherp/multiw ... experiment

Comments?

P.S.: I am sure it can also be done with just functions, but that approach wouldn't be able to use inheritance and it's benefits, wouldn't it?
P.P.S.: It would be better to have those C++ classes in library folders next to the MultiWii folder. Reduces clutter, but wont be editable in the Arduino "IDE" then ...

c++ on an atmega makes me shrug :/
how can you seriously believe it will just be as performant as plain c-code.
clearly every layer of abstraction doesn't benefit performance but rather makes it worse as you just proved with the increased code size.
why not do the whole abstraction thing in c? for example baseflight actually has some hardware abstraction and is written only in c

Naysayers...

Because class->method(blabla) should be the same as function(blabla) except that no compiler complains when you fail to implement function(blabla) correctly.

Regarding the size issue, I think I know what is happening here. When using the .cpp/.c/.h approach the compiler wont/may not know which (member-) functions are unused when generating the .o file. Apparently the linker used isn't smart enough to figure that out and thus more bytes are used. Just tested that theory by commenting out some unused code in my test classes ...

That is ... meh! If Alex really wants to split up MultiWii this way (using c or c++ or whatever mixture) this might become a problem if binary sketch size stays a priority

Did arducopter get much bigger when they switched to a hal in 2.9 I thought?

Probably not, they used c++ code (libraries folder) before that switch

Ok, updated the branch (https://github.com/sebastianherp/multiw ... experiment) to use a class with static members. That is basically equivalent to the what's currently used and static members are being optimized away by the compiler when not used ...

... but it's not elegant at all.

Enough experimenting. Just thought it would be a good idea to have all code that uses hardware features in one place so the whole thing can be ported more easily to other plattforms and the base code looks cleaner (the Arduino way)

Peter wrote:Did arducopter get much bigger when they switched to a hal in 2.9 I thought?

look at the code - a mess does not getting better with a hal ...
the code sucks with regards to the timing.

the most important thing is the compiler.
the compiler for atmel sucks - unbelievable old.
c++ is a pain.

why not using a struct with function pointers inside.
this way you could write a mockup usable for example on a pc.

Ok, rewrote the thing so it uses a struct with function pointers. Better approach?

https://github.com/sebastianherp/multiw ... iWii_HAL.h
https://github.com/sebastianherp/multiw ... _HAL_AVR.h
https://github.com/sebastianherp/multiw ... AL_AVR.cpp (btw, when using the .c extension, the Arduino IDE doesn't compile the code in this file)

i think so - looks good to me.
now we have boards with spi.

brm wrote:i think so - looks good to me.
now we have boards with spi.

We have?

There's absolutely no need to bloat shit up with start/repeatstart/etc.
*ALL* i2c transactions can be written into a single function call each for read/write

read(addr, subaddr, buffer, length, flag_no_subaddr) and
write(addr, subaddr, buffer, length, flag_no_subaddr).

*every* device you can imagine will fit into the above 2 calls.
thanks!

Well, this wasn't about the beauty of the code. Just about separating out all hardware related stuff into one place so it can be easier ported ... originally Arduino code should have provided that, but as we all know, MultiWii isn't using much of the arduino API, right?

just read and write ...
hmm,
that shoot and forget methodoligy is strange.
open and close and a virtiul destructor is a 'must' ...
imagine you call read and the device is closed ...

Probably it will be useful. ziss_dm already done this for avr, stm32f1 and stm32f3 in his project...
https://code.google.com/p/mwc-ng/source ... Fsrc%2Fhal

Is baseflight able to run on Arduino hardware? Anyway, I just ordered a Flyduino MW32 to test something, if it doesn't work I hope baseflight works with airplanes (that's where I want to use it)?

I'd be happy when MultiWii is able to run on / compile for AVRs, STM32 and X86 (maybe ARM, like the RasPi). X86 might not have an I2C bus and it would be pointless to have the GUI on a serial port there, but one can always have simulated sensors/motors and UDP for the GUI

Sebbi wrote:Is baseflight able to run on Arduino hardware? Anyway, I just ordered a Flyduino MW32 to test something, if it doesn't work I hope baseflight works with airplanes (that's where I want to use it)?

I'd be happy when MultiWii is able to run on / compile for AVRs, STM32 and X86 (maybe ARM, like the RasPi). X86 might not have an I2C bus and it would be pointless to have the GUI on a serial port there, but one can always have simulated sensors/motors and UDP for the GUI

Speaking of the Raspberry PI, these are starting to appear on Ebay. On the backside, there is an ATMega328 and there is no reason why the required sensors could not reside there also. I can breadboard one but what would be very interesting is, to have MWC running the flight stabilization and the PI handling the navigation, Telemetry and Video feeds.


RC-servo controller board for Raspberry PI Version 3.

Well, I don't plan on flying the RasPi, but yeah ... it should be possible to run MultiWii (with sensors / servos / motors) directly on there if you can tolerate the rather long boot phase

Sebbi wrote:Well, I don't plan on flying the RasPi, but yeah ... it should be possible to run MultiWii (with sensors / servos / motors) directly on there if you can tolerate the rather long boot phase

Interesting, the boot time is not a problem, just power the PI from its own power source, something I do now with the GPS unit.

I got the Flyduino MW32 (pretty much the same as a Naze32) yesterday. Neat hardware and I'm looking forward to get MultiWii running on there, well at least the sensor reading and GUI part.

Making it Easier to Build Firmware

http://hackaday.com/2013/03/28/making-i ... -firmware/

That's just a makefile collection ...

But I found an interesting project: https://github.com/mlu/arduino-stm32 It is unfortunately over 3 years old, but the idea was to compile normal Arduino code so it runs on STM32. MultiWii doesn't only use Arduino code however ...

The point is, people are starting to think in terms of Multiple platforms. Hmmm.

Did you consider the following in your rush to belittle the project?

"Currently there’s support for AVR, MSP430, Stellaris ARM, and STM32L1. More devices are in the works, and suggestions are welcome. Hopefully this helps people get started building firmware that’s easy to build and distribute with projects."

I do not belittle the project, but it's not what I am looking for. It's just some repositories with makefiles so one can compile source code for either platforms on a linux system. I know how to compile code The thread is about rewriting the MultiWii code in a way so it can compile for multiple platforms. If we get this to work and nobody freaks out because of the file renaming, maybe this will be the way MultiWii is organized in the future and makes a transition to 32bit easier (and let MultiWii 2.2 run on Naze32 hardware ... even if you have to use #defines in config.h and don't get a CLI).

I'm not interested in this, my 8bit flight controllers work well for me. I was just sharing or BLOGGING as some have said.

Oh and if I were to become interested, I surely would not be deterred by naysayers. Ha.

Just a quick reply ... I had some free time and was able to modify MultiWii 2.3 code in a way so it can be compiled on different plattforms. Currently that is AVR/Arduino and X86 (using the Visual Studio c++ compiler). This version has no functionality yet, but it runs the loop with dummy sensor data. Next step: use socket communication for all the Serial* functions on x86 and modify the GUI to connect to it

P.S.: Loop time on my PC is between 1100 and 1500 nanoseconds