Flowcode Support Board

Hi, 
Serial component - Rx string
This question, that may actually be a request!
It is for an App Dev project but it may be useful in embedded applications as well. 

I have a repeating serial string. I am using the Rx string component to recieve the string. 

As I understand this macro will exit when, 
A) there is no data for specified timeout period. 
B) the recieved data exceed the Max Length parameter. 

Is it possible to define a received character to force the string collection to end. This could be an character or escape character maybe.
Is this currently possible or would it require a modiification to the Receive String Macro?

Thanks, J. 

I tried looking inside the Comm Port component source code. I can see Recieve string and that this gets data from Recieve Byte.
But I struggle to see how the string was made and I think I'm more likely to break my Com_Port component, haha

I have not tried but I assume , I would need to set up a new parameter for the 'Stop_Char' character, then In a deciion loop, check if .in = Stop_Char.
If so, set .MaxLength = .idx
I think this would end the recieve string loop.
But as I say, i dont really understand exacly how the COM_Port macro works as a whole and if such an action would break something else!

So.. is this a Fault or am I just working the system too much?

My aim is to enable reliable reception of strings of varying length from a PIC and into App Dev, fast as possible.

The App Dev COMM component "RecieveString" appears to stop collecting bytes when,
a) the sequence of recieved bytes exceeeds the specific length - I have seen this work
b) there is a delay in the incoming data, greater than the timeout (in mS) - This does not seem to work. Or at least it needs a big delay, >100mS

Test.
I have an Embedded FC10 and PIC sending data out over UART. It sends groups of data bytes.
8 bytes, 10ms wait, 4 bytes, 100ms wait, 10 bytes and a 300mS wait. Flash the LED and Loop. The recieve is done in App Dev.
It simple recieves serial datastrings and writes them to a console.
The RecieveString component is set to a timeout of 2mS
If a timeout or maxlength is recieved it should seperate the strings into seperate parts. By monitoring the Console, I get erratic blocks of data out.
I appreciate windows is not a realtime system..so is this just windows being slow and randomly detecting the timeout?
I get tha same behaviour in Simulation and Compiled into an App.

Thanks. J.

P.S. This is my just testing to understand the component behaviour, ideally I would like to be able to send a character that forces the RecieveString macro to terminate.

Hello,

Currently a null will terminate the received string. Otherwise yes your thoughts are correct. Timeouts and COM ports are a bit broken in my experience of modern windows. They used to be really good but then took a back seat as more and more was built underneath them. Steve is probably more better suited to answer this portion

However in the attached I've added a new function "ReceiveStringWithTermination" that has an additional string and length parameter to allow a bit more then a single byte to be used as the termination sequence. The termination sequence will still be appended to the end of the returned string.

Have a go and let us know if it's any good and I'll put it on the update system. If it's ok then I might add it to the other serial components, UART, Bluetooth etc as it is handy.

The file needs to be placed here. C:\ProgramData\MatrixTSL\FlowcodeV10\Components
Here's the latest source if you want to see or have a play with it.

Another way I commonly use is to collect everything that's been received, e.g. keep receiving until you get a timeout and pop everything into a circular buffer. Then use the functions of the CB component to check for things like the beginning and end of a command.

Fantastic Ben, I'll have a play.
Honestly its this sort of support that puts FlowCode ahead of the rest. J.

Only done some basic testing but terminting on a specified character has really cleaned up the data I recieve in App Dev Console.
Thanks Ben and the FC Team.