Should we fork code for Mega2560?
Should we fork code for Mega2560?
Hi Guys,
It's really amazing what was done on this project. I never thought that a processor as small as the AtMega328 could fulfill the needs of a full blown multirotor flight controller. (even with gps rth). However it's clear that the project is reaching the limits of the mega328 and further development will be more and more constrained by the limitations of memory and ports.
The question is: Could we go forward with the current single codebase and use sophisticated defines to separate parts that does not work on 328? This solution has the advantage, since it's easier to maintain, but also make the code hard to read, and eventually cause constrains on certain parts of the code.
OR
We can fork the code and maintain a separated codebase for 328 and for 2560? This will add some workload for backporting fixes and improvements between forks, but as I see, this can help to speed up the development of new functions such as waypoint navigation or mav-link implementation.
Alex and all other contributors, what do you think?
It's really amazing what was done on this project. I never thought that a processor as small as the AtMega328 could fulfill the needs of a full blown multirotor flight controller. (even with gps rth). However it's clear that the project is reaching the limits of the mega328 and further development will be more and more constrained by the limitations of memory and ports.
The question is: Could we go forward with the current single codebase and use sophisticated defines to separate parts that does not work on 328? This solution has the advantage, since it's easier to maintain, but also make the code hard to read, and eventually cause constrains on certain parts of the code.
OR
We can fork the code and maintain a separated codebase for 328 and for 2560? This will add some workload for backporting fixes and improvements between forks, but as I see, this can help to speed up the development of new functions such as waypoint navigation or mav-link implementation.
Alex and all other contributors, what do you think?
Re: Should we fork code for Mega2560?
no need to fork now.
Avoid separate code bases as long as possible.
Avoid separate code bases as long as possible.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Should we fork code for Mega2560?
Hamburger wrote:no need to fork now.
Avoid separate code bases as long as possible.
Agreed,
at my company we are spending a lot of time to keep everythin in one project.
Re: Should we fork code for Mega2560?
May be its the time to fade out AtMega328
Re: Should we fork code for Mega2560?
wahaha99 wrote:May be its the time to fade out AtMega328
if you want to have a quad flying with a brain you have to option :
- port the multiwii source to a high level board [1]
- connect a high level board to a working flight controler ..and in this case you want to avoid 5v ( 328p 8mhz,3.3v is great)
an 328p can add flight abilities to any projects and those projects can in turn enhance the initial capabilities of multiwii. an autopilote (input) or mavlink (output) are not real part of the flight controler .. they are connected to it
Do one thing, and do it well .
- send command to servo/motor (two array) to adjust current attitude (getestimatedAttitude() and getestimatedAitude ) with the correction describe by the input (currently rcdata)
everything else is extra code .
so unless an 328p can not handle this task there is no reason to fade it out.. also there is no reason to set a limits to the numbers of components just because they do not all fit in memory
1 : I have multiwii running on this board
Re: Should we fork code for Mega2560?
@EOSBandi
Great idea,
Now it's time for me to make a 2560 Multiwii board.
(low cost to keep Multiwii mind).
It is Alex idea to keep the arduino IDE and to keep it simpele.
So ATMega2560 is a good choice.
Start drawing?
Rob Keij
Great idea,
Now it's time for me to make a 2560 Multiwii board.
(low cost to keep Multiwii mind).
It is Alex idea to keep the arduino IDE and to keep it simpele.
So ATMega2560 is a good choice.
Start drawing?
Rob Keij
Re: Should we fork code for Mega2560?
Why not start reducing the memory footprint of the existing Multiwii code first? There are so many line of code where memory (both flash and RAM) is tossed out of the window.
Re: Should we fork code for Mega2560?
Or move to a real processor (stm32)
Re: Should we fork code for Mega2560?
dongs wrote:Or move to a real processor (stm32)
I was waiting for you ! I really love your enthusiasm about moving to a powerfull platform And I share it, but don't forget that couple of thousands people who currently has 328 and 1280/2560 based MultiWii boards....
Re: Should we fork code for Mega2560?
Rob wrote:@EOSBandi
Great idea,
Now it's time for me to make a 2560 Multiwii board.
(low cost to keep Multiwii mind).
It is Alex idea to keep the arduino IDE and to keep it simpele.
So ATMega2560 is a good choice.
Start drawing?
Rob Keij
All my devs are made on my 2560 based board. I'm at ver4 and soon will have ver5. I'll find an affiliate who can manufacture and sell them... (I'm not interested on making a business out from MultiWii, I believe in donationware )
Re: Should we fork code for Mega2560?
EOSBandi wrote:dongs wrote:Or move to a real processor (stm32)
I was waiting for you ! I really love your enthusiasm about moving to a powerfull platform And I share it, but don't forget that couple of thousands people who currently has 328 and 1280/2560 based MultiWii boards....
so if you're waiting, why did you make a new post right above this one trying to continue perpetuating fail by making MORE failmega hardware?
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Should we fork code for Mega2560?
The strength of multiwii has always been the affordable and easy to get harware like a Wii Motion Plus or an ARduino Pro Mini.
If we want a perfect ahrdware and software solution we could call ourselves Miktrokopter and take load of money for a platform that is worse than multiwii.
I predict that if you branch to a new hardware you will miss out a lot of features that only will be developed by people like me that do not want to spent all their money and time for sophisticated hard and software.
IMHO multiwii as it is is the best platform available and that is because of the huge community and their crowdsourcing and betatesting ability.
If we want a perfect ahrdware and software solution we could call ourselves Miktrokopter and take load of money for a platform that is worse than multiwii.
I predict that if you branch to a new hardware you will miss out a lot of features that only will be developed by people like me that do not want to spent all their money and time for sophisticated hard and software.
IMHO multiwii as it is is the best platform available and that is because of the huge community and their crowdsourcing and betatesting ability.
Re: Should we fork code for Mega2560?
Maybe stupid question but ...
I saw Maple board @ Sparkfun, it have STM32 it have some compatibility with Arduino and IDE is very close.
So - maybe this could be less painful way to move forward.
Tom
I saw Maple board @ Sparkfun, it have STM32 it have some compatibility with Arduino and IDE is very close.
So - maybe this could be less painful way to move forward.
Tom
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Should we fork code for Mega2560?
IMO, the only issue with going with the STM32 at present is, the availability of a FREE or cheap IDE. Once that problem is resolved, the floodgates are open.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: Should we fork code for Mega2560?
Tifani wrote:http://leaflabs.com/docs/maple-ide-install.html
Awesome, going to give Maple a try now.