Hamburger wrote:Yes it is a good starting point.
But I do not want forks but one multiplatform MWii source tree.
that is all being done now. Up until now, he has done
he updates just what he likes
what we need is TC on the forum adding his $.02, right?
dr.tom wrote:it looks someone else must integrate MS5611 sensor into baseflight
or at least write driver folowing timecop's rules.
itain wrote:
Personally, I do not think that timecop's port is a good base for this. He has ported parts of MultiWii to a specific board. Adding the missing features and making it run on atmega328p again may be more work than doing the required changes to the current codebase.
yes, that is part of what I call a problem in the long run. It _needs_ doing, because it is separate forks.
So not all features from arduino-mwii make it into stm32-mwii. Last I looked the entire LCD & telemetry stuff was not there.
Besides, there is no 'backchannel'. New features from the stm32 fork have no designated mechanism to become part of the arduino-mwii in an orderly fashion.
timecop wrote:Hamburger wrote:yes, that is part of what I call a problem in the long run. It _needs_ doing, because it is separate forks.
There is no way to "just use" mwc-8bit code directly because:
1) everything is a forest of #ifdef (here it's all compiled and and configurable at runtime)
2) drivers/control code is all mixed and there's no attempt to have any sort of abstraction layer - particularly bad examples: mag and baro stuff
3) 8bit shortcuts are done all over the place - 16 vs 32 bit multiplies if expected value < 65000 etc.
So not all features from arduino-mwii make it into stm32-mwii. Last I looked the entire LCD & telemetry stuff was not there.
LCD is unnecessary because of serial console. It would be basically duplicating all the same functionality of serial console and STILL wouldn't be able to be used as-is because there are a LOT more parameters to configure. For example I'd have to hack in way to change motor mixer or any of the other settings that are only exposed by serial console.
Besides, there is no 'backchannel'. New features from the stm32 fork have no designated mechanism to become part of the arduino-mwii in an orderly fashion.
It's a rewrite for proper hardware only reusing basically bits of control code. Any improvements, if any, would be made with assumption that the hardware is capable so adding an extra sinf() in the main loop doesn't take a week of deliberations and confirmation that it won't affect loop time on atmega168 running at 8MHz. As others said, the code is open and you're welcome to take back ideas or features - I'm sure mega2560 users would like to have a working serial console and all the settings configurable instead of having to recompile stuff. Or heck, forget console and just add them all to LCD if you're into that.
Hamburger wrote:For the sake of MWii, I still think it could benefit from a common source base instead of drifting forks. Alas, when I asked for input on a multi-platform MWii code there was little response. I understand it would not be easy. So it seems the pain is not yet strong enough, the benefits not sweet enough.
We shall keep watching out, right?
timecop wrote:Normal flight telemetry (via bt/xbee/whatever) and going to multiwiiconf works too..
nicog wrote:I'm sorry hamburguer,
but:
... If you ask me nicely I can add it.
...
I find using an old BT enabled smartphone/gadget Naze32 configurator is android 2.1 compatible, wich seems to be an old one.
nicog wrote:And if you want to use it, as you said, code it and commit to svn.
nicog wrote:I'm not competing with you either.
But my code is free to everyone. it's not closed source.
Please understand that the telemetry implementation maybe is not needed in the 32bits port.
timecop wrote:Yeah airplane mix stuff will be done separately, to allow servos/direction/etc.
Still planning a good way to do that.
Will probably merge flying wing and aeroplane mixers together, and just allow enough customization so it can be configured either way.
timecop wrote:With 8 servos available in airplane mix mode, I doubt there's going to be any need for a HACK.
And with serial GPS working in both PPM and PWM input modes, what's the point for I2C GPS again? Remind me. Another point of failure? OK, thanks.
timecop wrote:p.s. enabled GPS in PWM mode as well - reduces number of channels to 4RC+2 AUX.
timecop wrote:I have a solution that looks like a turd, I can commit it today.
Or I can spend some time on it and make it nice - something most 8bit devs dont seem to care about.
Users browsing this forum: No registered users and 0 guests