Update to Photon-Fun

Posted 01/28/2018

In my last blog post on this topic from over a year ago, I walked through the setup of a development environment for the Photon MCU board (a board made by Particle, a company which is not associated with this author or site in any way. I really like their MCU boards though!). Recently, I decided that the AMD-64, with its tether (in the form of a 110V power plug), its twenty pounds, and its voracious appetite for power, was a poor development machine for an MCU board not much bigger than a couple postage stamps.

I had a spare Pi2 that wasn’t doing anything, so I imaged a uSD card with an image file from Devuan.org – one that they had built for the Pi2. It’s a minimal image, but contains most of what is needed for Photon development excepting for the gcc-arm-none-eabi cross compiler. That dependency was easily added via the apt-get utility. I used an environment setup procedure that pretty much mirrored the one I described a year ago (for the AMD-64). I got a copy of the latest stable release of the software from the Particle.io github, compiled it, and flashed my Photon (thus upgrading its firmware from 0.5.x to 0.6.x). After firing up the Photon with its new firmware and tcpserver app, I looked at the DHCP client listing shown on the WiFi router’s status page, and I noticed that the Photon was not sending a host name for the DHCP handshake, causing the router to auto-generate a crappy one.

Well, I like to see a real host name in my router. Call me picky. I went off to the Particle community forum to try and find a way to set the host name. I discovered that a feature was added about six months ago to the firmware, and that it would allow the WiFi DHCP related host name to be set in code in the user application. Hooray! The fix required a development version of the firmware, but I’m brave, so I downloaded a copy and tried to compile it on the Devuan Pi2 OS. An error message popped up, indicating that my compiler was too old (4.9 sys / 4.8 arm-none-eabi) versus the minimum version of gcc that was wanted (5.3).

It’s not a trivial thing to upgrade the compiler, nor to run an upgraded version in parallel, so I opted for another alternative solution. I switched to Raspbian Stretch by obtaining a new image and putting it on another uSD card. Booting it, I verified that its compiler was gcc and gcc-arm-none-eabi version 5.4 (for both).

It had been years since I’d updated my Raspbian uSD image, and so I was pleasantly surprised by the new look. My copy of the image file was dated 11-17-2017.

I updated the packages:

sudo apt-get update
sudo apt-get install gcc-arm-none-eabi
sudo apt-get install libarchive-zip-perl
sudo apt-get install dfu-util

Then, I got the latest development source for the Photon firmware:

git clone https://github.com/spark/firmware.git
cd ¬/firmware
git branch (shows develop, release, and master)
git checkout develop (at the moment, gives me 0.8.0-rc1)
cd ¬/firmware/modules
make clean all PARTICLE-DEVELOP=1 PLATFORM=photon APP=tcpserver program-dfu

Notice the last line contains the variable PARTICLE_DEVELOP. If this is not used, the build will halt, and display an onerous message about the dangers of using bleeding edge source. I inserted the variable on the command line, since I’m so brave. But, it should be known that there are risk associated with using bleeding edge development sources.

If you look at the github, you’ll see admonitions about installing the versions in steps. For instance, to go from 0.6.x to 0.8.x, it mentions that you should install the 0.7.x before the 0.8.x version. But, if you look closely at the words, and the shape of the outline, it’s apparent, at least to me, that they mean the extra updates should only happen when updating via Ymodem or OTA (over the air) techniques. I went directly from 0.6.x to 0.8.x but flashed the device using the DFU/USB cable method (i.e. I put “program-dfu” on the command line, and had a USB cable plugged directly into the device). I had no issues, but cannot vouch for how it’d work for anybody else, especially since it’s “bleeding edge” code, as was previously stated, which has risks always.

I put a code change into the tcpserver app, which basically added a single line:

WiFi.setHostname(“photon-ffrtos-mcu-sensor-server1”);

I recompiled, re-flashed, and restarted the board, and subquently the router’s listing dutifully displayed “photon-ffrtos-mcu-sensor-server” in the DHCP connected devices list. Hooray!

It should be noted that the following action theoretically should cause the building and the flashing of both system parts (part1, part2) and the specified user application:

cd ¬/firmware/modules
make clean all PARTICLE-DEVELOP=1 PLATFORM=photon APP=tcpserver program-dfu

The following action theoretically should cause the building and flashing of both system parts (part1, part2), but not the application:

cd ¬/firmware/modules
make clean all PARTICLE-DEVELOP=1 PLATFORM=photon program-dfu

The following action theoretically should cause the building of the app and all its wiring, and then the flashing of the application:

cd ¬/firmware/main
make clean all PARTICLE-DEVELOP=1 PLATFORM=photon APP=tcpserver program-dfu

AFAIK, the system is bootloader+syspart1+syspart2+wiring/application. The makefile in the ¬/firmware/modules directory builds the syspart1, syspart2, and optionally the wiring/application code depending upon the command line specified, i.e. whether or not the APP= variable is populated. The makefile in the ¬/firmware/main directory is concerned with the wiring/application build. So, typically, one would execute a make command line in the modules directory once, to build the system, or again at any time a new firmware version was built. The applications are built with the make file in the main directory, with or without wiring (depending upon whether the ALL target is specified, or a change detected).

The makefile in the ¬firmware/bootloader directory builds the bootloader, but the photon comes with a bootloader. Is it likely that it needs to be explicitly built and re-flashed every time? (I haven’t done it, and everything still seems to work OK)? If it needs to be rebuilt, the compiler command line would be similar to the one used to build modules, but without the application reference. I’m sure that at some point the bootloader will be changed to accommodate a new revision of the firmware, so ignore my statements about running 0.8 firmware on a 0.6 bootloader, be safe, and do whatever they tell you to do. Please don’t take anything on this page as advice. A new revision of the firmware may not work at all with a previous bootloader. Just now I built it (the bootloader for 0.8) – just for grins, and it seems to work, using:

cd ¬/firmware/bootloader
make clean all PARTICLE_DEVELOP=1 PLATFORM=photon program-dfu

Take all this with a grain of salt, because I’m not a Photon expert, and my topography view was constructed via a pretty speedy thumb-thru of the code. None of this is advice. I wanted to find a detailed diagram for all of this on the particle site, so that I could reference it, but haven’t found one so far. I get that the top-of-tree makefile is only a convenience for running the bootloader, modules, and main directory makefiles. So, I don’t use it, and I mainly work out of ¬/firmware/main (the app). Most people are using the GUI, which takes care of all of this I’m told.

So, the Raspbian Stretch image on a Pi2 works like a charm to do Photon development, IMO. It matches the form factor of the MCU board much better than the AMD-64. It’s another example of how I continually find more things to do with Pis and Odroids. I seemingly can’t have enough of them.

In the source retrieval process shown above, I could have looked at all of the available sources for checkout:

cd ¬/firmware
git branch -a (shows about 15-20 different versions of the firmware)
… I could have retrieved just the source I wanted thusly:
git clone -b v0.8.0-rc.1 –single-branch https://github.com/spark/firmware.git
… where the version was one of those found in the branch -a listing

The sample applications for the Photon are right in the firmware source tree, in the following directory:

¬firmware/user/applications

In the directory called applications is a separate subdirectory for each of several different sample applications.

I.E. tinker, serialbridge, etc. I created a tcpserver directory (¬/firmware/user/applications/tcpserver) – and in it added a tcpserver.cpp file with the code content of my app (it’s a pretty small one ATM). On the compile command line, when the variable APP=tcpserver is populated with the “app name” (as in the compile line shown midway up this page) – the named application will be compiled and flashed to the Photon.

Programming Miscellany

Programming, computer, and other tech pages of Ronald Scheckelhoff

Update to Photon-Fun

Share this: