Gentlemen,
I'm currently using an AT91SAM7S microprocessor to read a 1000-sample
vector from an SAR A/D converter via a SPI port.
The samples are taken every 16.6us, which amount to a total time of
16.6ms.
It seems best to use the SPI port DMA feature to move the SPI data into
the internal SRAM.
What is most important though is that the micro is able to maintain a
fixed sample period (16.6us) during the data acquisition.
Currently a simple loop is "tuned" to create a delay equal to 16.6us,
at which point the SPI select line is asserted Hi to start a conversion.
It seems best perhaps to disable interupts and use the SPI port DMA
during the data acquistion because it's absolutely necessary to avoid
interrupting the data acquisition process.
Regarding the 16.6us timing - it seems best to control the conversion
rate of the A/D converter in a manner that is as deterministic as
practicality will allow.
The micro is running at 50-mips, but still it's not clear if using a
counter-timer to generate a SPI event every 16.6us is practical.
Of course it will work, but perhaps using a "tuned" loop is just as
effective, especially if interrupts are turned off during the data
acquisition.
In the spirit of brevity I'll end it here.
Feel free to offer an opinion on this matter - I'll provide additional
information as necessary.
Thanks,
Marc
Re: SPI Port DMA
Started by ●December 5, 2008
Reply by ●December 6, 20082008-12-06
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
marcradzikowski wrote:
> Gentlemen,
>
> I'm currently using an AT91SAM7S microprocessor to read a 1000-sample
> vector from an SAR A/D converter via a SPI port.
>
> The samples are taken every 16.6us, which amount to a total time of
> 16.6ms.
>
> It seems best to use the SPI port DMA feature to move the SPI data into
> the internal SRAM.
>
> What is most important though is that the micro is able to maintain a
> fixed sample period (16.6us) during the data acquisition.
>
> Currently a simple loop is "tuned" to create a delay equal to 16.6us,
> at which point the SPI select line is asserted Hi to start a conversion.
>
> It seems best perhaps to disable interupts and use the SPI port DMA
> during the data acquistion because it's absolutely necessary to avoid
> interrupting the data acquisition process.
>
> Regarding the 16.6us timing - it seems best to control the conversion
> rate of the A/D converter in a manner that is as deterministic as
> practicality will allow.
>
> The micro is running at 50-mips, but still it's not clear if using a
> counter-timer to generate a SPI event every 16.6us is practical.
>
> Of course it will work, but perhaps using a "tuned" loop is just as
> effective, especially if interrupts are turned off during the data
> acquisition.
>
I guess you don't have any interrupt line between SAM7S and A/D so you
plan to poll A/D at every 16.6 usec for one sample. IMHO, this interrupt
timing is a little bit stressing for SAM7S. You can either use FIQ for
this purpose. However, since you don't receive any interrupt from A/D,
you can continuously read from A/D using SPI with DMA. You can adjust
delays between each transfers, so no interrupt overhead will be
incurred. You will only need to update DMA chain at every 65535 reading.
Caglar
> In the spirit of brevity I'll end it here.
>
> Feel free to offer an opinion on this matter - I'll provide additional
> information as necessary.
>
> Thanks,
>
> Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkk6XBsACgkQ/nL+S5dojeiG2wCcCn9IcHHlTnRs8gsMvxK5eCJB
l9gAoLSk90f/D3kEg1ZxCelW55sX8WTR
=l6kK
-----END PGP SIGNATURE-----
Hash: SHA1
marcradzikowski wrote:
> Gentlemen,
>
> I'm currently using an AT91SAM7S microprocessor to read a 1000-sample
> vector from an SAR A/D converter via a SPI port.
>
> The samples are taken every 16.6us, which amount to a total time of
> 16.6ms.
>
> It seems best to use the SPI port DMA feature to move the SPI data into
> the internal SRAM.
>
> What is most important though is that the micro is able to maintain a
> fixed sample period (16.6us) during the data acquisition.
>
> Currently a simple loop is "tuned" to create a delay equal to 16.6us,
> at which point the SPI select line is asserted Hi to start a conversion.
>
> It seems best perhaps to disable interupts and use the SPI port DMA
> during the data acquistion because it's absolutely necessary to avoid
> interrupting the data acquisition process.
>
> Regarding the 16.6us timing - it seems best to control the conversion
> rate of the A/D converter in a manner that is as deterministic as
> practicality will allow.
>
> The micro is running at 50-mips, but still it's not clear if using a
> counter-timer to generate a SPI event every 16.6us is practical.
>
> Of course it will work, but perhaps using a "tuned" loop is just as
> effective, especially if interrupts are turned off during the data
> acquisition.
>
I guess you don't have any interrupt line between SAM7S and A/D so you
plan to poll A/D at every 16.6 usec for one sample. IMHO, this interrupt
timing is a little bit stressing for SAM7S. You can either use FIQ for
this purpose. However, since you don't receive any interrupt from A/D,
you can continuously read from A/D using SPI with DMA. You can adjust
delays between each transfers, so no interrupt overhead will be
incurred. You will only need to update DMA chain at every 65535 reading.
Caglar
> In the spirit of brevity I'll end it here.
>
> Feel free to offer an opinion on this matter - I'll provide additional
> information as necessary.
>
> Thanks,
>
> Marc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkk6XBsACgkQ/nL+S5dojeiG2wCcCn9IcHHlTnRs8gsMvxK5eCJB
l9gAoLSk90f/D3kEg1ZxCelW55sX8WTR
=l6kK
-----END PGP SIGNATURE-----
Reply by ●December 8, 20082008-12-08
--- In A..., Yusuf Caglar AKYUZ wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> marcradzikowski wrote:
> > Gentlemen,
> >
> > I'm currently using an AT91SAM7S microprocessor to read a 1000-
sample
> > vector from an SAR A/D converter via a SPI port.
> >
> > The samples are taken every 16.6us, which amount to a total time
of
> > 16.6ms.
> >
> > It seems best to use the SPI port DMA feature to move the SPI
data into
> > the internal SRAM.
> >
> > What is most important though is that the micro is able to
maintain a
> > fixed sample period (16.6us) during the data acquisition.
> >
> > Currently a simple loop is "tuned" to create a delay equal to
16.6us,
> > at which point the SPI select line is asserted Hi to start a
conversion.
> >
> > It seems best perhaps to disable interupts and use the SPI port
DMA
> > during the data acquistion because it's absolutely necessary to
avoid
> > interrupting the data acquisition process.
> >
> > Regarding the 16.6us timing - it seems best to control the
conversion
> > rate of the A/D converter in a manner that is as deterministic as
> > practicality will allow.
> >
> > The micro is running at 50-mips, but still it's not clear if
using a
> > counter-timer to generate a SPI event every 16.6us is practical.
> >
> > Of course it will work, but perhaps using a "tuned" loop is just
as
> > effective, especially if interrupts are turned off during the
data
> > acquisition.
> > I guess you don't have any interrupt line between SAM7S and A/D so
you
> plan to poll A/D at every 16.6 usec for one sample. IMHO, this
interrupt
> timing is a little bit stressing for SAM7S. You can either use FIQ
for
> this purpose. However, since you don't receive any interrupt from
A/D,
> you can continuously read from A/D using SPI with DMA. You can
adjust
> delays between each transfers, so no interrupt overhead will be
> incurred. You will only need to update DMA chain at every 65535
reading.
>
> Caglar
>
> > In the spirit of brevity I'll end it here.
> >
> > Feel free to offer an opinion on this matter - I'll provide
additional
> > information as necessary.
> >
> > Thanks,
> >
> > Marc
> >
> Caglar,
The crux on the matter is that it's important to maintain a constant
16.6us sampling period, and to not break from the process of sampling
when servicing an UART interrupt or etcetera.
The SAM7S is connectd to an AD7685 is "3-wire" mode and uses the the
SPI select line to control the conversion rate of the A/D.
The first issue is to lock out interrupts during the 16.6ms period
when the SAM7S is acquiring date.
The second issue is how to better control the rate of conversion -
perhpas using a timer to generate the 16.6us sampling pulse as
opposed to "tuning" a for loop.
The third issue is whether to use a SPI port DMA, and if so how it
will interact with the timer that is firing every 16.6us.
Thank you for your reply.
Marc
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkk6XBsACgkQ/nL+S5dojeiG2wCcCn9IcHHlTnRs8gsMvxK5eCJB
> l9gAoLSk90f/D3kEg1ZxCelW55sX8WTR
> =l6kK
> -----END PGP SIGNATURE-----
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> marcradzikowski wrote:
> > Gentlemen,
> >
> > I'm currently using an AT91SAM7S microprocessor to read a 1000-
sample
> > vector from an SAR A/D converter via a SPI port.
> >
> > The samples are taken every 16.6us, which amount to a total time
of
> > 16.6ms.
> >
> > It seems best to use the SPI port DMA feature to move the SPI
data into
> > the internal SRAM.
> >
> > What is most important though is that the micro is able to
maintain a
> > fixed sample period (16.6us) during the data acquisition.
> >
> > Currently a simple loop is "tuned" to create a delay equal to
16.6us,
> > at which point the SPI select line is asserted Hi to start a
conversion.
> >
> > It seems best perhaps to disable interupts and use the SPI port
DMA
> > during the data acquistion because it's absolutely necessary to
avoid
> > interrupting the data acquisition process.
> >
> > Regarding the 16.6us timing - it seems best to control the
conversion
> > rate of the A/D converter in a manner that is as deterministic as
> > practicality will allow.
> >
> > The micro is running at 50-mips, but still it's not clear if
using a
> > counter-timer to generate a SPI event every 16.6us is practical.
> >
> > Of course it will work, but perhaps using a "tuned" loop is just
as
> > effective, especially if interrupts are turned off during the
data
> > acquisition.
> > I guess you don't have any interrupt line between SAM7S and A/D so
you
> plan to poll A/D at every 16.6 usec for one sample. IMHO, this
interrupt
> timing is a little bit stressing for SAM7S. You can either use FIQ
for
> this purpose. However, since you don't receive any interrupt from
A/D,
> you can continuously read from A/D using SPI with DMA. You can
adjust
> delays between each transfers, so no interrupt overhead will be
> incurred. You will only need to update DMA chain at every 65535
reading.
>
> Caglar
>
> > In the spirit of brevity I'll end it here.
> >
> > Feel free to offer an opinion on this matter - I'll provide
additional
> > information as necessary.
> >
> > Thanks,
> >
> > Marc
> >
> Caglar,
The crux on the matter is that it's important to maintain a constant
16.6us sampling period, and to not break from the process of sampling
when servicing an UART interrupt or etcetera.
The SAM7S is connectd to an AD7685 is "3-wire" mode and uses the the
SPI select line to control the conversion rate of the A/D.
The first issue is to lock out interrupts during the 16.6ms period
when the SAM7S is acquiring date.
The second issue is how to better control the rate of conversion -
perhpas using a timer to generate the 16.6us sampling pulse as
opposed to "tuning" a for loop.
The third issue is whether to use a SPI port DMA, and if so how it
will interact with the timer that is firing every 16.6us.
Thank you for your reply.
Marc
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkk6XBsACgkQ/nL+S5dojeiG2wCcCn9IcHHlTnRs8gsMvxK5eCJB
> l9gAoLSk90f/D3kEg1ZxCelW55sX8WTR
> =l6kK
> -----END PGP SIGNATURE-----
>
Reply by ●December 8, 20082008-12-08
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
marcradzikowski wrote:
> --- In A..., Yusuf Caglar AKYUZ wrote:
> marcradzikowski wrote:
[...]
>> Caglar,
>
>> The crux on the matter is that it's important to maintain a constant
>> 16.6us sampling period, and to not break from the process of sampling
>> when servicing an UART interrupt or etcetera.
>
That's where FIQ interrupt is helpful.
>> The SAM7S is connectd to an AD7685 is "3-wire" mode and uses the the
>> SPI select line to control the conversion rate of the A/D.
>
>> The first issue is to lock out interrupts during the 16.6ms period
>> when the SAM7S is acquiring date.
>
IMHO, no need to if you're using dma.
>> The second issue is how to better control the rate of conversion -
>> perhpas using a timer to generate the 16.6us sampling pulse as
>> opposed to "tuning" a for loop.
>
Now I understand...
>> The third issue is whether to use a SPI port DMA, and if so how it
>> will interact with the timer that is firing every 16.6us.
>
Here's what I would do if I were you...
Option 1: Adjust timer to generate a 16.6 usec signal, enable timer
interrupt, and start spi transfer using dma in the interrupt handler.
Mark timer interrupt as fiq so that latency is minimized and do not mask
fiq interrupt in the code so that A/D results never get interrupted by
other interrupt sources(IRQs).
Option 2: Adjust timer to generate a 16.6 usec signal but do not use
interrupt. Instead, continuously read from A/D spi using dma. Adjust
time between at each transfer using SPI delay values in CSRs.
I'm not sure if option 1 is realizabledue to strict timing requirements
and efficient excessive interrupt overhead. Option 2 is hard to
implement(due to sync between timer and spi) but incurs less interrupt
overhead.
Best regards,
Caglar
>> Thank you for your reply.
>
>> Marc
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkk9vqMACgkQ/nL+S5dojei/3wCgixcWgrUXQs9ngyYOGsRJ7J0s
qQwAn29j5QKaUqS2//F5K+6bg3bTiC82
=8SiK
-----END PGP SIGNATURE-----
Hash: SHA1
marcradzikowski wrote:
> --- In A..., Yusuf Caglar AKYUZ wrote:
> marcradzikowski wrote:
[...]
>> Caglar,
>
>> The crux on the matter is that it's important to maintain a constant
>> 16.6us sampling period, and to not break from the process of sampling
>> when servicing an UART interrupt or etcetera.
>
That's where FIQ interrupt is helpful.
>> The SAM7S is connectd to an AD7685 is "3-wire" mode and uses the the
>> SPI select line to control the conversion rate of the A/D.
>
>> The first issue is to lock out interrupts during the 16.6ms period
>> when the SAM7S is acquiring date.
>
IMHO, no need to if you're using dma.
>> The second issue is how to better control the rate of conversion -
>> perhpas using a timer to generate the 16.6us sampling pulse as
>> opposed to "tuning" a for loop.
>
Now I understand...
>> The third issue is whether to use a SPI port DMA, and if so how it
>> will interact with the timer that is firing every 16.6us.
>
Here's what I would do if I were you...
Option 1: Adjust timer to generate a 16.6 usec signal, enable timer
interrupt, and start spi transfer using dma in the interrupt handler.
Mark timer interrupt as fiq so that latency is minimized and do not mask
fiq interrupt in the code so that A/D results never get interrupted by
other interrupt sources(IRQs).
Option 2: Adjust timer to generate a 16.6 usec signal but do not use
interrupt. Instead, continuously read from A/D spi using dma. Adjust
time between at each transfer using SPI delay values in CSRs.
I'm not sure if option 1 is realizabledue to strict timing requirements
and efficient excessive interrupt overhead. Option 2 is hard to
implement(due to sync between timer and spi) but incurs less interrupt
overhead.
Best regards,
Caglar
>> Thank you for your reply.
>
>> Marc
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkk9vqMACgkQ/nL+S5dojei/3wCgixcWgrUXQs9ngyYOGsRJ7J0s
qQwAn29j5QKaUqS2//F5K+6bg3bTiC82
=8SiK
-----END PGP SIGNATURE-----
Reply by ●February 8, 20092009-02-08
> >
> > marcradzikowski wrote:
> > > Gentlemen,
> > >
> > > I'm currently using an AT91SAM7S microprocessor to read a 1000-
> sample
> > > vector from an SAR A/D converter via a SPI port.
> > >
> > > The samples are taken every 16.6us, which amount to a total time
> of
> > > 16.6ms.
> > >
> > > It seems best to use the SPI port DMA feature to move the SPI
> data into
> > > the internal SRAM.
> > >
> > > What is most important though is that the micro is able to
> maintain a
> > > fixed sample period (16.6us) during the data acquisition.
> > >
> > > Currently a simple loop is "tuned" to create a delay equal to
> 16.6us,
> > > at which point the SPI select line is asserted Hi to start a
> conversion.
> > >
> > > It seems best perhaps to disable interupts and use the SPI port
> DMA
> > > during the data acquistion because it's absolutely necessary to
> avoid
> > > interrupting the data acquisition process.
> > >
> > > Regarding the 16.6us timing - it seems best to control the
> conversion
> > > rate of the A/D converter in a manner that is as deterministic as
> > > practicality will allow.
> > >
> > > The micro is running at 50-mips, but still it's not clear if
> using a
> > > counter-timer to generate a SPI event every 16.6us is practical.
> > >
> > > Of course it will work, but perhaps using a "tuned" loop is just
> as
> > > effective, especially if interrupts are turned off during the
> data
> > > acquisition.
> > >
> >
> > I guess you don't have any interrupt line between SAM7S and A/D so
> you
> > plan to poll A/D at every 16.6 usec for one sample. IMHO, this
> interrupt
> > timing is a little bit stressing for SAM7S. You can either use FIQ
> for
> > this purpose. However, since you don't receive any interrupt from
> A/D,
> > you can continuously read from A/D using SPI with DMA. You can
> adjust
> > delays between each transfers, so no interrupt overhead will be
> > incurred. You will only need to update DMA chain at every 65535
> reading.
> >
> > Caglar
> >
> > > In the spirit of brevity I'll end it here.
> > >
> > > Feel free to offer an opinion on this matter - I'll provide
> additional
> > > information as necessary.
> > >
> > > Thanks,
> > >
> > > Marc
> > >
> > >
> >
> Caglar,
>
> The crux on the matter is that it's important to maintain a constant
> 16.6us sampling period, and to not break from the process of sampling
> when servicing an UART interrupt or etcetera.
>
> The SAM7S is connectd to an AD7685 is "3-wire" mode and uses the the
> SPI select line to control the conversion rate of the A/D.
>
> The first issue is to lock out interrupts during the 16.6ms period
> when the SAM7S is acquiring date.
>
> The second issue is how to better control the rate of conversion -
> perhpas using a timer to generate the 16.6us sampling pulse as
> opposed to "tuning" a for loop.
>
> The third issue is whether to use a SPI port DMA, and if so how it
> will interact with the timer that is firing every 16.6us.
>
> Thank you for your reply.
>
> Marc
Hi Marc,
I have had a similar problem in the past, and what I did which worked
well is insert dummy reads/writes in between the access to the ADC.
You don't have to use the timer, but instead rely on the SPI module to
time the 16.6us between conversions. You need to force the SPI module
to wait a precise time between conversions. If you have an extra chip
select line which you are not using, you can have the SPI module
perform one or more read/writes to that unused chip select in between
reads from your ADC. The delay associated that dummy access can be set
using the baud rate and the number of transferred bits. The baud rate
and number of transferred bits can be set independently of what you
need for the ADC. To do this, you also need to enable the variable
chip select so the DMA can automatically switch between chip selects.
The benefits of this is that now the timing does not depend on the
interrupt latency at all. It is fully deterministic, set by how fast
the intermediate access in the SPI complete; no matter what the
processor may be doing. However, it does require some experimenting
with the scope to get the timing right.
Regards,
Nathan
> > marcradzikowski wrote:
> > > Gentlemen,
> > >
> > > I'm currently using an AT91SAM7S microprocessor to read a 1000-
> sample
> > > vector from an SAR A/D converter via a SPI port.
> > >
> > > The samples are taken every 16.6us, which amount to a total time
> of
> > > 16.6ms.
> > >
> > > It seems best to use the SPI port DMA feature to move the SPI
> data into
> > > the internal SRAM.
> > >
> > > What is most important though is that the micro is able to
> maintain a
> > > fixed sample period (16.6us) during the data acquisition.
> > >
> > > Currently a simple loop is "tuned" to create a delay equal to
> 16.6us,
> > > at which point the SPI select line is asserted Hi to start a
> conversion.
> > >
> > > It seems best perhaps to disable interupts and use the SPI port
> DMA
> > > during the data acquistion because it's absolutely necessary to
> avoid
> > > interrupting the data acquisition process.
> > >
> > > Regarding the 16.6us timing - it seems best to control the
> conversion
> > > rate of the A/D converter in a manner that is as deterministic as
> > > practicality will allow.
> > >
> > > The micro is running at 50-mips, but still it's not clear if
> using a
> > > counter-timer to generate a SPI event every 16.6us is practical.
> > >
> > > Of course it will work, but perhaps using a "tuned" loop is just
> as
> > > effective, especially if interrupts are turned off during the
> data
> > > acquisition.
> > >
> >
> > I guess you don't have any interrupt line between SAM7S and A/D so
> you
> > plan to poll A/D at every 16.6 usec for one sample. IMHO, this
> interrupt
> > timing is a little bit stressing for SAM7S. You can either use FIQ
> for
> > this purpose. However, since you don't receive any interrupt from
> A/D,
> > you can continuously read from A/D using SPI with DMA. You can
> adjust
> > delays between each transfers, so no interrupt overhead will be
> > incurred. You will only need to update DMA chain at every 65535
> reading.
> >
> > Caglar
> >
> > > In the spirit of brevity I'll end it here.
> > >
> > > Feel free to offer an opinion on this matter - I'll provide
> additional
> > > information as necessary.
> > >
> > > Thanks,
> > >
> > > Marc
> > >
> > >
> >
> Caglar,
>
> The crux on the matter is that it's important to maintain a constant
> 16.6us sampling period, and to not break from the process of sampling
> when servicing an UART interrupt or etcetera.
>
> The SAM7S is connectd to an AD7685 is "3-wire" mode and uses the the
> SPI select line to control the conversion rate of the A/D.
>
> The first issue is to lock out interrupts during the 16.6ms period
> when the SAM7S is acquiring date.
>
> The second issue is how to better control the rate of conversion -
> perhpas using a timer to generate the 16.6us sampling pulse as
> opposed to "tuning" a for loop.
>
> The third issue is whether to use a SPI port DMA, and if so how it
> will interact with the timer that is firing every 16.6us.
>
> Thank you for your reply.
>
> Marc
Hi Marc,
I have had a similar problem in the past, and what I did which worked
well is insert dummy reads/writes in between the access to the ADC.
You don't have to use the timer, but instead rely on the SPI module to
time the 16.6us between conversions. You need to force the SPI module
to wait a precise time between conversions. If you have an extra chip
select line which you are not using, you can have the SPI module
perform one or more read/writes to that unused chip select in between
reads from your ADC. The delay associated that dummy access can be set
using the baud rate and the number of transferred bits. The baud rate
and number of transferred bits can be set independently of what you
need for the ADC. To do this, you also need to enable the variable
chip select so the DMA can automatically switch between chip selects.
The benefits of this is that now the timing does not depend on the
interrupt latency at all. It is fully deterministic, set by how fast
the intermediate access in the SPI complete; no matter what the
processor may be doing. However, it does require some experimenting
with the scope to get the timing right.
Regards,
Nathan
