Page 1 of 1

RECEIVERS232STRING QUESTION

Posted: Sun Dec 21, 2014 10:54 am
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

Re: RECEIVERS232STRING QUESTION

Posted: Sun Dec 21, 2014 11:57 am
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.

Re: RECEIVERS232STRING QUESTION

Posted: Mon Dec 22, 2014 9:28 am
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 :)

Re: RECEIVERS232STRING QUESTION

Posted: Mon Dec 22, 2014 11:51 am
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!

Re: RECEIVERS232STRING QUESTION

Posted: Mon Dec 22, 2014 3:17 pm
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.....

Re: RECEIVERS232STRING QUESTION

Posted: Mon Dec 22, 2014 3:30 pm
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

Re: RECEIVERS232STRING QUESTION

Posted: Mon Dec 22, 2014 4:57 pm
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.

Re: RECEIVERS232STRING QUESTION

Posted: Tue Dec 23, 2014 9:42 am
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

Re: RECEIVERS232STRING QUESTION

Posted: Tue Dec 23, 2014 1:23 pm
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.

Re: RECEIVERS232STRING QUESTION

Posted: Thu Mar 05, 2015 1:54 pm
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

Re: RECEIVERS232STRING QUESTION

Posted: Thu Mar 05, 2015 2:08 pm
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

Re: RECEIVERS232STRING QUESTION

Posted: Thu Mar 05, 2015 2:36 pm
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

Re: RECEIVERS232STRING QUESTION

Posted: Thu Mar 05, 2015 6:42 pm
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.