bit banging with NI-8451

[SergeB]

Hello everyone!

So i have a board that has two 12-bit DAC's (LTC1257) . They are cascaded together with the Dout of one DAC going into the Din of the other. So essentially I need to shift in 24 bits to get my two 12-bit analog output voltages. I have tried using the SPI write script API with some success but there are times where my output voltages make no sense and i think it's because the timing is not always right. Therefore, i want to try some good old fashioned bit-banging on the DIO lines of the NI-8451 and see if that works. The timing requirements for the DAC are attached, which I am trying to mimic with 3 DIO lines. One for the clock, one for the data in to the DAC and one for the LOAD line. However, I am having trouble synchronizing all the signals to get the timing just right. I don't know if i'm limited because of the hardware or if i'm just not doing it the right way.

Attached is my code (LV 2011) and also an jpeg image of my code. I have tried multiple ways but the best I have so far is running 2 loops simultaneously, one loop for the data and clock and the other for firing off my load line (which is not a very accurate way). If I run one signal at a time and check my scope, the signal looks ok, but when i try running 2 or 3 signals at a time, the timing of the signals get all funky on scope, which makes me think it might my hardware that can't keep up. Any advice on how I should approach this would be greatly appreciated!

thanks,

Serge

[beccamir]

SergeB,

When using the API, what do you mean by the voltages not making any sense and the timing not always right? The timing will be much better using the API versus the bit banging. 

[SergeB]

Hi beccamir,

thanks for the response. What I mean is that some units I test with the API give me the right voltages but others units give me random voltages so I thought maybe the registers are sometimes getting populated an extra unwanted bit or vice-versa when they get latched on to the DAC.

Also sometimes, a unit showing the right voltages will all of the sudden, stop showing the right analog output voltage. And then later, it will come back to life again.

Any advice?

-Serge

[SergeB]

So the SPI API only start the bit transfer on each rising on falling edge of the clock. However, if you look at the timing diagram for the DAC on my first post, the bits are being transfered in between the falling edge and the rising edge of the clock. How can I achieve this timing with the hardware I have? Pleas help, thanks!

-Serge

[beccamir]

SergeB,

According to your timing diagram, you are looking for timing on the order of ns. When using the DIO lines, you are working purely with software timing. The DIO lines are designed to work as something like a trigger. They are never under any circumstance meant to be used to pass SPI/I2C. 

It is understandable why you are getting a timing issue if you are trying to get messages and merge together two halves of the voltage value, this is made worse by moving to the DIO ports. 

You would be better off adding some error handling to your code to check for voltage values that make sense and discard them if they don't. You can also look at the basic API and see if you are able to merge the data after collecting it. This would be better because the basic API tends to be more efficient than the scripting API. One thing you can try is using the basic API in a producer conssumer architecture. Here you can acquire the data with the basic API in the producer loop, pass it to the consumer loop, and work to merge data points from there. 

[SergeB]

Hi Beccamir,

Thanks for the response. I will try some of your suggestions, thank you. I just need to think of a way to process the data and verify the digital value before it gets fed into the DAC. 

The nanosecond requirements you mentioned are all minimums so I would think I can slow it down enough for it to be manageable with the DIO? The hard part is getting the timing to stay the way I programmed it because when i'm trying to fire off all 3 DIO lines simultaneously, they are being affected by each others and causing delays.

thanks,

-Serge

[beccamir · Accepted solution]

they're very slowly updated (in the range of 100-150Hz)

and there are jitter considerations on those updates as well