> "Jim Granville" <no.spam@designtools.maps.co.nz> skrev i meddelandet
>>If that is 3MSPS, two ways, you are a long way from ever meeting that
>>SW bit banging. Even a SSC at 48MHz will need care, to keep the frame
>>overhead low. Use a cheap CPLD to wrap the details, and it will pay
>>for itself in saved cabling.
>>
>>-jg
>>
>
> I think you can run the SSC at 48 MHz and this has
> double buffered DMA support, so you should support 3 Msample/s in each
> direction
> using an I2S interface.
> If your ADC/DAC use a parallel bus, then you can add that CPLD
> or you can consider the AT91SAM9263, which has a second 16 bit
> databus and Dual memory to memory DMA support allowing you to easily meet
> bandwidth needs.
> The DMA can read/write to bus and to internal 16 kB SDRAM without
> cycle stealing from the CPU, since it is on the AHB bus matrix.
I was thinking the SSC had a frame overhead simlar to SPI, but
I see you can configure it many ways, and so use all clocks for data
slots, which means there is effectvely no 'frame overhead'.
I see SSC and CPLD as natural companions, for expansing these larger uC
like Arm9, Avr32 etc,
Depending on the ADC/DAC details, the OP may be able to MUX the IO dirn,
and so save pins on the CPLD.
-jg
Reply by Ulf Samuelsson●March 21, 20072007-03-21
"Jim Granville" <no.spam@designtools.maps.co.nz> skrev i meddelandet
news:4601b6da$1@clear.net.nz...
> aniloyo2@hiwaay.net wrote:
>
>> On Mar 20, 4:01 pm, "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote:
>>
>>>What is the ADC sample rate and resolution?`
>>>What is the DAC sample rate and resolution?
>>
>>
>> 3 MHz, 16 bit ADC
>> 3 MHz, 14 bit DAC
>>
>>
>>>Then think SSC which can run at Master Clock (96 Mhz) / 2 = 48 MHz.
>>>With a 16 bit ADC/DAC, you can get 3 MSamples/s in both directions.
>>>With an 8 bit ADC you get 6 Msamples/s in both directions.
>>>
>>
>>
>> I'm beginning to think the I2S bus may be the way to go if we can't
>> make it work fast enough with bit-banging. It would require some more
>> hardware work though.
>
> If that is 3MSPS, two ways, you are a long way from ever meeting that
> SW bit banging. Even a SSC at 48MHz will need care, to keep the frame
> overhead low. Use a cheap CPLD to wrap the details, and it will pay
> for itself in saved cabling.
>
> -jg
>
I think you can run the SSC at 48 MHz and this has
double buffered DMA support, so you should support 3 Msample/s in each
direction
using an I2S interface.
If your ADC/DAC use a parallel bus, then you can add that CPLD
or you can consider the AT91SAM9263, which has a second 16 bit
databus and Dual memory to memory DMA support allowing you to easily meet
bandwidth needs.
The DMA can read/write to bus and to internal 16 kB SDRAM without
cycle stealing from the CPU, since it is on the AHB bus matrix.
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
Reply by Jim Granville●March 21, 20072007-03-21
aniloyo2@hiwaay.net wrote:
> On Mar 20, 4:01 pm, "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote:
>
>>What is the ADC sample rate and resolution?`
>>What is the DAC sample rate and resolution?
>
>
> 3 MHz, 16 bit ADC
> 3 MHz, 14 bit DAC
>
>
>>Then think SSC which can run at Master Clock (96 Mhz) / 2 = 48 MHz.
>>With a 16 bit ADC/DAC, you can get 3 MSamples/s in both directions.
>>With an 8 bit ADC you get 6 Msamples/s in both directions.
>>
>
>
> I'm beginning to think the I2S bus may be the way to go if we can't
> make it work fast enough with bit-banging. It would require some more
> hardware work though.
If that is 3MSPS, two ways, you are a long way from ever meeting that
SW bit banging. Even a SSC at 48MHz will need care, to keep the frame
overhead low. Use a cheap CPLD to wrap the details, and it will pay
for itself in saved cabling.
-jg
Reply by ●March 21, 20072007-03-21
On Mar 20, 4:01 pm, "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote:
> What is the ADC sample rate and resolution?`
> What is the DAC sample rate and resolution?
3 MHz, 16 bit ADC
3 MHz, 14 bit DAC
>
> Then think SSC which can run at Master Clock (96 Mhz) / 2 = 48 MHz.
> With a 16 bit ADC/DAC, you can get 3 MSamples/s in both directions.
> With an 8 bit ADC you get 6 Msamples/s in both directions.
>
I'm beginning to think the I2S bus may be the way to go if we can't
make it work fast enough with bit-banging. It would require some more
hardware work though.
- ani loyo
Reply by Jim Granville●March 20, 20072007-03-20
aniloyo2@hiwaay.net wrote:
> On Mar 20, 12:14 am, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>
>>if that does not 'fit', use a CPLD as the IO conditioner.
>>- better all round use of resources...
>
>
> I agree, a CPLD or similar device would be better for high-speed
> jitter-less data transfers; however, I'm seeing pretty long timings
> when accessing the GPIOs on the ARM that concern me regardless of the
> source/destination of the signal. Right now it's a struggle to get to
> 3 MHz or so at a processor clock of 192 MHz, and I'm running with
> interrupts off and in a tight loop.
>
> After doing some more research, I think the problem may be the
> internal busses in the ARM architecture, which buffer any general I/O
> that's not part of a built-in peripheral. Still don't know for sure
> though.
I think that's the way of the world: when you take a device that
is a microprocessor (not a microcontroller), and try for hard real time
under 1us, you find yourself in 'PC' territory.
Take a CPLD like ATF1502BE, and it should do 16 bit SPI/SSC duplex,
so you can read a ADC result, and send a DAC in the same 16 clocks,
and use the clock generators to set the rate, which will not
all turn to custard, when you enable interrupts....
> On Mar 20, 12:16 pm, "linnix" <m...@linnix.info-for.us> wrote:
>
>>> You are better off with 2 16 bits uni-directional bus.
>
>
> Unfortunately I can only use 1 16-bit bus due to other peripherals;
> it's theoretically possible to put the ADC and DAC on the actual
> memory bus of the development kit (AT91SAM9261-EK), but it would be a
> lot more difficult for the fellow making the ADC and DAC boards.
you really don't want to run the processor databus any further than
you have to....
-jg
Reply by Ulf Samuelsson●March 20, 20072007-03-20
<aniloyo2@hiwaay.net> skrev i meddelandet
news:1174362715.047795.199510@e1g2000hsg.googlegroups.com...
> Hi, does anyone know how fast an ARM processor, specifically Atmel's
> AT91SAM9261 can bit-bang its general-purpose ports?
> I'm trying to get speeds on the order of 3-6 MHz at a minimum. The
> idea is to write to a DAC, turn the direction of the 16-bit "bus"
> around, read from an ADC, and repeat.
>
Did you configure the SRAM to exist on the Tightly Coupled Memory Bus?
This is mandatory to get highest performance.
I think it would be much better if you answered a few questions.
What is the ADC sample rate and resolution?`
What is the DAC sample rate and resolution?
Then think SSC which can run at Master Clock (96 Mhz) / 2 = 48 MHz.
With a 16 bit ADC/DAC, you can get 3 MSamples/s in both directions.
With an 8 bit ADC you get 6 Msamples/s in both directions.
You can also step up to the AT91SAM9263 which has an extra
16 bit bus and a DMA controller allowing you to do scather/gather
to ADC without affecting the CPU operation since it lives on the other bus.
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
Reply by Eric●March 20, 20072007-03-20
On Mar 20, 3:00 pm, anilo...@hiwaay.net wrote:
> After doing some more research, I think the problem may be the
> internal busses in the ARM architecture, which buffer any general I/O
> that's not part of a built-in peripheral.
That's a general problem with Arm 7s, where it can be difficult to get
more than 3 or 4 mhz from bit-banging. The NXP chips have a special
bus arrangement that can take you up to 15 mhz.
But I don't have any experience with Arm 9's.
Eric
Reply by linnix●March 20, 20072007-03-20
On Mar 20, 11:00 am, anilo...@hiwaay.net wrote:
> On Mar 20, 12:14 am, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>
> > if that does not 'fit', use a CPLD as the IO conditioner.
> > - better all round use of resources...
>
> I agree, a CPLD or similar device would be better for high-speed
> jitter-less data transfers; however, I'm seeing pretty long timings
> when accessing the GPIOs on the ARM that concern me regardless of the
> source/destination of the signal. Right now it's a struggle to get to
> 3 MHz or so at a processor clock of 192 MHz, and I'm running with
> interrupts off and in a tight loop.
I think your problem is with the directional switching.
I am doing several MHz bitbanging on a 20MHz clock.
>
> After doing some more research, I think the problem may be the
> internal busses in the ARM architecture, which buffer any general I/O
> that's not part of a built-in peripheral. Still don't know for sure
> though.
>
> On Mar 20, 12:16 pm, "linnix" <m...@linnix.info-for.us> wrote:
>
> > You are better off with 2 16 bits uni-directional bus.
>
> Unfortunately I can only use 1 16-bit bus due to other peripherals;
> it's theoretically possible to put the ADC and DAC on the actual
> memory bus of the development kit (AT91SAM9261-EK), but it would be a
> lot more difficult for the fellow making the ADC and DAC boards.
>
> -ani loyo
The chip has 217 balls, I am sure you can get enough I/O pins.
You might have to share pins with other peripherals,
or multiplex the bus.
Are you using 16 bits multi MSPS converters?
What are the speeds and resolutions?
Reply by ●March 20, 20072007-03-20
On Mar 20, 12:14 am, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> if that does not 'fit', use a CPLD as the IO conditioner.
> - better all round use of resources...
I agree, a CPLD or similar device would be better for high-speed
jitter-less data transfers; however, I'm seeing pretty long timings
when accessing the GPIOs on the ARM that concern me regardless of the
source/destination of the signal. Right now it's a struggle to get to
3 MHz or so at a processor clock of 192 MHz, and I'm running with
interrupts off and in a tight loop.
After doing some more research, I think the problem may be the
internal busses in the ARM architecture, which buffer any general I/O
that's not part of a built-in peripheral. Still don't know for sure
though.
On Mar 20, 12:16 pm, "linnix" <m...@linnix.info-for.us> wrote:
> You are better off with 2 16 bits uni-directional bus.
Unfortunately I can only use 1 16-bit bus due to other peripherals;
it's theoretically possible to put the ADC and DAC on the actual
memory bus of the development kit (AT91SAM9261-EK), but it would be a
lot more difficult for the fellow making the ADC and DAC boards.
-ani loyo
Reply by linnix●March 20, 20072007-03-20
On Mar 19, 7:51 pm, anilo...@hiwaay.net wrote:
> Hi, does anyone know how fast an ARM processor, specifically Atmel's
> AT91SAM9261 can bit-bang its general-purpose ports?
> I'm trying to get speeds on the order of 3-6 MHz at a minimum. The
> idea is to write to a DAC, turn the direction of the 16-bit "bus"
> around, read from an ADC, and repeat.
>
> Thanks!
With a 6 MSPS ADC?
You are better off with 2 16 bits uni-directional bus.