Re: 8ms Timer for serial port access
From: David Schwartz (davids_at_webmaster.com)
Date: 10/29/03
- Next message: Byron A Jeff: "Re: 8ms Timer for serial port access"
- Previous message: Michael Fuhr: "Re: Q: SIGALRM deferred during read() ?"
- In reply to: Jens Schumacher: "Re: 8ms Timer for serial port access"
- Next in thread: Jens Schumacher: "Re: 8ms Timer for serial port access"
- Reply: Jens Schumacher: "Re: 8ms Timer for serial port access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 28 Oct 2003 15:01:17 -0800
"Jens Schumacher" <jens.schumache@gmx.net> wrote in message
news:BBC44E5C.1C8D%jens.schumache@gmx.net...
> > Then just call read() and ask for the number of bytes in a frame. You
don't
> > need to wait between calls to read() -- it will wait for the data.
> I used the timer because I though it takes to much performance to call the
> read function in a loop. And I used it to synchronize the serial port with
> my application. Do you think I should run a loop to read from the port all
> the time? Is there a big difference between running this driver in user
> space or as a module?
You could loop on a blocking read. You could also use 'poll' to wait up
to a certain amount of time. The key is that each time you call 'read', you
*must* read all the data that's available before sleeping.
Do not try to teach the kernel that 24 bytes means something special to
you. It doesn't care. If you get 8 bytes, wonderful. You'll get 16 more
later. If you get 36 bytes, fine, process 24 of them now and save 12 for the
next time you get some data.
> >> But how comes that, even when I trigger the timer as fast as possible,
I
> >> don't get better results.
> >
> > Because the kernel's timer interrupt is 10ms, and that is therefore the
> > granularity of task scheduling. The real question is why are you
sleeping?
> I need a timer to load the data in the application and to process it.
No, you don't. You read the data when it's ready, not at some magic
time. You can use 'poll' to tell when there's data ready or you can use a
blocking read. Here's what you're doing:
1) Wait X time
2) Read Y bytes
3) Repeat.
Here's what you should do:
1) Wait X time or block in 'poll' until data is available.
2) Read however many bytes there are.
3) Repeat.
> I just need the data from the serial when a whole frame arrives every 8ms
> and need to process the data directly. I never thought this would be a
> problem on a modern system.
It's not a problem, you'd just trying to teach the kernel that 8
milliseconds and 24 bytes are special. It doesn't care and so won't do what
you want it to do. Just read however much data it has whenever it has it and
you'll be fine.
You can even do this:
1) Wait 8 milliseconds (though it will probably really be ten)
2) Read as many bytes as are ready without blocking.
3) Process as many complete frames as you now have saving any leftover
bytes for the next pass.
DS
- Next message: Byron A Jeff: "Re: 8ms Timer for serial port access"
- Previous message: Michael Fuhr: "Re: Q: SIGALRM deferred during read() ?"
- In reply to: Jens Schumacher: "Re: 8ms Timer for serial port access"
- Next in thread: Jens Schumacher: "Re: 8ms Timer for serial port access"
- Reply: Jens Schumacher: "Re: 8ms Timer for serial port access"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|