Pseudo-serial passthrough(?) OR controlling a serial device over the net

Hi @ScruffR

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.

Consider this:

char myStr[5][10];

void setup() {
    Serial.begin(9600);
}

void loop() {
    Serial.print(sizeof(myStr[2]));
    Serial.print("  ");
    Serial.print(sizeof(myStr[2][0]));
    
    delay(5000);
}

This prints “10 1”.

The address of myStr[2] and myStr[2][0] point to the exact same memory location, but sizeof(myStr[2]) returns 10, while sizeof(myStr[2][0]) returns 1.

This also means that if I have a pointer to myStr[2] called ptr and I do ptr++, it gets incremented by 10 and now points to myStr[3].

But if I have a pointer to myStr[2][0] called cptr and I do cptr++, it gets incremented by 1 and now points to myStr[2][1].

1 Like

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 :wink:

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 …

I would post a sample string that you are parsing, we could figure a lot of stuff out and help you more.

EDIT: Almost---Well. You're not going to believe this (or maybe you are) but it worked now. I just reuploaded it and got the following:

STS,1
MO,6712,ID,1128085203,TI,41778.79058,STS,1,STI,41764.60713,BTL,5,SVO,1000,SOR,3,CS,4771

CS,4771

TI,41778.79058,STS,1,STI,41764.60713,BTL,5,SVO,1000,SOR,3,CS,4771

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

1 Like

Well done! Glad to hear it is working for you now.

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)

1 Like

EDIT: To include explanation without multiple postings

[strike]Thank you but the congratulations was premature it seems.[/strike]

I tried it again after performing other actions and am getting 1 red flash between the SOS.
I’ll try some of ScruffR’s recommendations too

This is the string I am parsing
MO,6712,ID,1128085203,TI,41778.79058,STS,1,STI,41764.60713,BTL,5,SVO,1000,SOR,3,CS,4771

After performing all of ScruffR’s recommendations, it works again. It looks like I was going over the limit somewhere.

3 Likes