RECEIVERS232STRING QUESTION

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 5.
To post in this forum you must have a registered copy of Flowcode 5 or higher.

Moderator: Benj

Post Reply
MarkW
Flowcode v5 User
Posts: 118
Joined: Thu Sep 17, 2009 1:30 pm
Has thanked: 3 times
Been thanked: 11 times
Contact:

RECEIVERS232STRING QUESTION

Post by MarkW »

Hello,

I have looked in the help section about the receive string function, and understand
the various parameters, but i have a question about what the timeout parameter
is actually based on? Using FC V5....

The nTimeout byte seems like a value between 0-255. But the help file does
not explain what that value represents? Lets say i use a value of 100....what does
that mean? 100msec....100 "cycles".....???

Thanx

Mark

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by medelec35 »

Hi Mark,
You can set the timeout to be in milliseconds via Ext Properties:
232 Ext set.png
(49.86 KiB) Downloaded 5962 times
That will be a better way than to use legacy.
Martin

MarkW
Flowcode v5 User
Posts: 118
Joined: Thu Sep 17, 2009 1:30 pm
Has thanked: 3 times
Been thanked: 11 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by MarkW »

Hi there,

Thanx for info....i didnt know that setting also worked
for receive string.

So, if i set it to millisecs, and in the string receive function
i set the ntimeout value as 200, that would imply 200mS
delay to terminate the string capture?

Just trying to understand the timeout value/meaning :)

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by medelec35 »

Hi Mark,
To be honest I'm not that knowledgeable on how the timeout works.
So this is just a guess, and some one can shed more light on the matter?
Each time the RX goes from high to low the rx interrupt macro is accessed and left (not waiting for a time out) and timed between that and next time it goes low.
This is not a part of the time out as I believe the time out is for the time it takes for all eight bits take to be decoded.
If all bits are not decoded within timeout set then which ever bit is being decoded with be left and byte or string bit will be reset to wait for the first bit.
Of course I could be totally wrong!
Martin

MarkW
Flowcode v5 User
Posts: 118
Joined: Thu Sep 17, 2009 1:30 pm
Has thanked: 3 times
Been thanked: 11 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by MarkW »

Hi (sorry dont know your name!)

What you say might be so, however logically i think whats going
on is that the timeout is a time period for waiting to see if all
chars are received for the string. If so it should end the string
with a null character and then exit the interrupt macro....going
to test this bit later.

It has to "wait" until the string is fully captured, then if there
is no more chars coming in it should then consider the string
complete....oherwise how would you populate the string unless
it was using a circular buffer.

I have already used a circular buffer using the char receive
function but now i need to use the string capture function
as the 232 streams i get are unknown length. Then its difficult
to establish end of the string as its done on single char capture
into the buffer on interrupt, theres no timeouts. So, hopefully
the string receive will help me here.

We might need Ben or one of the guys to fill us in how the ntimeout
works with more details.....

medelec35
Matrix Staff
Posts: 9520
Joined: Sat May 05, 2007 2:27 pm
Location: Northamptonshire, UK
Has thanked: 2585 times
Been thanked: 3815 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by medelec35 »

MarkW wrote:Hi (sorry dont know your name!)
It's Martin

What I did was to USB Test pod and measure how long the RX interrupt macro was being accessed for when i/p to RX went from logic 1 to logic 0.
It turned out that even with Byte set for 255 the interrupt macro was accessed the exited within a few microseconds, so the waiting is not within that macro.
That was all the hardware testing I did.
MarkW wrote:We might need Ben or one of the guys to fill us in how the ntimeout
works with more details.....


Totally agree with that!

Martin
Martin

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by Benj »

Hi Guys,

The receive string macro does the following. It will try to receive characters up to the count specified in NumBytes.

If the number of characters reaches the NumBytes then we add the null termination and immediately return.

The nTimeout parameter specifies the maximum delay in between bytes to wait. If we receive a byte then the timeout is reset back to the initial value to wait for the next byte.

If a time out event occurs then the data we have collected so far is packaged into a string with the null terminator.

You could use the circular buffer method but after the string data maybe add a "\n" or "\r" character as a fixed delimiter to signal the end of the string.

MarkW
Flowcode v5 User
Posts: 118
Joined: Thu Sep 17, 2009 1:30 pm
Has thanked: 3 times
Been thanked: 11 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by MarkW »

Hi Ben,

Thanx for explaining that....had idea that was going on there.

Can you also please explain the ntimeout value? For example
if i use 200 in the ntimeout value, does this mean 200mS
or some other quantity? Martin suggested i use the
"milliseconds" in the 232 config panel....

What is the difference between "legacy" and "millisecs"?

Thanx guys

Mark

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by Benj »

Hi Mark,

Legacy is literally the number of iterations which will generate a short delay which will vary greatly depending on clock speed.

Milliseconds adds a 1ms delay to each iteration to allow the generated delay to be uniform no matter what clock speed your using.

MarkW
Flowcode v5 User
Posts: 118
Joined: Thu Sep 17, 2009 1:30 pm
Has thanked: 3 times
Been thanked: 11 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by MarkW »

Hi Ben,

Just got round to trying the receive string macro. Does not seem to be working....
Using 18F66K22 and FC V5

I am putting the receive string function in an interrupt macro which has a loop
to receive the string. Copied the procedure exact same as the flowcode V5
example. I set the timeout to 50 (legacy) and nbytes to 9.

It enters the interrupt macro but never gets out (sending string out once
the receive has timed out or max chars received).

The interrupt is working perfectly for if i do a byte receive and echo out
it works 100%

Appreciate your input here

Mark

MarkW
Flowcode v5 User
Posts: 118
Joined: Thu Sep 17, 2009 1:30 pm
Has thanked: 3 times
Been thanked: 11 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by MarkW »

Hi Ben,

Also tried using the string receive function in the uart interrupt
without a loop, also nothing doing....does not exit the interrupt
and does not send out anything either (sending out the string
once supposedly captured)

Thanx

Mark

MarkW
Flowcode v5 User
Posts: 118
Joined: Thu Sep 17, 2009 1:30 pm
Has thanked: 3 times
Been thanked: 11 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by MarkW »

Hi Ben,

Ok found the problem :D

Cannot make the string 256 members, otherwise it falls
on its nose. I needed a large buffer because i could receive
up to 200 chars at a time.

I changed the string array to 200 members and it now works.
Little headsup there for you fellows out there

Thanx

Mark

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: RECEIVERS232STRING QUESTION

Post by Benj »

Hi Mark,

This limitation should only exist on the 8-bit PIC devices. There is a workaround should you need longer data arrays but it's probably best to keep the size smaller if you can get away with it.

Post Reply