Using DIO in loop to generate TTL

[Jimbo76]

Hi,

I have an sbRio and on the FPGA I have a loop that executes every 5 us. The loop has a counter which increments with every iteration and I acquire analogue data each cycle (effectively setting the rate at 200kS/s). The counter is used to generate a boolean True or False. So, for example, if the counter is less than 200 (say) the value is False, but greater than 200 it's True. The counter then resets back to zero at, say, 400. This counter is then used for two purposes - the resulting T/F value is sent to a DIO port so it becomes, effectively, a TTL output, and since I store the counter with the analogue data, it acts as a reference for where in the TTL cycle the data was sampled.

My problem is that when I examine the 'TTL' output on an oscilloscope it looks pretty ok ... except now and then I get a glitch where it suddenly either drops to zero or 'stutters'.

The question I have is this - if I write a True value to a DIO port within a timed loop, does that value 'latch' until it is altered or does it literally flick on then off within some time period (the implication being that it's actually not a continuous True but a series of True/False steps that happen on a timescale much shorter than my loop time)? If so, is there a way to ensure that the value remains constant until the next loop iteration? If not, then should I move to using ticks rather than us in the loop timer?

Thanks (and sorry for the length)! 

[nathand]

A digital output will hold its value until a new value is written to it.

It might help if you upload your code, highlighting or explaining the problematic section, and if you can also include an image showing one of these glitches.

Do you by any chance have a counter that could roll over? For example, if you have an 8-bit value, when you add 1 to 255 it will reset to 0. This can cause unexpected glitches.

[Jimbo76]

Thanks for replying, Nathand.

I've attached an image of the FPGA vi ... it's pretty simple. The RT Host passes a value for the full and half cycle length of the TTL pulse to the FPGA. So, for example, if the loop executes every 10 us (100,000 samples/sec) then a 100 Hz TTL pulse would be 1000 iterations of the loop. The half cycle length would then be 500, with the full cycle length 1000. The counter simply increments with each loop iteration. If less than 500 it sends a True to the DIO port, if greater than 500 it sends a False. The counter then loops back to zero. Since this counter only ever counts up to a few thousand, there should be no issues with the type of variable. A 16-bit integer is more than capable of handling those numbers!

Although this seems to produce a nice TTL output, there are occasional glitches. I'll have a go at trying to capture one of those glitches, but imagine a TTL square wave that's at the True value. This should be True for, using the example, 5000 us. At some points, though, the value isn't the 3.3V that you'd expect, but it drops to zero or drops somewhere in-between. It's as if the value of that True-valued point was dropping to False, but suddenly went True again by the next point.

Hope that clarifies?! 

[nathand]

I don't see an obvious logic problem with that code.

Can you narrow down the conditions under which you see the glitch? Does it happen when the board is connected to some external device that momentarily draws more current than the board can handle? That would cause a short drop in voltage, and possibly a voltage between 0 and 3.3. Does it happen only when you have just changed the pulse width values? Perhaps there's some situation in which you change the value in the middle of a pulse.

I am assuming that the False case is identical to the True case, except with a False wired to the digital output channel. If so, simplify: remove the case structure entirely and wire the value that's current going to the case selector directly to the digital output.

On a purely aesthetic note, straighten your wires. Removing bends and stair-steps makes it easier for someone else to look at the code and quickly understand what it does.

[Jimbo76 · Accepted solution]

I think the issue is the reading of the half/full cycle values. When I replace those with constants, the problem seems to vanish. I've moved the reading of those outside the main loop and that seems to have worked.

Thanks for your help! The case loop was removed since, as you pointed out, it was unnecessary. Oh, and sorry about the bent wires ...