You are right that the 2d char array is in memory linearly like one big array but you can refer to the parts because the compiler and sizeof() “know” that a reference with just one index refers to the entire second index worth. I know that you know this stuff but I am going to give a bit more detail for others who might be reading here.
Indeed, I am still using strings. Here are the variables declared at the top of the file
char inSerial[200];
//unsigned long currentime;
//bool stbyflag = true;
int nStr;
String stsArName[6];
int stsArVal[6];
String stMessage;
String erMessage;
bool PoweredOn;
/* This function is called once at start up ----------------------------------*/
void setup()
{
//Register Spark function in the cloud
Spark.function("connect", ISCOConnect); // if 1 is returned then we connected
Spark.function("status", ISCOStatus);
Spark.function("control", ISCOControl);
//Expose variables to the cloud
Spark.variable("strReceived", inSerial, STRING);
Serial1.begin(9600); //comm with isco
Serial.begin(9600); //comm with computer
// currentime = millis();
nStr=0;
PoweredOn = true;
}
BKO, do you recommend that I stop using strings then? I'm not getting errors writing to the strings. It appears that it is getting passed the whole char array (I printed those values to screen at one point). Is parsed status still getting pointed to something random?
No, if strings are working for you they are great! Creating and destroying lots of Strings can lead to memory problems but you shouldn’t have trouble copying into them. I am still not sure you need the parsedStatus[][] array–you could just copy them into your Strings in the parser.
I assume you are still having memory problems–what about the length of these chars?
This is a long-shot but I have also had weird things happen with this compiler when I do if (boolVar) { ... } so in my code, the while loop looks like:
while(token != NULL) {
...
}
What you wrote is perfectly legal C but like I said this compiler with the Arduino-like preprocessor is sometimes funny.
@ruben, after all these C ins and outs back to your problem
There are a lot of possible reasons - one of is the already mentioned RAM issue.
But there are others, too.
I might have missed it in your posts, but what kind of red flashing do you see? SOS + how many blinks?
As I don’t know what your inSerial actually looks like, I’d see the possibility that your counter++ might exceed 14 leading to corrupted data - try limiting your while by doing while(token && counter < 15).
A similar thing might happen with your strcpy() if token is longer than 14 chars - try using strncpy() instead, to limit the max length.
Another problem - which I can’t see evidence for in your code, but for completeness - if you find your code crashing on a return statement, it might be due to a corrupted return address or register state on the stack.
Whenever you call a function, the address, where to carry on after the function has finished its work, gets popped onto the stack, along with some other info (e.g. some µP registers). Additionally function arguments will be popped onto the stack and local vars will be placed there too.
If some operation on arguments or local vars go beyond the respective bounds it might damage the data on the stack that would be needed to propperly return to the position in code, where we left off - most certainly leading to a crash.
Another possible way to crash is an almost exhausted stack space. If your functions use a lot of big local vars (e.g. arrays) and/or deep nested calls (function calls function calls function …) you gradually “fill” the stack closer and closer to its limit. When you then call another function - even only delay() - this can lead to a crash, since the necessary info couldn’t be popped on.
To check this out, you could print out the addresses of the last local vars in your functions and check their location against the stack limit.
BTW: Since delay() does do some cloud stuff while it’s waiting it in turn will call functions which do call functions …
looks like status string is complete and in right direction/prob not repeated
we made it
passedgauntlet
DataParse Complete
begintodisplaymessage
1= WAITING TO SAMPLE
bottle
5
volume
1000
USER STOPPED
Done
That last part comes from DisplayMessage()
begintodisplaymessage
1= WAITING TO SAMPLE
bottle
5
volume
1000
USER STOPPED
I did just go ahead and change while to the not equal to null.
I would like to read right into the string but I didn’t do that because I wanted to perform some QC on the data before adding them. It takes more memory I suppose but it goes with the way I think: gather the data, look at the data, approve the data, save the data (longterm)
