[En-Nut-Discussion] How to write character filter with timeout?
uprinz2 at netscape.net
Fri Aug 21 09:46:06 CEST 2009
On Thu, 20 Aug 2009 18:52:35 -0300, Thiago A. Corrêa
<thiago.correa at gmail.com> wrote:
> On Thu, Aug 20, 2009 at 5:48 PM, Ulrich Prinz<uprinz2 at netscape.net>
>> Hi Harald!
>> But that doesn't solve my problem. If I wait a certain time on fgetc() I
>> miss characters that arrived after the one that is returned.
>> If I use it in a loop, the timeout of fgetc() must be added to the
>> NutSleep() ammount. But also then I miss characters, possibly containing
>> the one I search for.
> Looks like a bug then. I belive what Harald proposed should have worked.
No, it isn't... I try again...
I have a counter, that counts down from 500 to 0. On 0 the routine is
exited with return -1.
I wait for a 1ms timeout on fgetc() in that routine, so in total it waits
for 500ms, round about.
Now, any time a character is coming in, the timeout doesn't strike, instead
fgetc() is coming back with the char. In that case, I do not decrement
count. So every char coming in, extends the total period of time waiting
for a char.
I am wrong with the missing character in that case, as all characters
coming in are read.
So the negatives of my small solution are:
- Timeout is not kept exactly as every incoming char is extending the time.
- A client running dumb, sending lots of chars, but not the expected one,
can keep the routine active forever.
>> It seems to work. I set the timeout to 1ms and count down my timeout on
>> any EOF condition. Going that way means, that any received character
>> will not decrement the timeout as I cannot find out after what part of
>> the timeout the character occured. So any character extends the timout.
> Shouldn't you miss characters that arrive in that 1ms slot? I guess
> I'm not understanding it properly.
No I don't miss any char. That was a wrong idea from me. but the fgetc() is
coming back with the char before the timeout occures. If I decrement my
counter in the case a wrong char is coming in, the timout will be shorter
than expected. If I don't decrement my counter, ms periods where chars
arrive are not taken into account, so my timeout silently increases. There
is no other way than to check the timeout against a real timer.
>> Its ok for now, but is there any other way without breaking into the
>> driver structure? A routine like fsize( ) could help, to distinguish the
>> filesize / rx-buffer size of a stream device.
> I think there is a ioctl to get the buffer size. Some stream devices
> like USARTs and Network doesn't have a filesize, at most you can check
> for the bytes received so far.
Ok, that was the ffirst idea I had. Sleep for 10ms, check for ammount of
chars arrived and scan them for the one I'd like to see. Then sleep again.
I knwo about the ioctl to get / set the buffersize, high- and low-water
mark. But I don't know about functions to get the real size of the file, or
in my case, the actual ammount of bytes in the buffer. I found the routines
for the buffer handling of USARTs, but I didn't want to add some cruel
code, bypassing all standard API functions. If you tell me the correct
functions to determine filesizes, I can add that for buffers as well.
More information about the En-Nut-Discussion