Playing with a Photon (3)

phot-with-bat1Continued from page two …

This device, so far, seems to be the compromise solution I was looking for, to handle the sensor end of things, with more power and less cost than other options I’d looked at, but without the (relatively speaking) overkill (and poor battery life) of a CPU/WiFi SoC.  The latter processor is well suited as the aggregation and control node.

It’s true the Arduino eco-system contains a huge repository of libraries and projects to jump start many other projects, but the Particle.io eco-system is growing fast.  And, thus far I have found the built-in firmware and libraries that are available for the Photon to be well documented and easy to use.

It’s a simple thing to use convenient supplied objects for such things as I2C communications, SPI communications, serial communications, WiFi communications, etc.  The Photon is a communicator.

sensornet7Figure 2:  setup for long battery life on the “collector subnet” nodes

Here are some typical built-in objects, and random examples of facets of their usage:

For SPI:

  • SPI.begin(SPI_MODE_MASTER, A2);

Or, for the second SPI bus:

  • SPI1.begin(SPI_MODE_MASTER, D5);

Or, for I2C:

  • Wire.beginTransmission(DEVICE4);

Or, for WiFi:

  • int intReceiveStrength = WiFi.RSSI();

More WiFi:

  • WiFi.setCredentials(SSID, PASSWORD, WPA2, WLAN_CIPHER_AES);

.

Here are some additional, random observations about the Photon:

On Devuan Linux, the Atom Particle environment would not run without the crc32 utility, which does not exists on the system by default.  One needs to install libarchive-zip-perl_1.30-7_all.deb to get this utility.  Now that IS random, since I’m not really going that route at all.

Many Arduino apps are fairly portable to the Photon, but sometimes there’s an issue due to int being 16 bits on the Arduino, and 32 bits on the Photon.

In “safe mode” – blinking magenta – the board loads the system firmware and WiFi may work (depending on configuration), but the user program is not executed.

If the board is “breathing” white, then the WiFi module has been turned off.

Cyan and red, blinking alternatively supposely means bad public keys (cloud related stuff).  I have not verified this at all.

A red S.O.S blinking LED means an error has occured.  Here’s the list:

Blink seq: short,short,short,long,long,long,short,short,short (SOS)

PLUS:

  • 1 blink:   Hardware fault
  • 2 blinks: Non-maskable interrupt fault
  • 3 blinks: Memory manager fault
  • 4 blinks: Bus fault
  • 5 blinks: Usage fault
  • 6 blinks: Invalid length
  • 7 blinks: Exit
  • 8 blinks: Out of heap memory
  • 9 blinks: SPI overrun
  • 10 blinks: Assertion failure
  • 11 blinks: Invalid case
  • 12 blinks: Pure virtual call
  • 13 blinks: Stack Overflow

Red blinking without the SOS is as follows (IIRC):

  • 2 blinks: could not reach internet
  • 3 blinks: could reach internet, but not cloud.

Generally, the Photon should be considered a 3.3 VDC device. So, level shifters should be used when connecting to other systems that do no use 3.3 VDC.  The device has some 5 VDC tolerant pins, but the word “some” always bothers me in those situations. The board has a 3.3 volt regulator, which gets its power from USB or from Vin (5V).

Additional random development info:

Photon comes preloaded with the tinker app, which (AFAIK) couldn’t be used in the way I wanted to use it. It is oriented towards the cloud, and the use of Android or IOS systems as clients. Therefore, I built and loaded a new “tcpserver” program into the Photon.  To create the tcpserver app, I created the directory:

  ~/github/firmware/user/applications/tcpserver

Then, I put the code (source described below) into the file:

 ~/github/firmware/user/applications/tcpserver/tcpserverSimple.cpp

I changed the directory to be the modules directory, and ran make:

  • cd ~/github/firmware/modules
    make clean all PLATFORM=photon APP=tcpserver program-dfu

This builds all the system firmware, and potentially other modules (such as the user program), and then downloads them to the board.  Subsequently, when it is desired to build only the user application by itself, and download only it to the board, I change to the main directory, and run make:

  • cd ~/github/firmware/main
  • make clean PLATFORM=photon APP=tcpserver program-dfu

This seems to do the trick, and downloads only the user app to the board. I have cycled this procedure a few times, and it seems to do what I’m saying, but I may have more to say about it as time progresses.

The last step puts the “user app” firmware into:

~/github/firmware/build/target/user-part/platform-6-m/tcpserver.bin

The system firmware is in two parts, and after building is in:

~github/firmware/build/target/system-part1/platform-6-m/system-part1.bin

~github/firmware/build/target/system-part2/platform-6-m/system-part2.bin

The memory map of the Photon is:

  • 802-806:  system part 1
  • 806-80A: system part 2
  • 80A-80C: user application
  • 80C-80E: Over the Air firmware backup
  • 80E-810: Factory backup

So, one could just use the dfu-util program, and point it to the proper target directories and board addresses, and “flash” the board manually.  In fact, that’s what the build system is doing with the “program-dfu” option.  It’s a lot nicer to let the build system flash the board.

The manual way for flashing the user app would be something like:

  • dfu-util -d 2b04:d006 -a0 -i0 -s 0x80A0000:leave -D /home/ron/github/firmware/build/target/user-part/platform-6-m/tcpserver.bin

where -d 2b04:d006 is derived from :

  • dfu-util -l

Other dev notes:

The Photon has a nifty vBATT pin, which supposely can be used to save data in a 4k page even when the device is in deep sleep mode.  Normally, deep sleep wipes out the variables, so is close to a reset (execept that it doesn’t reset).  Using the 4k space to maintain state is an idea I can appreciate, since I’ll be using deep-sleep widely.  I’ve yet to code this stuff, so will return when I have for an update.  If a coin cell (3V) is put on vBATT, then this feature may be used.  It has to be explicitly allowed in user code, with something like:

STARTUP(System.enableFeature(FEATURE_RETAINED_MEMORY);

When used this way, variables are declared like this:

retained int value = 10;

Like I said, I’ll report on this as time progresses …

Threads are usable, but I’ve not seen any mutexes yet.  In the meantime, one can use the “critical section” statement to keep threads in order.

The tcpserver app I used (after a little modification), was pulled from a contributor snippet on Particle.io.  There are lots of little snippets on the site, and in connected githubs.  Many are geared to cloud connections, but are usually easy-peasy to port to a local-net-only sort of setup, which I have here.

Read More …

Note: the author does not have a recent, applicable background in circuit building, or battery related issues, so this is presented as the work of a hobbyist, and is not meant for duplication by others. Readers should look elsewhere for design advice and info.

Note: the Photon referenced in this post is manufactured by the folks at particle.io, and this site and author are not related to them in any way. PHOTON is a trademark of Particle Industries, Inc.

The Arduino is manufactured by the people at Arduino.org, and they are not affiliated with this site or author in any way.

 

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s