Local building for Core+Photon

oh 80 column terminal - is it clipping the message so you don’t see all of it? I wonder if we can put some newlines in the message?

Any news for local building?

Even the simplest blink fails on Mac OS X. Providing an alternative to the cloud IDE is key.

local building does work, i’ve just built 0.4.6 as i was having trouble getting the cloud to work actually!

Building the framework goes fine, but not a basic project. The develop branch isn’t recommended, so I’ve tried with the latest branch, to no avail on Mac OS X.

Viable command line building is becoming critical as more disruptions are experienced on the cloud service.

have you got a log or error message, you can’t be helped by just saying “it doesn’t work” when it does for most of us. don’t tell me you’re using el-capitan?

When I say “it doesn’t work”, I mean 'it doesn’t work". Otherwise, I would have posted lengthy compilation traces, log errors and cryptic codes to decipher.

The code source is as minimal and stupid as the blinky example with the recommended firmware/latest branch. Building and linking complete fine, the resulting executable uploads successfully to the board but, as a result, the D7 LED doesn’t blink. So “it doesn’t work”. It performed the test various times following the same protocol.

The firmware/feature/HAL branch works fine for the Core, but not the new firmware/latest branch for the Core nor the Photon.

Yes, I’m using El Capitan. I’ve experienced no issues so far with other platforms when I use the GCC tool-chain and other SDKs like mbed, different flavours of Linux SDKs, RTOS, and different flavours of the Wiring/Arduino framework.

The “it just works” or plug-and-play or end-user experience includes the hardware, the software but also the documentation and the tutorials. My point was less technical but more user-oriented.

If “it just works” for you, lucky one! Feel free to share your experience, especially for the Custom makefile section. Thank you!

@rei_vilo could you share the command you’re using?

Here’s the way to ensure a clean build for the Photon, with modular firmware (Photon in DFU mode):

~code/firmware/modules $ make clean all -s PLATFORM=photon COMPILE_LTO=n APP=tinker program-dfu

And here’s how to compile a monolithic image if iterating locally:

/firmware/main $ make clean all -s PLATFORM=photon COMPILE_LTO=n APP=tinker program-dfu MODULAR=n

You can replace APP=tinker with a folder of your choice sitting along side of

firmware/user/applications/tinker/
1 Like

Here’s my blink.cpp which i have inside a blink directory somewhere in my $HOME

#include "application.h"

void setup()
{
    pinMode(D7, OUTPUT);
}

void loop()
{
    digitalWrite(D7, HIGH);
    delay(500);
    digitalWrite(D7, LOW);
    delay(500);
}

and here’s my custom Makefile, which is also inside the blink directory:

GCC_ARM_PATH = /stuff/sparkcore/gcc-arm-none-eabi/bin/
APPDIR       = $(realpath $(dir $(realpath $(lastword $(MAKEFILE_LIST)))))
APP          = $(notdir $(CURDIR))
TARGET_DIR   = $(CURDIR)/build-$(PLATFORM)
PLATFORM     = photon

all:

clean: local_clean

upload: all program-dfu

local_clean:
    rm -rf $(TARGET_DIR)

%:
    $(MAKE) -C /stuff/sparkcore/firmware/main APP=$(APP) PLATFORM=$(PLATFORM) APPDIR=$(APPDIR) GCC_ARM_PATH=$(GCC_ARM_PATH) TARGET_DIR=$(TARGET_DIR) v=1 $@

obviously the $(MAKE)…$@ should be all on one line, the forum has wrapped it.

i put the photon into dfu mode (hold setup+reset, let go of reset but keep holding setup until it blinks yellow. auto dfu mode doesn’t work on linux at least, you have to use the buttons) and call “make upload” and it works on my particle photon and spark core, i end up with a directory structure like:

blink/
├── blink.cpp
├── build-core/
├── build-photon/
└── Makefile

tested using gcc-arm-none-eabi-4_9-2015q2-20150609-linux.tar.bz2 and gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 with the “latest” branch

Thank you for the two answers.

Here the tests I've conducted so far.


Configuration

Tool-chain and SDK located at
/Users/ReiVilo/Library/embedXcode/gcc-arm-none-eabi-4_9-2015q2 /Users/ReiVilo/Library/embedXcode/Particle-new with firmware-latest branch

Projects are located at
/Users/ReiVilo/Desktop/particle-1 /Users/ReiVilo/Desktop/particle-2 /Users/ReiVilo/Desktop/particle-3


Test 1

The particle-1 folder contains
/Users/ReiVilo/Desktop/particle-1/LocalLibrary.cpp /Users/ReiVilo/Desktop/particle-1/LocalLibrary.h /Users/ReiVilo/Desktop/particle-1/main.cpp

Test 1a

  • Launch cd ~/Library/embedXcode/Particle-new/firmware/modules

  • Launch make v=1 GCC_ARM_PATH=/Users/ReiVilo/Library/embedXcode/gcc-arm-none-eabi-4_9-2015q2/bin/ COMPILE_LTO=n PLATFORM_ID=6 APPDIR=/Users/ReiVilo/Desktop/particle-1 TARGET_DIR=/Users/ReiVilo/Desktop/particle-1/Builds TARGET_FILE=embeddedcomputing clean all program-dfu > ~/Desktop/particle-1/1a.txt

  • Result: OK.

Test 1b

Change the number of blinks, e.g. blink(myLED, 1, 333); for blink(myLED, 2, 333);

  • Launch make v=1 GCC_ARM_PATH=/Users/ReiVilo/Library/embedXcode/gcc-arm-none-eabi-4_9-2015q2/bin/ COMPILE_LTO=n PLATFORM_ID=6 APPDIR=/Users/ReiVilo/Desktop/particle-1 TARGET_DIR=/Users/ReiVilo/Desktop/particle-1/Builds TARGET_FILE=embeddedcomputing program-dfu > ~/Desktop/particle-1/1b.txt

  • Result: NOK

Omitting clean all fails: old code is kept, new code not taken into account. The LED still blinks once, not twice.

Test 1c

  • Launch make v=1 GCC_ARM_PATH=/Users/ReiVilo/Library/embedXcode/gcc-arm-none-eabi-4_9-2015q2/bin/ COMPILE_LTO=n PLATFORM_ID=6 APPDIR=/Users/ReiVilo/Desktop/particle-1 TARGET_DIR=/Users/ReiVilo/Desktop/particle-1/Builds TARGET_FILE=embeddedcomputing clean all program-dfu > ~/Desktop/particle-1/1c.txt

  • Result: OK.

Question 1

Is clean all compulsory? Why to build the whole framework each time? Why to upload 3 packages each time, when only the latest one changes?
Downloading to address = 0x08020000, size = 249148 Downloading to address = 0x08060000, size = 169036 Downloading to address = 0x080a0000, size = 2272

Question 2

How to get rid of those messages?
fatal: Not a git repository (or any of the parent directories): .git

Question 3

What is the meaning of COMPILE_LTO=n, which is not documented at https://github.com/spark/firmware/blob/develop/docs/build.md?


Test 2

The particle-2 folder contains
/Users/ReiVilo/Desktop/particle-2/blink.ino /Users/ReiVilo/Desktop/particle-2/LocalLibrary.cpp /Users/ReiVilo/Desktop/particle-2/LocalLibrary.h /Users/ReiVilo/Desktop/particle-2/main.cpp

Test 2a

Sketch uses an .ino extension. main.cpp mentions #include "blink.ino"

  • Launch make v=1 GCC_ARM_PATH=/Users/ReiVilo/Library/embedXcode/gcc-arm-none-eabi-4_9-2015q2/bin/ COMPILE_LTO=n PLATFORM_ID=6 APPDIR=/Users/ReiVilo/Desktop/particle-2 TARGET_DIR=/Users/ReiVilo/Desktop/particle-2/Builds TARGET_FILE=embeddedcomputing clean all program-dfu > ~/Desktop/particle-2/2a.txt
  • Result: OK.

Question 1, Question 2, Question 3

Same as per Test 1.

Test 2b

Change the number of blinks, e.g. blink(myLED, 1, 333); for blink(myLED, 2, 333);

  • Launch make v=1 GCC_ARM_PATH=/Users/ReiVilo/Library/embedXcode/gcc-arm-none-eabi-4_9-2015q2/bin/ COMPILE_LTO=n PLATFORM_ID=6 APPDIR=/Users/ReiVilo/Desktop/particle-2 TARGET_DIR=/Users/ReiVilo/Desktop/particle-2/Builds TARGET_FILE=embeddedcomputing program-dfu > ~/Desktop/particle-2/2b.txt
  • Result: NOK.

Test 2c

Separating building and linking from uploading. Uploading done through USB or OTA.

  • Launch make v=1 GCC_ARM_PATH=/Users/ReiVilo/Library/embedXcode/gcc-arm-none-eabi-4_9-2015q2/bin/ COMPILE_LTO=n PLATFORM_ID=6 APPDIR=/Users/ReiVilo/Desktop/particle-2 TARGET_DIR=/Users/ReiVilo/Desktop/particle-2/Builds TARGET_FILE=embeddedcomputing clean all > ~/Desktop/particle-2/2c.txt

  • Launch particle flash ABCDEFGHIJKLMNOPQRSTUVWX /Users/ReiVilo/Desktop/particle-2/Builds/embeddedcomputing.bin

  • Result: Success rate = 60%.

Connection fails although the LED pulses cyan and the board is listed as online. Error message is

Flash device failed
[object Object]

  • Launch particle flash --usb /Users/ReiVilo/Desktop/particle-2/Builds/embeddedcomputing.bin
  • Result: OK.

Question 4

How to upload the program OTA with success rate = 100%?


Test 3

The particle-3 folder contains
/Users/ReiVilo/Desktop/particle-3/blink.ino /Users/ReiVilo/Desktop/particle-3/LocalLibrary.cpp /Users/ReiVilo/Desktop/particle-3/LocalLibrary.h /Users/ReiVilo/Desktop/particle-3/main.cpp /Users/ReiVilo/Desktop/particle-3/Particle_fast.mk

Particle_fast.mk include a variable definition MY_IDE, which is tested on main.cpp and blink.ino
CPPFLAGS += -DMY_IDE=310 CFLAGS += -DMY_IDE=310

  • Launch make v=1 GCC_ARM_PATH=/Users/ReiVilo/Library/embedXcode/gcc-arm-none-eabi-4_9-2015q2/bin/ COMPILE_LTO=n PLATFORM_ID=6 APPDIR=/Users/ReiVilo/Desktop/particle-3 TARGET_DIR=/Users/ReiVilo/Desktop/particle-3/Builds TARGET_FILE=embeddedcomputing USER_MAKEFILE=Particle_fast.mk clean all program-dfu > ~/Desktop/particle-3/3a.txt
  • Result: NOK.

Question 5

How to specify variables in the makefile?

Thank you!

One more question: Why are you using /stuff/sparkcore/firmware/main while the recommended folder is /stuff/sparkcore/firmware/modules?

Thank you!

For Question 5, see specific thread Local Build: How to Specify Variables in the Makefile?.

@BDub does the monolithic build work on the latest branch?

@BDub

No answer to my comprehensive post?

Thank you for bringing this issues. I tried all the failed test cases against release 0.4.6 (Oct 2 2015) and all the tests passed. Could it be you were using an older release?

The make target given is just program-dfu - which flashes latest built code to the device. To build the code first and flash it to the device you need all program-dfu as a target, as documented at https://github.com/spark/firmware/blob/develop/docs/build.md#targets

  • all: the default target - builds the artefact for the project
  • clean: deletes all artefacts so the next build runs from a clean state
  • all program-dfu: (not bootloader) - builds and flashes the executable to a device via dfu
  • all st-flash: flashes the executable to a device via the st-link st-flash utility

A clean build isn't necessary each time, only when switching branches.

Q2

How to get rid of those messages?
fatal: Not a git repository (or any of the parent directories): .git

I don't see these messages. What make command do you run that produces this?

Q3

COMPILE_LTO is an internal flag that the build system sets itself for different platforms. You do not need to provide this flag.

Test 2b, same cause as 1b - missing all target. :wink:

Test 2c, Q4 - this issue has been resolved in the meantime.

Test 3, Q5: This worked for me, in a test application I had

#if MY_IDE!=310
#error variable not defined as 310
#endif

I got the test to fail by excluding the user makefile (since the variable wasn't defined) and the tests passed when the makefile was used.

Please retry these tests with the latest branch or develop. They should work for you, but if not we can investigate further.

Thank you for your answer.

Unfortunately, the initial tests were performed and reported three months ago, in Oct '15, so I’m not sure I’ve kept the protocol.

In the meantime, almost everything has changed: new release of Mac OS X, new release of Xcode and thus make and obviously new release of the tools for Core and Photon local build.

I’ve found another solution with the MediaTek LinkIt One, which brings WiFi, Bluetooth + BLE, GSM + GPRS, GPS in one single board, plus full Wiring / Arduino implementation and compatibility.

Sorry.

The RedBear Duo board leverages Particle for the IoT infrastructure, and manages to compile with Arduino. Incidentally, this makes the board supported by embedXcode.

When does Particle plan to release the same feature for the Core and Photon?

2 Likes

Any update on this major feature?

Github All Releases Slack Status Donate Bitcoin GitHub issues GitHub stars Build Status Circle CI

Hi. @sej7278

I have recently been developing a script for installing and using the Particle Toolchain on Ubuntu-based Distros and OSX. I have done lots of testing and it is now very stable. Read more at po-util.com, or download it instantly with:

curl -fsSL bit.ly/po-util13 | bash

2 Likes

I had the opportunity to test the offline Particle Workbench for this Remote e-Paper Messages Panel project and I really liked it. It leverages the features of Visual Studio Code and offers cloud and local build. This is what I had in mind for an offline IDE many years ago…

2 Likes