- both CC serial ports are now disabled by default (no telemetry);
- serial ports now have DSM2, DSMX (10bit) and DSMX (11bit) options;
- ReceiverGroups now have DSM (MainPort) and DSM (FlexiPort) options.
For DSM2 protocol there is an explicit resolution bit in the stream, so
the DSM2 should be selected. For DSMX there is no such bit, and user
should choose the resolution from the list configuring the spektrum port.
ReceiverGroups have single DSM option which is handled by the same driver.
Downside: this implementation saves received frame first, unrolls by the
end of frame. This should be ok, but may be improved by unrolling channels
on the fly in the rx callback.
Another minor difference is that a ChannelGroup is now bound to port:
DSM (MainPort) or DSM (FlexiPort). This was considered as acceptable
solution in order to not have 6 DSM options for each ChannelGroup and
even more in case of new DSM protocol variations.
Known problem: it is not possible to choose same protocols like
DSM2/DSM2 for two ports. It can be enabled by adding an exception to
common rule, though.
The DSMX throttle channel misbehavior (zero value) is not treated
specially yet. It should trigger the failsafe being out of bounds.
More info and data dumps are required to handle this properly.
PPM. This saves resources. Good suggestion Os. In this configuration we
could allow 12 channels of output but for now I'll leave it capped at 10 to
lessen resources on the mixer table.
With spektrum and camera stab enabled there was
1632 bytes heap remaining
180 bytes irq stack remaining
In the previous version the decoder could in rare cases get synced from
the middle of data stream in case of data byte equal to the S.Bus start
of frame (SOF) byte (wrong data will be rejected but it was not perfect).
Now it waits for the real start of frame and then checks the SOF byte.
- does not glitch when used in 2-frame mode (DM9, 9503, etc)
- does NOT provides yet DSMX stream decoding - do NOT merge
- uses a bit more time in the interrupt, but frees 16 bytes of RAM.
This is done to help decoding the weird DSMX stream which does not
contain explicit resolution/frame/lost frames info and needs special
processing (to be done yet).
PWM and PPM can now coexist in the same load and be
selected at boot time via the hwsettings UAVObject.
This is basically a complete restructuring of the
way the drivers interact with the TIM peripheral in
the STM32.
As a side effect, the PWM and PPM drivers are now
ready to support multiple instances of each.
This also provides the first step toward being able
to reassign some of the PWM input pins to be servo
output pins. Still more work required, but this is
a good start.
This allows the GCS to emulate a receiver device via the
telemetry link.
Select "GCS" as your input type in the manualcontrol config
screen and calibrate it as normal.
Note: The expected values for the channels are in microseconds
just like a PWM or PPM input device. The channel values
are validated against minimum/maximum pulse lengths just
like normal receivers.
This allows the spektrum and sbus receiver drivers to bind
directly to the usart layer using a properly exported API
rather than overriding the interrupt handler.
Bytes are now pushed directly from the usart layer into the
com layer without any buffering. The com layer performs all
of the buffering.
A further benefit from this approach is that we can put all
blocking/non-blocking behaviour into the COM layer and not
in the underlying drivers.
Misc related changes:
- Remove obsolete .handler field from irq configs
- Adapt all users of PIOS_COM_* functions to new API
- Fixup callers of PIOS_USB_HID_Init()
Each channel was previously tracking a separate driver.
Now, channels are grouped within a channel group to save
RAM used for tracking and to better reflect how channels
are actually mapped.
Working spektrum bind routine, depending your TX try BIND_PULSES 3,5,7,9 (5 works with DX7)
Boot process takes too long on MB so bind command misses the window (20-140ms).
This is a port of a work-in-progress by Sambas onto
the new driver infrastructure needed for boot-time
configuration.
PPM and PWM still don't coexist in a build but this
is closer.
The initial baud rates of each interface are now forced in the
board init code.
Any modules using USARTs should have fields added to
their settings object to allow the user to change the
baud rate from the default by using the COM layer APIs.
Developers requiring custom baud rates before the settings
objects are in place should locally edit the cfg structs
to specify the desired baud rates.
This should mark an end to the compile-time selection of HW
configurations.
Minor changes in board initialization for all platforms:
- Most config structs are marked static to prevent badly written
drivers from directly referring to config data.
- Adapt to changes in .irq fields in config data.
- Adapt to changes in USART IRQ handling.
Major changes in board initialization for CC:
- Use HwSettings UAVObj to decide which drivers to attach to
the "main" port and the flexi port, and select the appropriate
device configuration data.
- HwSettings allows choosing between Disabled, Telemetry, SBUS,
Spektrum,GPS, and I2C for each of the two ports.
- Use ManualControlSettings.InputMode to init/configure the
appropriate receiver module, and register its available rx channels
with the PIOS_RCVR layer. Can choose between PWM, Spektrum and PPM
at board init time. PPM driver is broken, and SBUS will work once
it is added to this UAVObj as an option.
- CC build now includes code for SBUS, Spektrum and PWM receivers in
every firmware image.
PIOS_USART driver:
- Now handles its own low-level IRQs internally
- If NULL upper-level IRQ handler is bound in at board init time
then rx/tx is satisfied by internal PIOS_USART buffered IO routines
which are (typically) attached to the COM layer.
- If an alternate upper-level IRQ handler is bound in at board init
then that handler is called and expected to clear down the USART
IRQ sources. This is used by Spektrum and SBUS drivers.
PIOS_SBUS and PIOS_SPEKTRUM drivers:
- Improved data/API hiding
- No longer assume they know where their config data is stored which
allows for boot-time alternate configurations for the driver.
- Now registers an upper-level IRQ handlerwith the USART layer to
decouple the driver from which USART it is actually attached to.
This separates the RTC device and interrupt handling
from the devices that rely on the tick notifications.
Drivers can now register tick notification functions
that will be called on each RTC tick event.
All receivers now fall under the same driver API provided
by pios_rcvr.c.
This is part of a larger sequence of commits that will
switch the receiver selection over to boot time dynamic
configuration via UAVObjects.
It was tested being merged with OP-472_CorvusCorax_CopterControl-Guidance_v3
branch, Spektrum on USART3 and GPS on USART1 and seems to work.
Currently defaults mimic original behavior, that is, if USE_SPEKTRUM
is not defined - define USE_PWM and USE_GPS. Thsi should be refactored
later to make it configurable from the Makefile.
Also it was not ported to the OP MB: it currently does not support the
S.Bus hardware and still has original behavior with the patch. But this
is one more step to dynamic configuration of ports.
TODO: This should be dynamic in the future.
But for now define any compatile combination of:
USE_I2C (shared with USART3)
USE_TELEMETRY
USE_GPS
USE_SPEKTRUM
USE_SBUS (USART1 only, it needs an invertor)
and optionally define PIOS_PORT_* to USART port numbers
Defaults are:
#define PIOS_PORT_TELEMETRY 1
#define PIOS_PORT_GPS 3
#define PIOS_PORT_SPEKTRUM 3
#define PIOS_PORT_SBUS 1
#define USE_TELEMETRY
#define USE_GPS
Telemetry, GPS and PWM input are enabled by default.
