The GCS hwsettings config widget now disallows any
configuration that disables both HID and VCP telemetry
over the USB port.
The firmware will allow it if the UAVObj is set manually.
This allows a mechanism to reduce RAM usage by another
500 more bytes if USB telemetry can be sacrificed in
certain configurations.
Not all transmitters will continue to run when disconnected.
USB is one example of this. When the USB cable was disconnected,
any transmitter blocked here would wait forever.
This was particularly noticeable when the telemetry Tx task
blocked forever on USB disconnect. This also resulted in
the telemetry Rx task blocking forever waiting on the UAVTalk
connection lock.
We now block for a max of 5s waiting for space in the transmit
buffer.
This allows the HID and VCP functions to be configured
separately so that additional functions can be more easily
bound to the VCP port.
This change also provides a safety net that forces either
the HID or VCP to be configured for USB Telemetry. This
safety net may vanish in the future once the GCS can check
it. Disabling USB Telemetry entirely would save more than
400 bytes of RAM.
The uavtalk layer was previously implementing a poor
version of packet fragmentation based on a hard-coded
max packet size. Since this was hard-coded, there was
no guarantee that it would match the underlying devices.
Now that the COM layer sending routines support fragmentation,
remove fragmentation and use the COM layer directly.
This will support future buffer size reductions in the COM
layer.
PIOS_COM_SendBufferNonBlocking() will now fragment its buffer
to match the max size of the underlying device.
This allows the buffer size of the underlying device to shrink
below the maximum message size, thus allowing us to use smaller
buffers on memory-constrained platforms.
Apple is very particular about requiring the bDeviceClass
to be set to 2 (Commmunication Device) even for composite
devices which seems wrong.
Device is enumerated without error on Mac now. Not sure if it
works though.
Reduced scope of many variables since they were being
exposed unnecessarily.
Renamed pios_usb_hid_prop code to pios_usbhook to reflect
the fact that it implements all of the callout functions
that are hooked into the stm32 usb library.
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).
TelemetrySettings object removed (saved 200+ bytes of RAM). Telemetry
port speed moved to the HwSettings object. Added GPS port speed setting.
GCS code updated to reflect changes and support both fields.
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.
