Inconsistent use of debug macros in board definition files resulted in
BU compilation error. It was attempted to use PIOS_COM_SendFormattedStringNonBlocking()
directly even if PIOS_COM was not included (like for BootloaderUpdater).
So this function in pios_debug.c was replaced by DEBUG_PRINTF() macro.
The macro itself is defined in pios_debug.h file. Its definitions are
removed from board files. And to use it one has to define in pios_config.h:
#define PIOS_INCLUDE_DEBUG_CONSOLE
#define DEBUG_LEVEL <number>
in addition to PIOS_INCLUDE_COM with aux port.
Conflicts:
flight/PiOS/Boards/STM32103CB_PIPXTREME_Rev1.h
flight/PiOS/Boards/STM32F4xx_RevoMini.h
The difference was in dfs_sdcard.c, line 107:
-if((status = PIOS_SDCARD_SectorRead(sector, buffer)) < 0) {
+if((status = PIOS_SDCARD_SectorRead(sector, buffer)) != 0) {
Currenly unused, kept as is.
Now PipXtreme uses the same apps-defs.mk file as CopterControl.
Next steps are F4 boards.
Conflicts:
flight/targets/PipXtreme/Makefile
flight/targets/PipXtreme/System/inc/pios_config.h
When more than one task is concurrently trying to access
the same i2c bus and a timeout occurs on bus lock the
transfer would just continue and blow up the pios_i2c
driver. This has been fixed.
There shouldn't be any reason to need 8-byte alignment on the
F1 platform. This allows better packing of all malloc'd data.
Reducing this below 4-byte alignment is not recommended and will
likely result in misaligned pointers being passed to peripherals.
RAM savings is another 300 bytes.
The SET_LINE_CODING request contains data and must be
handled as such.
Previously, the only requests that had data were IN
requests. SET_LINE_CODING is an OUT request so it
required additional changes to support a new type of
data request.
The CDC interface is always advertised in the FW USB
descriptors. It is NOT always enabled/initialized at
runtime. Specifically, it can be Disabled in HwSettings.
Previously, any CDC-related query that the host would send
resulted in an assert and a watchdog.
Now, a suitable return code indicating that the request is
unsupported is returned in this scenario.
Scales each channel only based on max and min calibrated values.
The neutral value is now ignored so the joystick sees a linear
range between min and max.
This is particularly useful to allow the full range of values for
throttle to be passed through to the joystick.
The bootloader needs to understand whether the USB cable
is connected. The HID and CDC drivers need to know if
the cable is connected _and_ the device has been enumerated
already. Separate these two concepts in the API.
Combining these was resulting in the BL not properly
detecting that the cable was plugged in, and trying to boot
the firmware image immediately. This effectively bricked
the board if you ever had an invalid firmware image.
It also happens to be the case that the BU images automatically
invalidate themselves after updating the BL so they don't run
again. The cable detect bug + this intended behaviour of the
BU image resulted in a bricked board after upgrading the BL.
USB device was being accessed prior to being initialized.
This resulted in a hard-fault or NMI when using any endpoint
beyond 0 or 1 which are init'ed by the BL. This broke VCP which
is on endpoint 2 (control) and 3 (data).
This bug was introduced in 5ad37e69 which stopped checking the
transfer_possible variable.
BL images now always use hid-only.
FW images can use hid-only or hid+vcp but this is selected
ONLY at compile time based on whether PIOS_INCLUDE_USB_CDC
is defined.
CC uses HID+VCP by default now.
