Experiencing various issues

@jrubins: I’ll raise a glass of whiskey to your scotch!

I too have not been without my fair share of issues with the Photon. I’ve been hacking with my trusty ol’ Spark Cores while I wait for the motivation to start troubleshooting my Photon.

I’m not as microcontrollery-technical as many of the other elites, but maybe I can offer some help!

  • Piette DHT library vs Adafruit DHT library: I think this all comes down to timing and blocking code. In particular, the Photon and Core need to sync up with the cloud every now and then (something like every 15 to 20 seconds). If they can’t or things are blocked and delayed too much, the device isn’t going to be happy. Also, when the device does its cloud check-in, it can cause delays in other timing-sensitive code. Those two reasons are at least part of the problem why the Adafruit library didn’t work out well in the first place.
  • Difficulties with local Particle Dev IDE: One suggestion I can offer (if you haven’t already tried it yourself), is to make sure all of your project is contained within a directory (and not just an .ino file on your desktop or something). Try to clean out any cruft that’s not directly related to compiling and/or put it in a particle.ignore file.
  • Web IDE Difficulties: I’ve grown a little frustrated with the response times and switched to another IDE (Cloud9 – I did a write-up about it in another thread). I think the problem there is it just hasn’t scaled well and hasn’t had the attention that it needed. A lot of things have changed since the web IDE was scoped and launched, and it’s a complicated system to update. I heard within the physical confines of Particle HQ (note that I live some 2,500 miles away) that the web IDE is on the radar, but I don’t know the priority off the top of my head.

If you can, give the Particle CLI another shake with a different editor (such as Sublime that you mentioned). Since you’re on a Mac, try out some of the shell scripts from my Cloud9 thread mentioned earlier. Hopefully that will take some of the IDE edge off. Also, I am living proof that you can compile a sketch with no errors or warnings and lock up a Core/Photon. Infinite loops and buffer overflows are tough for compilers to catch! :wink:

The firmware update for the Photon that someone mentioned above is supposed to address some bugs that I think are giving me grief with my Photon. I’ve shelved my Photon until that update hits production. Then I’ll start threatening my Photon with a hammer if I still have issues out of it.

As unbiased as I’ve tried to make this post, I do want to “defend” the Particle team. They are a truly exceptional group of people. They are a passionate, smart, and dedicated team, all of which left me feeling like I made a whole new group of BFFs in just a few days. Feedback like yours is taken very seriously, and it is a matter of personal pride for everyone to get it resolved as quickly as possible. The Photon is still a very new product with some pretty drastic changes from the original Spark Core, so there are bugs that are cropping up that never reared their ugly heads in development. Being a 20-year veteran of software development, I now this feeling all too well. We (speaking for all developers) just need to “own” our mistakes, acknowledge them, and fix them in a reasonable manner. There are always other forces at play like the bigger picture and business priorities that will get in the way.

I appreciate reading this polite feedback, even if it took some “discourse” to drill down to some of the issues. If some of the suggestions in this post or the posts prior don’t fix your issues, keep an eye out for that new firmware release. If that doesn’t improve things, hit @christine up for that refund. My personal belief is that it will work itself out in the next few weeks, and you may be glad you held on!

4 Likes

Wow @jrubins, that thread grew a bit :wink:
Sorry for not getting back earlier, but my points were addressed already, so I’d like do what @Christine mentioned what Elites like to do most - help solve problems and give tips how to get round things.

Although it might not help directly, some things to try, if you still can be bothered:

  • If you don’t need cloud support, try SYSTEM_MODE(MANUAL)
  • For your buttons (it is frustrating when they don’t respond) try using interrupts for them
  • Power/voltage might be an issue, try beefier power supply and maybe level shifters where needed.

Another person noted the issues with the I2C library for LiquidCrystal on my repo, It is likely an issue related to only the Photon. I haven't received my Photons yet (thought they are in the mail) so I will be able to look at that sometime later this week, I am hoping.

as a side note... I too, having a pretty comfortable background in Arduino, expected that the Particle platform to would be more "Arduino-like" that\n it is. After spending about 10 months working with it, I can say that I'd rather have all of the built-in awesomeness of a Particle (and I've learned a lot too). At this point (and Particle team please take this the right way) I just cannot get my hands on enough of them to do all of the new projects I want to do!!! So please stick with it... the community is great and can help you.

2 Likes

Wow, thanks all of you for the considered responses, @christine, @wgbartley, @ScruffR, @BulldogLowell

I appreciate that you are taking these issues seriously.
If I can provide overall feedback to the Particle team:
This is a great product, but it seems to be hamstrung by its differences with the Arduino platform. If you want to see the Particle platform grow to the size of the arduino platform, piggyback on what they’ve done as much as you possibly can. Make it so that porting libs is easy and 100% compatible. Make it so I can copy/paste code. If the Photon is “an arduino with wifi and extra features for 1/2 the price” then you will have a real giant killer on your hands. Even if it were the same price or more expensive it would be able to get a huge DIY following. The advantage of the lower price is a realistic path from prototype to production with a single device.

Second, if the Web IDE is not the best way to do things, then tell me (in the docs) the best way to get firmware to the Photon. I’m happy as a pig to upload firmware via a usb cable, wifi flashing is a “gravy” feature IMHO, but it seems to be the focus of all the documentation. I’ll definitely spend some time investigating the other approaches like cloud9. Because the web IDE is the focal point of the documentation, I assume that it’s the best way to get ones and zeros from laptop to Photon. If it’s not, I’m all ears.

Third, I’m sure that the Particle Dev team are awesome people. They made a great product, and I want to see it succeed. It seemed that some folks on the forum were not particularly concerned with being helpful or even contributing meaningfully to the conversation (gripe-fest). It seems that those posts have vanished now, though… maybe it was all a dream :wink:

3 Likes

okay, specific issues now:
I got the CLI installed this morning. Particle Dev still won’t flash via the cloud :frowning:
I can flash via the CLI, which is great, and I’ve got sublime talking to the photon via sublimeREPL
Next step, take @mumblepins port of the adafruit library and add a few delays to the wire.somethingorother calls.
Any advice on including libraries when flashing from the CLI? Does the lib file just go into the same file as the code?

Thanks again,
JR

1 Like

For your error in the screenshot (in post #22) try to add this in your LiquidCrystal_I2C_Spark.h (and maybe .cpp)

#ifdef PLATFORM_ID
#include "i2c_hal.h"
#endif

As for your other question

I usually do it that way and put all the required library files in just one flat folder alongside my main program .ino (I use INO rather than CPP to quickly find the main program ;-)).
The thing you may have to watch then is, that examples from Particle Build (Web IDE) do have their includes like #include "LibraryName/LibraryName.h" and this would need to be changed into #include "LibraryName.h".
Not nice, but also on the ToDos.


A forum search for CLOCK_SPEED_ came up with some topics regarding this issue.
It is a temporary problem, till fw v0.4.2 hits the cloud build world, which should have happened earlier, but due to unexpected circumstances got pushed and pushed back.

As tricky it sometimes is, to find the best search term to give you the desired results, it often proves worth to spend a few extra minutes to search to save you a lot of frustration.

(Un)Fortunately the Photon has arrived in some peoples hands quicker than expected (while others are still waiting eagerly - we feel with them :weary:), while the firmware was not entirely in its "ready-for-everybody" state.
But behind the scenes ingenious people (like Mat McGowan) are working their heads off to iron things out.

2 Likes

Here's a screenshot of how I organize my project directories:

I use the online IDE (build.particle.io) to browse for the library I want, click on the GitHub link, and clone the repository into my project directory. The Particle CLI uploads all of these files as a "flat" directory, so you'll reference them in your main sketch "flatly" (#include "neopixel.h").

To flash, I use deploy.sh (pasted below) which includes all the requisite files that I usually want, minus stuff in any examples directories. I save the target device ID in a file named device_id. That way I can use cat device_id and only have to change the device ID in one place instead of updating each script in a project directory.

Like @ScruffR, I use the .ino file extension to help my main sketch to stand out a little. :wink:

#!/bin/bash

DEVICE_ID=$(cat device_id)
particle flash $DEVICE_ID `find . -type f -iname *.ino -or -iname *.h -or -iname *.c* -not -iname *.csv -not -ipath */examples/*`
2 Likes