Local building for Core+Photon

Firmware
1

Hi, I’ve been out of the Spark world for a while (messing with crappy ESP8266 sorry!) and am looking to get my hands on a Photon or two.

Sooooo. How to we build for a Photon, as obviously they’re different CPU and wifi chips for a start. Is it handled in the makefiles automatically, or do we have to pass in some arguments?

I’m not concerned with cloud IDE/spark-cli builds.

P.S. did you ever get static IP working (not static dynamic)?

2

Here’s how it works with the implementation of HAL

  • make PLATFORM=photon APP=app_name

This will give you a binary built for Photon

  • make PLATFORM=core APP=app_name

this will give you a binary build for core

You can see the command available here: https://github.com/spark/firmware/blob/feature/hal/build/readme.md

We should have something really exciting to announce that will make it super simple for people using linux/mac/windows to compile their binary locally. Stay tuned! :wink:

I also see that the network stack has some flags to set the static ip but i might be wrong.

@mdma should know this best :wink:

4 Likes
3

thanks @kennethlimcp

none of these flags that are dotted around the documentation seem to make any difference, they all build for the core:

PLATFORM_ID=0/1
PLATFORM=photon
SPARK_PRODUCT_ID=1/2/3
SPARK_NO_PLATFORM=y

i don’t think the makefile setup needs to get any simpler, jees you download arm-none-eabi and dfu-util and type “make”, the new HAL branch means you only have one repo to download too.

p.s. i don’t like make v=1, can’t we use something normal like -v or --verbose ?

4

The photon build is not available publicly yet - we will be releasing that next week.

5

Sure, if you find out how to make that work, please submit a PR!

6

well i’d get rid of firmware/build/verbose.mk which then defaults us to verbose output. for the very few people who don’t want to see any progress, they can run “make -s” which gives you:

$ make -s
Building firmware for Spark core, platform ID: 0
   text       data        bss        dec        hex    filename
  12932        632       3560      17124       42e4    ../build/target/bootloader/platform-0/bootloader.elf
   text       data        bss        dec        hex    filename
  79708       1144      11620      92472      16938    ../build/target/main/platform-0/main.elf
7

What happens when you do a clean build? I think you’re only seeing the final output since there’s no much for make to do.

8

that is a clean build

$ make -s clean APP=bmp085_cloud
Building firmware for Spark core, platform ID: 0
$ make -s APP=bmp085_cloud
Building firmware for Spark core, platform ID: 0
   text       data        bss        dec        hex    filename
  12932        632       3560      17124       42e4    ../build/target/bootloader/platform-0/bootloader.elf
   text       data        bss        dec        hex    filename
  86084       1168      11632      98884      18244    ../build/target/main/platform-0/applications/bmp085_cloud/bmp085_cloud.elf
9

cool! And without -s, what do you get? (again with clean all)

10
11

Cool that make is outputting the commands, but there are many echo messages that aren’t appearing.

12

ah is ECHO=echo only defined in verbose.mk ?

what echo’s are missing?

even with make v=1 i’m not seeing lines like:

$(call,echo,'Invoking: ARM GNU Create Flash Image')

so maybe its busted to start with?

this one has verbose.mk just consisting of ECHO=echo, doesn’t seem any better:

13

i’m trying to figure out how libraries are handled on a local build these days.

i thought we could put them in firmware/main/libraries or firmware/main/inc but that only seems to work for header files not c++ files (e.g. the bmp085 library has .cpp and .h files) and it also seems to be compiling every library instead of just the ones #include’d in the cpp source - actually it seems to be building every application - maybe the whole thing is broken - doesn’t seem to be building according to travis-ci either?

surely we don’t have to split .cpp files into src/ and .h files into inc/ ?

i’m sure we had this working months ago…?

i’ve tried the develop branch as well as master and they both seem to have the same problem, which branch should we be using these days?

am i right in that we no longer need core-common-lib or core-communications-lib, just firmware (not core-firmware) ?

14

The travis-ci build is failing because the core is deactivated. I should remove the integration tests so the build works.

Local libraries with CPP files are not supported at present. The simplest way at present is to copy them to a subdirectory of your application.

15

ok thanks for the library info, i got it working as a subdirectory but thought we’d already fixed that - as surely the ide servers only use one copy of a library - or do they copy them for each script?

16

to support libraries locally, at a minimum need some metadata so the compiler knows which libraries to build and link. I’d really like to see this happen soon!

17

well we’d need some info on what that metadata is - i assume that’s linked to the build server setup which we have no visibility of?

the problem at the moment i guess is the recursive search for build.mk files - you can’t use a makefile to append the libraries to $CPPSRC as then every one will get built, and inc/ is only being appended to to the include path (for headers).

18

Another workaround is to include your own build.mk file in the application sources, and amend CPPSRC and INCLUDES_DIR to include the libraries you want to build.

Even doing this doesn’t quite get us there since the library format has a “firmware” directory, which contains all the sources and headers. Yet, the include directive is include “lib/lib.h” - no mention of “firmware”. There is some magic happening in the online IDE, which the local built would have to emulate, via copying or symlinks to fix up the namespace.

19

yes i’ve been using my own build.mk, but as i have one for every app, they all get included!

for now, putting libraries in a subdirectory of the app is fine (for me)

1 Like
20

I'm seeing things like

Invoking: ARM GCC CPP Compiler

appearing.

Probably best you checkout a clean working copy and try again. I didn't use the -s switch because I couldn't make it work - if make had set a variable indicating silent mode then I could have used that, but I didn't find any such variable.

But if I'm perfectly honest, it seems a bit petty to spend time worrying about whether we pass v=1 or -s to change verbosity - surely the syntax is moot so long as it's reasonably compact and works?

1 Like