Bit bang speed on AT91SAM9261 ARM processor

and jitter ? best is to try an use the peripherals ( SPI / SSC ? ), and if that does not 'fit', use a CPLD as the IO conditioner.

- better all round use of resources...

-jg

With a 6 MSPS ADC? You are better off with 2 16 bits uni-directional bus.

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 do> 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

I think your problem is with the directional switching. I am doing several MHz bitbanging on a 20MHz clock.

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?

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

skrev i meddelandet news: snipped-for-privacy@e1g2000hsg.googlegroups.com...

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

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....

you really don't want to run the processor databus any further than you have to....

-jg

3 MHz, 16 bit ADC 3 MHz, 14 bit DAC

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

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

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