These are chat archives for SmingHub/Sming

8th
May 2017
Curtis Pope
@piperpilot
May 08 2017 01:44
@slaff still not sure why its crashing...seems to be something deep in the uart code. I'm trying to figure it all out now, but one thing I notice is a major logic change. In the old implementation, there was a callback on each character that was received. This would allow you to check for a specific end of line character. Seems like now, the uart interrupt processes all characters in a loop adding them to a buffer and then issues the callback...of course, there is a lot of code I'm not quite understanding...so maybe thats not the case, but thats what it seems like. Due to this, I'm only seeing every 3rd message I send in. I would love some help in figuring out what is going on...
vjacob
@vjacob
May 08 2017 07:37
hello @piperpilot , I had the same issue after the refactoring. I've changed my code as below to make it work again:
void SerialDelegate::onData(Stream& stream, char arrivedChar, unsigned short availableCharsCount)
{
while (stream.available())
{
    char c = stream.read();

    switch (c)
    {
    case X: {}
         break;

    // ... other character handlers...

     default:
        break;
}
}
Curtis Pope
@piperpilot
May 08 2017 11:14
thanks @vjacob I was considering that, but my message I am processing is about 160 chars in some cases (JSON)...the onData handler gets called multiple times before the whole message has arrived. I will need some kind of buffer or something to hold the data until the entire message arrives
riban-bw
@riban-bw
May 08 2017 12:35
Sounds like a helper function might be useful here. Something like, trigger callback when a character or string is received. Would need some form of housekeeping to handle buffer filling before callback.
Curtis Pope
@piperpilot
May 08 2017 12:37
@riban-bw yeah...I'm guessing the reason my app is crashing is because of the buffer filling up, but its strange there is NO feedback at all about what might have caused it. Definately need some kind of trigger on a certain character or the ability to do a callback on every character again
I'm experimenting with the stream functions right now...using stream.readString to see if I can get around this by calling that on every callback and if it gets a fully string do the processing
seems very slow though
Curtis Pope
@piperpilot
May 08 2017 13:38
well, the stream functions don't seem to be much help. I was thinking of using peek to inspect all chars in the stream looking for the string delimiter...but peak doesn't seem to advance and only returns the first character in the stream. The stringRead functions are interesting, but they consume the bits and require another buffer...so not ideal
Elmar
@elamre
May 08 2017 17:40
@slaff This makes me very happy! Thanks
vjacob
@vjacob
May 08 2017 18:11
hello @piperpilot , yes exactly. This is for reading all the available chars, without missing any. I'm having the exact same use-case as you, piping JSON data to another MCU. Nothing prohibits you to have a buffer where all the incoming bytes are stored. Wrap each message for example between an STX (0x02) to flag start and an ETX (0x03) to flag an end. Then use these in your switch/case statement to when a new message arrives/a message has been full received. As such STX clears the incoming buffer, ETX parses the (completed) incoming buffer. Any other character is just stored in the incoming buffer.
Curtis Pope
@piperpilot
May 08 2017 18:14
yeah, something similar to that is what I ended up doing...having a separate buffer...but it is really a waste. If the callback were called on every character like it was initially designed, then we wouldn't have to do that. The callback doesn't actually make any sense now...as one of the callback variables is arrivedChar...each callback is actually multiple characters and the only way to access them is to actually read them out of the stream...if we could just leave them in the stream (buffer) until the proper end of message character it would be much more effecient
vjacob
@vjacob
May 08 2017 18:53
@piperpilot , I'm sure @slaff had his reasons re-designing it like this, one consequence for example is having far less callbacks, thus interrupts of your program. 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.
Curtis Pope
@piperpilot
May 08 2017 19:45
@vjacob understood...its a work in progress and is definitely more efficient than the old method. It just breaks existing implementations and examples. We need to think of a way to restore functionality so that it works better and can enable efficient parsing based on a delimiter. Unfortunately the code in the uart library is a little over my head ;-)