This enables a new feature setting for PARALLEL_PWM which is enabled by
default.
This starts to move much of the feature checking/excluding code that is
littered through into a single place - validateAndFixConfig(). Since
the config is known to be valid after the method is called other code
can just get on with it's job instead of checking for confliciting
features/settings.
Currently port usage is hard-coded to the default port layout, cli
commands are coming in a future commit.
This decouples all code from the global 'serialPorts' structure which
has been removed. Any code that needs to use a serial port can use
findOpenSerialPort() and openSerialPort() and maintain it's own
reference to the port.
Ports can switch between functions. e.g. by default
cli/msp/telemetry/gps
passthrough all use USART1. Each port maintains it's current function.
see begin/endSerialPortFunction.
There are only certain combinations of serial port functions that are
supported, these are listed in serialPortFunctionScenario_e.
This commit also adds a few 'static' keywords to variables that should
have been.
There a a few other minor fixes and tweaks to various bits of code that
this uncovered too.
connected instead of the 'midrc' value.
Achieved by deleting unnecessary legacy ardino code.
Discussion here:
http://www.multiwii.com/forum/viewtopic.php?f=8&t=5063&p=50635#p50634
Basically it was there because the Ardiuno PPMSUM timer resolution is
lower than the STM32 code we use.
With a Grapner GR-24 receiver using parallel PWM or PPM (12channel) the
values hardly fluctuate at all, slightly more noticable with parallel
PWM input.
This removes a number of FIXMEs regarding driver dependencies on the
main code.
The code to verify pulse lengths is now in computeRC which means that
all RX drivers do not have to duplicate the pulse length checking code.
This means that failsafe can be used to validate serial RX providers as
well as PWM/PPM RX providers.
2d248676f5. MSP RX ignored rc channel
mapping.
Symptoms: power up FC using parallel PWM or PPM with no receiver
attached. Connect GUI tool to view receiver data. Observe that each
channel has a reading of '2' instead of somewhere near 'midrc'.
Symptoms: rxMsp ignored rc channel map, cli 'map' command had no effect.
This commit re-instates the code that checked to see if an rc channel
value was in the correct range but moved it into computeRC where it
really belongs.
Additionally to the code to remap rc channels was moved from the rx
implementations into the computeRc method. This results in smaller code
size, no duplication of logic avoids having to pass rxConfig to each rx
read method and finally fixes rxMsp so that channel mapping can be used.
Failsafe still works as intended, verified by using parallel PWM, arming
and then pulling out the throttle PWM inpout cable.
This also improves code cleanliness since now each rawRawRc method in
the RX implementations does not have to remap the channels. The methods
now do only what their name says.
Decoupled mpu6050 acc and gyro detection code.
This commit cleans up the #ifdef/#ifndef code which, due to the amount
of targets and variants, was starting to get a bit out of hand.
Now each acc & gyro is assumed to be used unless the respective
USE_ACC_* and USE_GYRO_* is #undef'd at the top of the file by a
particular target.
This commit also cleans up the mess of re-running all the mpu6050
detection code twice. Now the acc specific communication code is only
run once and only code that is actually needed to be run twice is run
twice, and the rest of the code is now only used once. This will
improve board startup time, albeit negligibly.
Sensor alignment is only known for the NAZE target so now the alignment
will be ALIGN_DEFAULT for all targets other than NAZE unless they are
known.
Finally, in the Makefile a file was included twice in the source list
for the STM32F3DISCOVERY target and now additional sensors are supported
for users that may want to try them on that board.
By decoupling everything the structures now only contain members they need. The mapping code is simplified. The calculation of timer periods is now where it belongs (with the output code, not with the mapping code). Also, since each motor output has it's own callback method it is technically possible to mix brushed and brushless motors if the brushed motors and brushless motors use different timers. Additional code would be required to fully support that.
Dominic Clifton
dongie
luggi
treymarc
DTF UHF