Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

faster sample rate 8451

Hi

I am trying to enquire data from an FPGA based system (Altera DE2) with SPI protocol.

I try to use the NI 8451, but it looks like the data rate I'm getting is too slow.

 

When reviewing the data sheet I came across the timing diagram of the device and figured out there is a lot of "dead time" in which i do not get any data from the device (for example  SCLK setup time).

Is there any way to shorten these timing parameters using advanced API?

Is there any way I could reach 1.5MBps?

 

I am using labview 8.6/9 on windows 7

my FPGA system is Altera DE2 - Cyclone II.

 

 

 

 

0 Kudos
Message 1 of 14
(6,047 Views)

Hello s.ruppin,

 

As the maximum clock rate for SPI communication is 12 MHz, the upper limit for your communication is 1.5 MB/s.  That is the very upper limit and you will want to make sure your program is as streamlined as possible.  What programming environment are you using?  

 

From your post, it sounds like you are just trying to shorten initilization time.  Can you give us a few more details on how you've setup your programming? (ex. initilization step»Read/Write @ x.x rate»some period of time later, close references/stop communication.)  From this we might be able to offer you some suggestions on how to best optimize your code.  

ColeR
Field Engineer
0 Kudos
Message 2 of 14
(6,027 Views)

Hi ColeR, thanks for your reply.

In the spi protocol the initialization needs to be performed every "read cycle" so the initialization time becomes a very dominant issue.

the 12MHZ clock refers only to the SCLK of the 8451 that is active only after the CS goes from high to low and after a long waiting time. In addition, the SCLK "goes to sleep" for a minimum of 8.5 us every 8 SCLK cycles.

 

I  am attaching the timing diagram of the 8451 and my main loop of the reading process

basicaly I used the example of "SPI read data from an Atmel AT25080A" under examples>>hardware input an output>>I2C and SPI>>SPI basic>>Atmel AT25080A read.vi

 

The main question is if there is any way shorten t1,t2,t3 and t4

 

I thak you again

 

timing diagram

0 Kudos
Message 3 of 14
(6,013 Views)

 

Please, I am also interested in lowering the setup times, as I need to communicate 7 channels within 1 ms.

This gets rather tricky, using the ready made VI drivers in LabVIEW (Windows).

 

 

Best regards,

HKH

 

--
Best regards,
HKH
0 Kudos
Message 4 of 14
(5,555 Views)

Hi HKH,

 

The best method for cutting out unnecessary time will be to optimize your code to make sure you don't have any (or very little) wasted time. Are you working with a particular instrument driver? Also, have you tried and been unable to get the speeds you need? How has your performance been?

 

John M

National Instruments
Applications Engineer
0 Kudos
Message 5 of 14
(5,530 Views)

Dear John,

 

 

I certainly need to optimize my code.

 

Right now, I have 8 channels updating good within 2 ms, but I still need to get within 1 ms for the 8 channels.

 

Updating is possible every 4 ms, I expect that the relatively huge delay of 2 ms is the closing and set up of the SPI script, which should be possible to optimize - I just didn't find the trick, as the script can only hold a limited amount of sample values (I think around 64 x 16 bit samples).

 

Please see attached oscilloscope pictures, showing my actual timing.

 

Yellow is CLK.

Purple is Data.

Blue is CS0.

 

I can PM the block diagram.

 

 

Best regards,

HKH

--
Best regards,
HKH
Download All
0 Kudos
Message 6 of 14
(5,280 Views)

HKN,

 

You can PM the block diagram to me and I'll take a look at it. John is on vacation this week.

National Instruments
0 Kudos
Message 7 of 14
(5,243 Views)

Dear Biel,

 

 

Thank you for your response.

I just PM'ed you the block diagram.

 

 

 

HKH

--
Best regards,
HKH
0 Kudos
Message 8 of 14
(5,228 Views)

HKN

 

I would recommend moving the script creation steps out of the loop. Your performance is being limited by the overhead of creating the script during each iteration of the loop. Move step 1 and 2 where you setup and configure the scripts outside the loop, then keep all of those scripts in memory. Step 3 where you run the scripts should be the only piece of code that is in the loop. If this setup is too memory intensive, then you may consider a producer/consumer architecture.

National Instruments
0 Kudos
Message 9 of 14
(5,197 Views)

 


I would recommend moving the script creation steps out of the loop.

 

I have way too much data, therefore this requires either:

 

1/ qeueing of scripts

or

2/ possibility to flush or overwrite the active script

 

Queues won't accept data of type script.

And I do not know how to flush or reset data pointer to overwrite script data.

I can see, in the manual, that there is a C function for it [int32 ni845xSpiScriptReset (uInt32 ScriptHandle);] but I can not find out how to carry this out in LabVIEW.

 

Could anyone help me out with some hints?

 

 

Best regards,

HKH

--
Best regards,
HKH
0 Kudos
Message 10 of 14
(5,001 Views)