jw3 / conan-particle Goto Github PK

Currently patches have to be copied in manually. They should be part of the conan package and cmake should be able to find and run them without the library user being involved.

Looks like the restructuring from the prototype to the conan packages was never tested.

• flash.mk doesnt have the app name configured, ends up with .dfu etc
• flash.mk ends up in wrong dir, should be in app dir but is in root build dir
• the configured flash script is nowhere to be found, should be in root build dir

Flashing still works if these problems are hacked around.

Move the clone from cmake to conan.

This is being copied around in every client project and should be moved up to commons

if (NOT CROSS_COMPILER_PREFIX)
    set(CROSS_COMPILER_PREFIX "/usr/local/gcc-arm")
endif ()

set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)

set(CMAKE_C_COMPILER "${CROSS_COMPILER_PREFIX}/bin/arm-none-eabi-gcc")
set(CMAKE_CXX_COMPILER "${CROSS_COMPILER_PREFIX}/bin/arm-none-eabi-g++")
set(CMAKE_ASM_COMPILER "${CROSS_COMPILER_PREFIX}/bin/arm-none-eabi-as")
set(CMAKE_AR "${CROSS_COMPILER_PREFIX}/bin/arm-none-eabi-ar" CACHE FILEPATH "Archiver")
set(CMAKE_RANLIB "${CROSS_COMPILER_PREFIX}/bin/arm-none-eabi-ranlib")

• xenon
• argon
• boron

spark_protocol_functions.h was included from communication/src and is breaking when compiling against 1.4.0 device-os

https://github.com/dwcares/debounce

tldr; The compilable target name should match the name passed to add_particle_remote_app.

In a non-trivial build the particle target may need to be called to add additional components to the build.

target_include_directories(firmware PRIVATE ${CMAKE_SOURCE_DIR}/something)

but firmware is not the compilable target, so you end up having to suffix it to firmware_remote.

Currently have to declare transitive dependencies for a remote app, eg

include(AssetTrackerRK)
add_particle_remote_app(app AssetTrackerRK LIS3DH)

Asset Tracker includes LIS3DH as a known dependency (in cmake module), but in in this example LIS3DH will not link if not explicitly passed to the add_particle_remote_app call.

Ideally transitive dependencies would be implicitly added to the remote app.

Using set(CMAKE_SYSTEM_NAME Generic) will prompt make to create .obj files instead of .o files. The particle firmware patch searches for .o. The end result is that you get a successfully compiled empty firmware.

Move the toolchain configuration into the conan package to avoid the need to figure this out.

• test publish local
• test build example project
• publish packages to bintray

If the device moves off of /dev/ttyACM0 the flash cannot succeed.

There appear to be Firmware and Product version concepts.

The firmware version is maintained in build/version.mk and does not need passed in.

VERSION_STRING = 1.0.1

# PRODUCT_FIRMWARE_VERSION reported by default
# FIXME: Unclear if this is used, PRODUCT_FIRMWARE_VERSION defaults to 65535 every release
VERSION = 1002

CFLAGS += -DSYSTEM_VERSION_STRING=$(VERSION_STRING)

As mentioned there the product version is a little ambiguous, though it is described in this discourse post.

Conclusion is that the firmware maintains its own version and the product version can be set in the application instead with the macro; eg. PRODUCT_VERSION(123);

Different projects that use source dirs named the same will collide.

For example two separate projects compiled for xenon with firmware under src will both write to build/target/user/platform-12-m/src.

Should prefix the dir with a project specific identifier.