[En-Nut-Discussion] How to write character filter with timeout?

[Ulrich Prinz]

On Thu, 20 Aug 2009 18:52:35 -0300, Thiago A. Corrêa 
<thiago.correa at gmail.com> wrote: 
> Hi, 
>  
> On Thu, Aug 20, 2009 at 5:48 PM, Ulrich Prinz<uprinz2 at netscape.net> 
wrote: 
>> 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.  
 
Best regards, 
Ulrich