No code changes, just file, variable and define names are changed.
First, it better describes the serial protocol used by DSMx satellite
receivers. Second, many people using Spektrum radio, assume Spektrum
protocol. This is the attempt to address those inaccuracies.
- 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).
TIM5-8. Also TIM1 was not handled probably (for CC either) as the name of the
IRQ is TIM1_CC and TIM1_UP for the capture compare versus update. I haven't
checked the downstream code that the registers it uses to map from a context to
event is invariant under timer channel.
