[Xenomai-help] Application question

[Xenomai-help] Application question

[Travis Stratman]

Hello,

I have an application that I'm trying to solve. I don't have a lot of
experience programming in real-time under an OS, so I'm trying to
determine if this is possible at all and what the best method of solving
it is.

The target for this application would be an Atmel AT91SAM9260 processor
or AT91SAM9G20 (9260 at 400 MHz essentially). The main constraint is
that the ADC in the processor must be sampled at 200K samples/sec which
gives a period of about 5 us. This sampling happens in bursts of 50 to
several hundreds of samples (so at most 2 ms for this task). Once the
data is analyzed, a value is set on a DAC. Once the value has been set
10s to 100s of ms go by before the cycle starts over again with sampling
and analysis.

The timing on the sampling is pretty critical, though a little jitter
might be acceptable at times. In general there shouldn't be much else
going on in the background on the board. The ADC block is rated at a max
312K samples / second.

The 5 us sampling period is too fast to schedule the sampling as a
periodic task. But, since the actual sample burst time is under 1 ms
most of the time I was thinking that I might be able to schedule a
thread to take a certain number of samples in one task, inserting delays
between each sample to get the timing right.

Is this possible or is this an application that should be done on a much
lower level? Am I on the right track at all?

Thanks in advance,

TAS

Re: [Xenomai-help] Application question

[Gilles Chanteperdrix]

Travis Stratman wrote:
> Hello,
> 
> I have an application that I'm trying to solve. I don't have a lot of
> experience programming in real-time under an OS, so I'm trying to
> determine if this is possible at all and what the best method of solving
> it is.
> 
> The target for this application would be an Atmel AT91SAM9260 processor
> or AT91SAM9G20 (9260 at 400 MHz essentially). The main constraint is
> that the ADC in the processor must be sampled at 200K samples/sec which
> gives a period of about 5 us. This sampling happens in bursts of 50 to
> several hundreds of samples (so at most 2 ms for this task). Once the
> data is analyzed, a value is set on a DAC. Once the value has been set
> 10s to 100s of ms go by before the cycle starts over again with sampling
> and analysis.
> 
> The timing on the sampling is pretty critical, though a little jitter
> might be acceptable at times. In general there shouldn't be much else
> going on in the background on the board. The ADC block is rated at a max
> 312K samples / second.
> 
> The 5 us sampling period is too fast to schedule the sampling as a
> periodic task. But, since the actual sample burst time is under 1 ms
> most of the time I was thinking that I might be able to schedule a
> thread to take a certain number of samples in one task, inserting delays
> between each sample to get the timing right.
> 
> Is this possible or is this an application that should be done on a much
> lower level? Am I on the right track at all?
> 
> Thanks in advance,

Polling during the time of the acquisition seems to be your best chance
on an ARM. However, one issue remain or maybe I did not understand
correctly your explanation: how do you wake up on time for the beginning
of this acquisition? Wake-up jitter is pretty high on ARM, even with
FCSE, you can count on something like 100us.

-- 
					    Gilles.

Re: [Xenomai-help] Application question

[Travis Stratman]

Thanks Gilles.

On Thu, 2009-03-12 at 23:48 +0100, Gilles Chanteperdrix wrote:

> > 
> > The target for this application would be an Atmel AT91SAM9260 processor
> > or AT91SAM9G20 (9260 at 400 MHz essentially). The main constraint is
> > that the ADC in the processor must be sampled at 200K samples/sec which
> > gives a period of about 5 us. This sampling happens in bursts of 50 to
> > several hundreds of samples (so at most 2 ms for this task). Once the
> > data is analyzed, a value is set on a DAC. Once the value has been set
> > 10s to 100s of ms go by before the cycle starts over again with sampling
> > and analysis.
> > 
> > The timing on the sampling is pretty critical, though a little jitter
> > might be acceptable at times. In general there shouldn't be much else
> > going on in the background on the board. The ADC block is rated at a max
> > 312K samples / second.
> > 
> > The 5 us sampling period is too fast to schedule the sampling as a
> > periodic task. But, since the actual sample burst time is under 1 ms
> > most of the time I was thinking that I might be able to schedule a
> > thread to take a certain number of samples in one task, inserting delays
> > between each sample to get the timing right.
> > 
> 
> Polling during the time of the acquisition seems to be your best chance
> on an ARM. However, one issue remain or maybe I did not understand
> correctly your explanation: how do you wake up on time for the beginning
> of this acquisition? Wake-up jitter is pretty high on ARM, even with
> FCSE, you can count on something like 100us.
> 

I'm not completely sure at this point... a customer has presented this
problem and I'm looking at the feasibility of it for now. I think that
an external flag will be read (some PIO line, possibly an interrupt)
that signals when a motor has settled down at which point calibration
begins again. I don't think that this timing is nearly as critical as
the sampling rate. I asked him to provide further information on it just
in case.

At this point I think the best thing for me to do at this point would be
to do some testing. I also noticed that the ADC seems to support
scheduling triggers using a timer/counter output and transferring
samples to a DMA buffer... this would be ideal if I can get it to work
right.

Thanks,

TAS