planning before going Multi Hardware achitectures

Post Reply
User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

planning before going Multi Hardware achitectures

Post by Hamburger »

Hi,
I am interested in a multi platform MultiWii. One joint code base instead of forks with different re-implementations (or not) of features. My original post viewtopic.php?f=8&t=1632 never got much attention, so I am happy to see increased interest in the 32 bit topic now. So I take the liberty to re-post - I think it is still valid

original post:
Hi,
seems more and more people becoming interested. At the same time lots of forks exist or are in the works. So maybe it is about time to rally up what aspects we want to be considered for the soon to come Multi Hardware Architectures strategy of MultiWii _before_ we really start coding for it. A well thought out layout should ease the pain.
(Me,, I have a personal interest in this as well, a FreeFlight stm32 board and a ulink2 are waiting for me, second stm32 board coming soon. Those should help me reduce debugging pain once the dev environment is up and running.)

- currently most cpus of the 8bit arduino family supported (pormini/nano/mega1280/mega2560/promicro)
- timecop has a fork for his stm32 port, exists isolated from current MWii development; also not all features ported/included.
- common source tree is desirable to keep maintenance tasks low (porting new features and fixes back and forth is boring)
- heavier cpus allow for more features, which is good (like config at runtime instead at compile time - example: servo orientation)
- need to preserve backwards compatibility to promini class of cpu (loads of working configs out there, do not want to loose those happy users)
- user experience must not become more difficult than it is now - loading code in arduino IDE, edit config.h and upload is about the maximum level of difficulty some people can cope with. (and for some that is too much already - but it is current status, so live with that)
- other hardware requires other toolchain and other IDE
- keep compatibility with arduino IDE somehow
- layout files & code for use with a real IDE for standard C code
- avoid the arduino automagic include mystery with .ino and .pde files
- use one .ino and multiple .c files?
- have #include the c files from the .ino file?
- may have to provide prototypes for the functions to compile?
- config at runtime instead at compile time for _all_ config items? For classic limited cpus must be possible to override per switch to compile instead of runtime option.
- is it desirable (if possible) to autodetect sensors (would need to compile in all sensors?)

to be continued...please

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: planning before going Multi Hardware achitectures

Post by Alexinparis »

Hamburger wrote:Hi,
I am interested in a multi platform MultiWii. One joint code base instead of forks with different re-implementations (or not) of features. My original post viewtopic.php?f=8&t=1632 never got much attention, so I am happy to see increased interest in the 32 bit topic now. So I take the liberty to re-post - I think it is still valid

original post:
Hi,
seems more and more people becoming interested. At the same time lots of forks exist or are in the works. So maybe it is about time to rally up what aspects we want to be considered for the soon to come Multi Hardware Architectures strategy of MultiWii _before_ we really start coding for it. A well thought out layout should ease the pain.
(Me,, I have a personal interest in this as well, a FreeFlight stm32 board and a ulink2 are waiting for me, second stm32 board coming soon. Those should help me reduce debugging pain once the dev environment is up and running.)

This is not what you are saying, but I would like to recall a point: a 32 bit board running multiwii won't make a multi fly better than for instance multiwii on a mega board. So, following the 32 bit trend is a nice purpose, but it must be done with this fact in mind.

- currently most cpus of the 8bit arduino family supported (pormini/nano/mega1280/mega2560/promicro)
- timecop has a fork for his stm32 port, exists isolated from current MWii development; also not all features ported/included.
- common source tree is desirable to keep maintenance tasks low (porting new features and fixes back and forth is boring)

I think it's possible to isolate every board specific code, and I think it would represent no more than 10% of all the code.

- heavier cpus allow for more features, which is good (like config at runtime instead at compile time - example: servo orientation)

right

- need to preserve backwards compatibility to promini class of cpu (loads of working configs out there, do not want to loose those happy users)

obviously mandatory, otherwise a fork is needed.

- user experience must not become more difficult than it is now - loading code in arduino IDE, edit config.h and upload is about the maximum level of difficulty some people can cope with. (and for some that is too much already - but it is current status, so live with that)

assuming we can take in the 32 bit code every possible configurations, it's maybe less important to ease the flash task.

- other hardware requires other toolchain and other IDE
- keep compatibility with arduino IDE somehow
- layout files & code for use with a real IDE for standard C code
- avoid the arduino automagic include mystery with .ino and .pde files
- use one .ino and multiple .c files?

I think it's possible with Arduino IDE as long as no folder is used.

- have #include the c files from the .ino file?
- may have to provide prototypes for the functions to compile?
- config at runtime instead at compile time for _all_ config items? For classic limited cpus must be possible to override per switch to compile instead of runtime option.
- is it desirable (if possible) to autodetect sensors (would need to compile in all sensors?)

autodetect would be useful only for 32 bit boards.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: planning before going Multi Hardware achitectures

Post by copterrichie »

Hamburger, I'm sorry, I completely missed this post.

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: planning before going Multi Hardware achitectures

Post by Hamburger »

copterrichie wrote:Hamburger, I'm sorry, I completely missed this post.

copterrichie,
no problem, everyone else did miss the original post just like you.
Well, here's your chance, fire away now.

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: planning before going Multi Hardware achitectures

Post by ronco »

Hi,

i know the most of you "32bit users" dont like arduino at all ;)

but would it be possible to write a java plugin for it to support the st32? just like paul stoffregen did for the teensys?

with something like this it would be simpler to keep the code togather and it will stay open source..

regards

Felix

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: planning before going Multi Hardware achitectures

Post by Alexinparis »

Yes, I forgot to say: free or open source tools are mandatory ;)

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: planning before going Multi Hardware achitectures

Post by kos »

Alexinparis wrote:Yes, I forgot to say: free or open source tools are mandatory ;)

Free AND Open Source

ps : i forked mutlwii to run on linux with any cpu . i aggree that the specific code for each board is a low percentage of the total loc: but it also implies some major refactoring (32bit port is a non portable crap)

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: planning before going Multi Hardware achitectures

Post by Hamburger »

sure. I was always thinking Makefile plus some gcc like compiler.
Dev environment must be available for at least the 3 OS (win, linux, macosx) just like Arduino IDE.
About your linux port: are you syncing your fork constantly? Where is it to be seen?

msev
Posts: 186
Joined: Thu Apr 14, 2011 11:49 am

Re: planning before going Multi Hardware achitectures

Post by msev »

Would it be sensible to run this linux fork on raspberry pi?

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: planning before going Multi Hardware achitectures

Post by copterrichie »

Here is a link for the Maple STM32, not sure if it can be used for other STM32 boards: http://leaflabs.com/docs/maple-ide-install.html

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: planning before going Multi Hardware achitectures

Post by kos »

Hamburger wrote:About your linux port: are you syncing your fork constantly? Where is it to be seen?


i am not , this is mainly for educational purpose, not enough spare time ;)

https://github.com/treymarc/multiwii

msev wrote:Would it be sensible to run this linux fork on raspberry pi?


you only need a /dev/ic2c-* bus and the kernel source

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: planning before going Multi Hardware achitectures

Post by Hamburger »

kos,
that looks real clean. I can see you are not a C dev. not a Linux dev. not a Multiwii dev :)
As a side note: I take it that could run in a linux-VM by itself and the java-GUI on the host-os (I have no experience with accessing programs inside a VM via serial)?

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: planning before going Multi Hardware achitectures

Post by Hamburger »

So it looks like
- for arduino arch we keep compatibility with Arduino IDE (just like now),
- for other archs we could rely on gcc-like compiler plus Makefile plus arbitrary IDE (like Eclipse).

on compile vs. runtime setup:
- for arduino arch we must stick with compile time setup (just like now) because of runtime memory limitations,
- for other archs we are free to offer either likewise or offer runtime setup (like baseflight cmdline) or both

alexia
Posts: 85
Joined: Sun Jun 17, 2012 10:23 pm
Contact:

Re: planning before going Multi Hardware achitectures

Post by alexia »

i think before to change of cpu ,multiwii should resolve all small problem like autolevel
i hope multiwii doesn t become like arducopter which have lots of features but which doesn t work very well...
the spirit of this code is userfriendly with good performance!
the most important things is to have a proper stable mode and good baro!(waypoint for example shouldn t be present on the multiwii project!)

sismeiro
Posts: 173
Joined: Tue Feb 21, 2012 12:33 pm

Re: planning before going Multi Hardware achitectures

Post by sismeiro »

alexia wrote:i think before to change of cpu ,multiwii should resolve all small problem like autolevel

Hi Alexia,

Can you please explain the problem with autolevel? I use autolevel (ACC mode) and I don't find any problem but maybe I am no enough experienced to understand if I have one.

Also I read some other people telling about baro problems but from what I saw in this and other forums, with the correct PID configuration it works very well. I haven't tried to use the baro on my FC.

Regards,
Luis Sismeiro

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: planning before going Multi Hardware achitectures

Post by Hamburger »

Some errors become more isible when porting code.
Besides it is open source so you are always welcome to help fixing what you think is broken.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: planning before going Multi Hardware achitectures

Post by Alexinparis »

alexia wrote:the most important things is to have a proper stable mode and good baro!(waypoint for example shouldn t be present on the multiwii project!)

I have the same question: do you consider a proper stable mode is still not here ?
I admit some baro problems, but the stable mode should be ok now.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: planning before going Multi Hardware achitectures

Post by copterrichie »

Alexinparis wrote:
alexia wrote:the most important things is to have a proper stable mode and good baro!(waypoint for example shouldn t be present on the multiwii project!)

I have the same question: do you consider a proper stable mode is still not here ?
I admit some baro problems, but the stable mode should be ok now.


I think some people are having problems with Trimming and making adjustments to the LEVEL PID. Maybe some good documentation on this will help because even for me, it is confusing at times. :)

User avatar
Hamburger
Posts: 2560
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: planning before going Multi Hardware achitectures

Post by Hamburger »

As you may not have followed the discussion on porting to other hardwares, I will repeat one of the motives to porrt MWii to other hardwares was that some offer better debug support than arduino does. This should help finding some errors in algorithms.

as a reminder: this thread is on the topic of things related to planning a multi hardwares architecture aware MWii. This includes aspects like file layout, naming conventions and coding etc. It is not helpful to insert another petition for feature repairs here. Those bugs may or may not exist, those may or may not be found and repaired. You must use other threads for discussion on possibly broken features, please.

So let us get back to the topic issue: other thoughts on the planning, please?

alexia
Posts: 85
Joined: Sun Jun 17, 2012 10:23 pm
Contact:

Re: planning before going Multi Hardware achitectures

Post by alexia »

copterrichie wrote:
Alexinparis wrote:
alexia wrote:the most important things is to have a proper stable mode and good baro!(waypoint for example shouldn t be present on the multiwii project!)

I have the same question: do you consider a proper stable mode is still not here ?
I admit some baro problems, but the stable mode should be ok now.


I think some people are having problems with Trimming and making adjustments to the LEVEL PID. Maybe some good documentation on this will help because even for me, it is confusing at times. :)



you are right!
i am a newbie with multiwii so it s possibile i made a mistake during trimming processing 8-)

i try to read eveything about multiwii to improve my tunes! i can say thank for all you hard work and this great code

Post Reply