This is the first cleanup pass through makefiles and pios.
Probably it is difficult to track changes due to the nature of them.
I would recommend to look at resulting files and compiled code instead.
NOTE: original branch was rebased and lot of conflicts were fixed on
the way. So do not expect that every commit in this series will be
buildable (unlike original branch). Only final result was tested.
The main goal was to remove as much duplication of code (and copy/paste
errors) as possible, moving common parts out of Makefiles. It still is
not perfect, and mostly no code changes made - Makefiles and #ifdefs only.
But please while testing make sure that all code works as before, and no
modules/options are missed by accident.
Brief list of changes:
- Moved common parts of Makefiles into the set of *.mk files.
- Changed method of passing common vars from top Makefile to lower ones.
- Some pios cleanup, mostly #ifdefs, and all pios_config.h files.
- Many obsolete files removed (for instance, AHRS files, op_config.h).
- Many obsolete or unused macros removed or fixed/renamed (ALL_DIGNOSTICS).
- Unified pios_config.h template. Please don't remove lines for board
configs, only comment/uncomment them. Adding new PIOS options, please
propagate them to all board files keeping the same order.
- Some formatting, spacing, indentation (no line endings change yet).
- Some cosmetic fixes (no more C:\X\Y\filename.c printings on Windows).
- Added some library.mk files to move libs into AR achives later.
- EntireFlash target now uses cross-platform python script to generate bin
files. So it works on all supported platforms: Linux, OSX, Windows.
- Top level packaging is completely rewritten. Now it is a part of top
Makefile. As such, all dependencies are checked and accounted, no
more 'make -j' problems should occur.
- Default GCS_BUILD_CONF is release now, may be changed if necessary
using 'make GCS_BUILD_CONF=debug gcs'.
- GCS build paths are separated into debug and release, so no more obj
file clashes. Packaging system supports only release builds.
- New target is introduced: 'clean_package'. Now 'make package' does not
clean build directory. Use clean_package instead for distributable builds.
- Targets like 'all', 'opfw_resource', etc now will print extra contex
in parallel builds too.
- If any of 'package', 'clean_package', 'opfw_resource' targets are given
on command line, GCS build will depend on the resource, so all fw_*.opfw
targets will be built and embedded into GCS. By default GCS does not
depend on resource, and will be built w/o firmware (unless the resource
files already exist and the Qt resource file is generated).
- fw_simposix (ELF executable) is now packaged for linux. Run'n'play!
- Make help is refined and is now up to date.
Still broken:
- UnitTests, should be fixed
- SimPosix: buildable, but should be reworked.
Next planned passes to do:
- toolchain bootstrapping and packaging (including windows - WIP)
- CMSIS/StdPeriph lib cleanup
- more PIOS cleanup
- move libs into AR archives to save build time
- sim targets refactir and cleanup
- move android-related directories under <top>/android
- unit test targets fix
- source code line ending changes (there are many different, were not changed)
- coding style
Merging this, please use --no-ff git option to make it the real commit point
Conflicts:
A lot of... :-)
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.
