Porting code from other Arduino type platforms to Photon - experience

We have just finished porting our (single source) firmware from a range of other ‘Arduino’ type platforms to the Photon, having received it yesterday & thought it would be useful sharing some of our experiences for other ‘newbies’.

Essentially, our firmware uses D2 & D3 to read input from a pair of Infrared receivers to record signals and sends the data to our PC based AnalysIR (Infrared decoder and Analyzer) over serial @ 115,200 bps. We have been wanting to try out the Photon since it was announced last year, for $19+shipping.

The good news is that we have finally got it going after a few ‘road-blocks’ (self-inflicted) and it now seems to perform on a par with the other other systems we support. At this time we are only using the cloud to update firmware. Later, we will look at adding in a TCP/IP direct connection over LAN/WiFi, to replace the serial connection.

Hopefully some of this post will help others similarly starting out with the Photon.

OTA Flashing
This one resulted in the biggest ‘sink’ of our time. In our ‘loop()’ we always wrapped the actual code inside a while(true) loop to get the best performance, as Arduino does some extra processing at the end of each loop, which we don’t need. I suspect a similar approach on Photon meant that the OTA firmware requests were not being serviced (I presume this happens at the end of each loop by default [?]). As our first workaround, we placed a Spark.process() call every time thru the loop & although this allowed OTA firmware updates to work, we then started missing interrupts (maybe 25%+). The final solution came by doing 20 Spark.process() calls during the first 20 seconds in Setup and then issuing a Spark.disconnect (to turn off the cloud connection), which was enough time to allow an OTA update after reset. There may be more elegant solutions, but this approach is sufficient to meet our needs for now.

Interrupts
Currently, interrupts are not working on some pins on the Photon, but we are OK as we just need 2 – on pins D2 & D3. Our initial mistake here was using 0 & 1 (a la Arduino INT0 & INT1) as the interrupt pins. Once we got some assurance on the forum that interrupts were indeed working, we quickly figured out our mistake and used D2 & D3 as the pins in the attachInterrupt call. A search on the forum will show which pins can be used at present & the plans for a fix for the other pins. The interrupts in our configuration can fire as often as every 17 uSecs when an IR signal is being received and we noticed that when the cloud was connected, the timings recorded were off a bit, occasionally. Now that we disconnect the cloud after the OTA ‘window’ during setup – the timings recorded are ‘spot on’ every time.

General Code & Getting Started
Clearly the Photon is a very different from a standard Arduino or Teensy etc. etc. However, our code ported well to the Photon environment with minimal changes. Most of the issues we encountered were related to OTA & Cloud connections, which is to be expected. I guess a dose of RTFM will always help. There sure seems to be a lot of info available.

Conclusion
The next step is to get a few of our users to test it all out using their Photon and then later to get a direct network connection going to replace the current serial connection… All in all, we managed to port our code with only a few extra lines of code (for OTA & cloud disconnect) & no material changes to our core Arduino code – nice.

7 Likes

In the meantime we have found some other things to look out for…

Update:

  • Varialble sizes (# of bits) can be larger on the Photon, which can intefere with some bit oriented manipulations.
  • Previous vesions of the System Firmware micros() didn’t wrap around to zero on the Photon. In the latest system Firmware this behaviour is now consistent with Arduino.
  • Initially, we had lots of issues with TCP Server/client (likely related to issues with the above), but is seems to operate reliably now.