Code not stable

Firmware
1

Hello, running into a spot of trouble trying to get my core up and running. I get periodic panics and resetting every few minutes. I can’t be running out of heap could I? Also is there any way anyone knows how to check memory used in the Particle Dev app?

Thanks

#include "Adafruit_LEDBackpack.h"
#include "Adafruit_GFX.h"
#include "Tinker.h"
#include "Adafruit_DHT.h"

#define DHTTYPE  DHT22 // DHT11 DHT21 DHT22(AM2302) | dht.getHumidity()  dht.getTempCelcius() dht.getTempFarenheit()
#define DHTPIN   D5    // Signal Pin                | dht.getHeatIndex() dht.getDewPoint()    dht.getTempKelvin()
DHT dht(DHTPIN, DHTTYPE);
Adafruit_7segment matrix = Adafruit_7segment();
int LED6 = D6;
int LED7 = D7;
char cData[120];
char cDHTf[5];
char cDHTh[5];
char cTime[5];
String upSince;

void setup() {
  pinMode(LED6, OUTPUT);
  pinMode(LED7, OUTPUT);
  Time.zone(-6);                        // MDT
  upSince = Time.timeStr().c_str();
	dht.begin();
  matrix.begin(0x70);
  matrix.print(10000,DEC);              // make display show ----
  matrix.writeDisplay();
  Spark.function("digitalread", tinkerDigitalRead);
  Spark.function("digitalwrite", tinkerDigitalWrite);
  Spark.function("analogread", tinkerAnalogRead);
  Spark.function("analogwrite", tinkerAnalogWrite);
  Spark.variable("DHTf", &cDHTf, STRING);
  Spark.variable("DHTh", &cDHTh, STRING);
  Spark.variable("data", &cData, STRING);
  Spark.variable("time", &cTime, STRING);
  RGB.brightness(64);
}

void loop() {
  double DHTh = dht.getHumidity();
  double DHTf = dht.getTempFarenheit();
  int hour = Time.hour();
  int min  = Time.minute();
  matrix.writeDigitNum(0, hour/10);
  matrix.writeDigitNum(1, hour%10);
  matrix.writeDigitNum(3, min/10);
  matrix.writeDigitNum(4, min%10);
  matrix.writeDisplay();
  sprintf(cData, "core_01 SN: %i Up: %s | Temp %.0f'F Humd %.0f%%",WiFi.RSSI(),upSince.c_str(),DHTf,DHTh);
  sprintf(cDHTf, "%.0f", DHTf);
  sprintf(cDHTh, "%.0f", DHTh);
  sprintf(cTime, "%i:%i", hour, min);
  Spark.publish("DHTf", cDHTf);
  Spark.publish("DHTh", cDHTh);
  Spark.publish("Time", cTime);
  Spark.publish("Up", upSince.c_str());
}
2

You are publishing too fast and the :cloud: probably rate limited them

1 Like
3

As per the docs:

NOTE: Currently, a device can publish at rate of about 1 event/sec, with bursts of up to 4 allowed in 1 second. Back to back burst of 4 messages will take 4 seconds to recover.

1 Like
4

Great - thanks very much - took out all define and publish statements and will see how it goes.

5

So I pulled every broadcast variable out - including
Spark.publish
Spark.variable
Spark.function

And am enjoying what looks to be perfect stability now.

I have another core running a LED string and measuring air pressure with a BMP180 chip. This program throws off:

Spark.variable("up", &up, STRING);
constructed with:  sprintf(up, "SN: %i Up Since: %s Pres=%.2f hPa", WiFi.RSSI(), upSince.c_str(), bmp_presHG);

and I see this::

{
"cmd": "VarReturn",
"name": "up",
"result": "SN: -58 Up Since: Sat May 30 07:57:51 2015 Pres=24.67 hPa",
"coreInfo": {
"last_app": "",
"last_heard": "2015-05-31T14:35:33.627Z",
"connected": true,
"last_handshake_at": "2015-05-31T13:11:59.333Z",
"deviceID": "54ff700666725248404xxxx"
}
}

About 1x per day this program resets.

Could this instance of Spark.variable be the cause?

Thanks - my time and intellectual capability I'd prefer to focus on just one platform. Cost is not a factor - not because I'm lucky enough for it not to be a factor but since I spend countless hours of my free time the $ diffs in platform costs are not a factor. I love to run LEDs and play with I2C and SPI sensors and Displays. Not working towards anything commercial - I just like to make interesting things. With my work this provides a great escape with benefits of learning and producing something.

So I have been playing with the following platforms:

  1. Learned the basics on Arduino with Unos, Mega, Yun and now Zero. Like Yun with the integrated radio but limited program memory space does not allow me any sloppy coding margin. The Mega and Zero fix that but would really like to avoid the entanglement of outboard radios with their associated integration and power issues. A Zero Yun w/ Blutooth LE radio running at Photon power levels with built in battery charging circuit = perfecto (if they are reading they are free to use that)
  2. Edison program space allows me to be a bit sloppy on coding - integrated high speed wifi and bluetooth radios - onboard battery charger but a bit demanding on power. Also requires me to learn Python (up and downs sides). Nice coding environment too for wired or wireless updates. The 1.8v IO buss is extra work in a 3.3v and 5v world forcing me to invest and sort through level converters (I have everyone of them now). I like that cloud functionality and integration is 100% optional and not a requirement.
  3. Been looking at the TI platforms too but have held off on more platform investments.
  4. Particle platform looks to be almost perfect - have core for testing and 2 photons on order. Photon memory space looks to be more than adequate - hard to tell from specs but looks to be about Arduino Mega size 100k+ . The built-in cloud functions and dashboard shave a bunch of learning curve but comes at the expense of the platform needing to work vs me just sending data to my own space. I can live w/o as wifi is just fine and look forward to punching past 802.11B with the photon. And I could these investments paying dividends on the coming Electron platform. Fantastic development choices with web or the local client. See GitHub as the bomb for all of this - keeping my code in 1 place and accessing it on either coding platform. Lots of potential there and just getting started with figuring that out.

[should I put all of the above into a separate post to 'spark' more conversation or add onto another on someplace. Search does show a lot of comparisons on the baseline platforms.]

But these core reset issues are plaguing me and I am working hard to sort them out prior to final platform choice. I have the core running on a 5v 10a supply used to run the strip. The program has been running for over 5 months and recovers itself every time. So no crazy SOS panics - are these resets just to be expected?

Here is the rest of the code:

#include "Adafruit_BMP085.h"
#include "neopixel.h"
#define PCOUNT  150
#define PPIN    A4
#define PTYPE   WS2812B

Adafruit_NeoPixel strip = Adafruit_NeoPixel(PCOUNT, PPIN, PTYPE);
byte mix[3][3] = {{23 ,59,118}, {129,63, 64}, {62 ,92, 43}}; // Spring: 19-4052 Classic Blue, 18-1438 Marsala, 18-0135 Treetop
int pWidth = 30;
int speedMS = 250;
char up [60];
String upSince;
Adafruit_BMP085 bmp;
double bmp_tempF = 32.0;
double bmp_presHG = 29.00;
double bmp_altFt = 1000.0;
void setup() {
    Time.zone(-6);
    bmp.begin();
    strip.begin(); 
    Spark.variable("up", &up, STRING);
    upSince = Time.timeStr().c_str();
}

void loop () {
    bmp_presHG = bmp.readPressure()*.000295333727;                 // hPa to inHg (*0.000295333727)  hPa (hectoPascals).
    sprintf(up, "SN: %i Up Since: %s Pres=%.2f hPa", WiFi.RSSI(), upSince.c_str(), bmp_presHG);
    LightUp (pWidth, speedMS);
}

void LightUp (int pWidth, int speedMS) {
    int offset = speedMS > 0 ? millis() / speedMS : 0;
    for (int i = 0; i < PCOUNT; ++i) {
        int colorIndex = ((i + offset) % (3 * pWidth)) / pWidth;
        strip.setPixelColor(i, mix[colorIndex][0], mix[colorIndex][1], mix[colorIndex][2]);
    }
    strip.show();
}
6

This is a common mistake. Don't use the ampersand & in this statement. up without [] is already a pointer.
I've not looked any further yet, but that's a quick fix and you can see if your problem goes away with it :wink:

Another thing to look into might be how you program copes with a longer absence of the cloud, which could be due to a IP release that might be imposed to the Core by your router every 24 hours or so.

7

thanks very much - changed my code. Appreciate the advice - been trying to understand the nuances of the &.

And of course on the ip address subscription - that could very well be a factor - I think my modem is set for 24 hours.

2 Likes
8

:+1: to what everybody has been saying, and I’ve heard similar things about shorter DHCP lease times. Many home routers have a lease of a week or longer, which works well if you’re not expecting a huge churn ( lots of devices joining and leaving) on your network. Sounds like a cool project!

Thanks,
David