kdumont

Members
  • Content Count

    11
  • Joined

  • Last visited

  1. Hi, Can you provide the part number for the main 30-pin RA header you are using on the AD2? I'm designing a breakout board with a few extra functions that plugs in and I want to make sure I have the correct specs. It looks like flash gold plating, ~7.5mm insertion length, 100mil pitch.
  2. Couple bugs: - The documentation says "DwfDigitalI2cWriteRead," but should be "FDwfDigitalI2cWriteRead" - The examples use "FDwfDigitalI2cFrequencySet" and "FDwfDigitalI2cTransfer" but should be "FDwfDigitalI2cRateSet" and "FDwfDigitalI2cWriteRead" Other than that it works magically so far.
  3. That's great news! In that case I will wait patiently.
  4. I'm writing an I2C interface in python in order to get a real-time stream from a peripheral device and do some additional processing. I have been able to get everything set up such that my peripheral ACKs my request. However, I'm curious for what your strategy is for handling the next packet depending on ACK/NACK. Originally I was just using a digital read at the start of the transmit (Start + Address) and processing the response to detect ACK, then setting up the device for the next transmit (data). However, the USB back/forth is way too slow, so I'm assuming you set everything up
  5. @attila Yeah, I saw that as well. I'm not sure if this is a common behavior or not, but this is what they call out in the spec and confirmed by their FAEs. It would certainly help me out to have that option. ~Kyle
  6. @attila thanks for pointing that out. I was mistaken. Still, it looks like the device I'm working with does require an ACK even after the final byte (this is because the transfer length is always the same - 3bytes). Is there any way we could get an option to modify this in Waveforms? It's a TI device, so this is a surprising behavior. I'm working with them to see if we can change it on the device in the future. However, in the meantime this would be helpful. ~Kyle
  7. I'm using Waveforms with the AD2 device to do some I2C debug. I'm running into an issue where my slave device hangs because the AD2 master doesn't ACK the final data transmission before sending the STOP signal. I believe it is supposed to per the I2C spec.
  8. Thanks @JColvin and @attila for quick responses. I wasn't aware that I can toggle individual IO states independently of the PWM. Unfortunately, my driver is a 38kHz signal. I might still be able to bit-bang that with a delay loop, but it's not ideal. I ended up using the AWG to set my bias current and then kept my driver as a PWM output with 1ms DigitalRun set. The only issue I have is that I might need more than two channels in the future, which is why I went with PWM in the first place. Also, I need very low voltage (down to 10mV), so I have some concern about accuracy. Still, it is qu
  9. I've found that the digital IOs hang for a small, but undetermined amount of time when the FDwfDigitalOutConfigure command is sent. In the attached picture it is 280us. This is a huge issue for my project at the moment. I have one channel driving a PWM signal to set a bias current. I want to wait for that to stabilize and then use another channel to drive another output. Unfortunately, when I send the FDwfDigitalOutConfigure(hdwf, True) command, the PWM output hangs in its previous state and wrecks havoc on my bias setpoint (see below). This would be a little more manageable if it was a d
  10. There appears to be a mistake in the WaveForms SDK Reference Manual supplied with the SDK. The document says: But the function actually requires the idxChannel AND idxNode, like this: I'm running the following code segment to get the different node options: num_channels = c_int() dwf.FDwfAnalogIOChannelCount(hdwf, byref(num_channels)) print(num_channels.value, "channels") for i in range(0, num_channels.value): print("Channel", i) channel_name = create_string_buffer(32) channel_label = create_string_buffer(16) dwf.FDwfAnalogIOChannelName(hdwf, c_int(i),