[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [rtl] Serial querry
Good points Chris. Thanks for the reply.
The analog channels are connected to integrators which need to
be read as close as possible to each other. The ADC takes 10us
to perform a conversion. I wasn't certain if it was worth while
to relinquish control if another conversion needs to done in 10us.
(The channels are scanned in quick succession, then the integrators
reset and allowed to accumulate for another 249ms)
What I'm wondering is: if the real time task sets a timer to be
awakened in 10us, then relinquishes control, how much of the 10us
is used up in the overhead of switching out, then back in to the
task once the timer fires? Is there much time left for the non
real time tasks?
Also, what is the latency from the time the real time timer interrupt
fires and the real time task begins processing?
This will be highly dependant on CPU speed, but does anyone have
any numbers?
Jim.
At 11:46 AM 5/8/98 -0700, Chris Albertson wrote:
>Jim,
>
>Do you really need to stay in the RT task for 1ms? I suspect
>you may be waiting on an ADC conversion in your RT task. I
>would not do that. IMO it is an un-needed waste of CPU time.
>
>What I do is have an 8KHz interrupt on each tick I
> 0) If (not time_to_read) return
> 1) Read sample N
> reset time_to_read
> 2) Do a "start convert" on sample N + 1
>
>In a 10Hz loop I do
> 1) time_to_read = 1
>
>You could use a 1KHz and 4Hz loop and your CPU would never be
>blocked for more than a few micro seconds.
>
>
>The 1/8000 sec period is just a bit longer than my ADC's conversion
>time so I never have to wait. The trick is to do it backwards
>read _then_ start the converter. Never do a busy wait inside
>an RT task.
>
>If you think you will have problems with your serial port what
>about Ethernet, the disk, floppy tape drive and so on?
>
>Actually my program is a bit more complex. I have two loops.
>Each is a Finite State machine with about a dozen states and
>make a transition once per cycle I third task accepts commands
>from a user program. but the above is the guts of it. I read
>blocks of 2400 16-bit integers off the interface. One block
>about every 0.9 seconds. The whole RT process does not seem
>to have any effect on even my 486/66. The reason is there is
>_no_ wait loop anyplace in the RT code.
>
>James Cassidy wrote:
>>
>> Hello everyone. I've got a querry regarding serial processing....
>>
>> The real time task that I'm setting up will scan a bunch of ADC
>> channels very quickly. This will take up to 1ms every 250ms.
>> So I'm assuming that the serial interrupts won't be processed by
>> Linux for this 1ms block.
>>
>> Does this mean that the speed of the serial port is limited?
>> I.e. at high baud rates, could I experience serial overruns?
>>
>> I beleive the serial hardware has a 16 byte buffer, so is my
>> serial rate limited to:
>>
>> time to recieve 16 bytes < 1ms
>>
>> Just want to make certain that I'm understanding the constraints
>> before I get too far.
>>
>
>--
>--Chris Albertson
>
> chris@topdog.logicon.com Voice: 626-351-0089 X127
> Logicon RDA, Pasadena California Fax: 626-351-0699
>--- [rtl] ---
>For more information on Real-Time Linux see:
>http://rtlinux.cs.nmt.edu/
>
>
--- [rtl] ---
For more information on Real-Time Linux see:
http://rtlinux.cs.nmt.edu/