you respnded to my post from June 29th - more than 2 months old.
You really do some catching up
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.
yes, I understand the different capabilities of the hardwares and the non-portable structure of current mwii code.
Still, two separate forks will either require continuous work on both sides for porting back and forth or will drift apart over time.
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.
from what I understand your console is the equivalent of the lcd config menu in MWii. Of course you provide more/other options since you converted compile time switches into cli-selectable items; I like that runtime-select over compiletime.define; MWii on 328p cannot do that for all supported hardware and features due to limited resources.
In MWii, the lcd also serves the purpose of telemetry - via serial over wireless (BT or other) or to i2c displays. Dunno if/how baseflight does telemetry.
Anyway, LCD was only meant as an example to drive the point - baseflight and MWii are already apart; supported sensors might be another example?
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.
so indeed there is no backchannel.
I have 2 stm32 boards plus ulink2 in the drawer. I am waiting to see telemetry in baseflight with options for i2c displays and serial (over wireless, BT) gadgets (like smartphones with terminal programs).
You have done a load of work on baseflight and still do, I applaud you for that.
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?