The exti layer now allows drivers to register interrupt callbacks
during board initialization. All details of the driver using a
particular EXTI pin have been removed from the EXTI layer so it
can now be used on any board without board-specific modification.
This includes some nice refinements provided by Mike Smith during
initial review. His original commits have been squashed into this
one.
This allows each device to be moved (at compile time) to a
different adapter. This is the first step to allowing devices
to be attached to different i2c adapters.
The main purpose of this new COM implementation is that it is
much simpler, and requires less code space. This takes a bit
of the pressure off of the CC bootloader which was right at
the limit of available code space in the bootloader partition.
This is not intended to ever be used by the application.
This driver also formalizes the assumptions in the bootloader's
usage of the COM layer. All messages are assumed to arrive
in atomic chunks from the HID layer.
These files do not contain content from the ID in the header.
This name seems to have been cut/pasted all over throughout
the openpilot source tree and should be removed from any files
that should not rightfully be attributed to this person.
The PIOS_COM_ReceiveBufferUsed() function call is no longer
necessary since the same semantics can be achieved using calls
to PIOS_COM_ReceiveBuffer().
Summary of changes:
* USB CDC and HID drivers are completely split apart.
* This will allow different max buffer sizes for HID and CDC.
* USB descriptors have been overhauled:
* Proper structs/macros/enums declared for USB (see pios_usb_defs.h)
* Two common descriptor definitions. One for HID+CDC another for HID only.
See pios_usb_desc_{hid_cdc,hid_only}.c for details.
* Long standing bugs in OP USB descriptors became much more obvious with the
new struct definitions.
* Board specific USB initialization is now in pios_usb_board_data.h in each build target.
* Definition of USB descriptors is now entirely indpendent of STM32 libs.
Glue into STM32 libs is provided by pios_usbhook.c.
* Removed a lot of stale/irrelevant USB #defines throughout the tree.
* Improved naming consistency throughout USB code:
* PIOS_USB_HID_* now refers to the HID endpoint code.
* PIOS_USB_CDC_* now refers to the CDC endpoint code.
* PIOS_USB_* now refers to the low-level USB code.
* PIOS_USB_BOARD_* now refers to board-specific USB data
* PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs.
* struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec.
* Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM.
* Made a few more USB related variables static to save some RAM.
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.
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.
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.
them symbolic constants.
- A timeout is 0
- A missing driver is 65534
- An invalid channel is 65535
ManualControl: Make it deal with the values explicitly. A timed out value
should not be treated like a minimum duration signal. Instead it does not
updated the scaled value but marks the data window as invalid to trigger the
failsafe.
Allocate per-instance data for drivers from the heap
rather than as static variables from the .data segment.
This converts > 800 bytes of RAM from being always consumed
as static data into being allocated from the heap only when
a particular feature is enabled in the hwsettings object.
A minimal config (no receivers, flexi port disabled, main port
disabled) leaves 2448 bytes of free heap. That's our new baseline.
Approximate RAM (heap) costs of enabling various features:
+ 632 Serial Telemetry (includes 400 bytes of Rx/Tx buffers)
+ 108 PWM Rcvr
+ 152 PPM Rcvr
+ 112 Spektrum Rcvr
+ 24 S.Bus (Should be closer to 68 since driver is still using
static memory)
There are still some drivers that pre-allocate all of their memory
as static data. It'll take some work to convert those over to
dynamically allocating their instance data.
needed by users because if too much changes I change the FS magic and trigger a
wipe.
Possibly the erase should require a particular "magic" object id value to
execute? This would make it harder to do manually through UAVOs though.
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.
