These are chat archives for SmingHub/Sming

May 2017
May 09 2017 08:55

one consequence for example is having far less callbacks, thus interrupts of your program.

That is exactly one of the advantages. It brings better responsiveness and fewer hard-to-chase crashes due to overlapping of callbacks.

I will need some kind of buffer or something to hold the data until the entire message arrives
yeah, something similar to that is what I ended up doing...having a separate buffer...but it is really a waste.

HardwareSerial has its internal buffer, so there is no need for having a second buffer on top of it. The buffer is 256 bytes long and, if needed, can be resized.
Is there a delimiter or character that signifies the end of the data? If yes, then you can look for that character and then process the whole data. Take a look at the Basic_rBoot example.

I'm guessing the reason my app is crashing is because of the buffer filling up

@piperpilot Can you create a small sample code that illustrates your issue? Maybe you have memory leak, or other unexpected things are happening? Without code everything is just speculation.

But I agree the function signature is flawed like this (I was also confused with the new meaning of the 'arrivedChar' parameter) and the change could have been documented better.

@vjacob Agreed. Can you submit a PR with better documentation?

if we could just leave them in the stream (buffer) until the proper end of message character it would be much more effecient

As I said already - just take a look at the Basic_rBoot example.

Curtis Pope
May 09 2017 13:51
@slaff I appreciate the comments, but I don't think the example in basic_rBoot will work all of the time too. Maybe the problem is I'm using a slower serial speed (19,200), but you can't rely on being able to inspect the arrivedChar. Depending on speed, etc it will get missed. I will work up an example for you to see it, but the data comes in in "chunks" and in a lot of cases the delimiter isn't seen