• Content Count

  • 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 in advance in Waveforms I2C to trigger on an ACK. I tried a few methods of setting the output to trigger from I/O states, but I haven't been able to get it to work quite right (is there a way to force a trigger?). Can you briefly explain the general flow for how you set the AD2 up to handle I2C as master in Waveforms? Thanks, Kyle
  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 quite impressive that the unit is so adaptable to have another solution like this. Still, I would like to voice my opinion that reducing the pin delay could be a big improvement for a future product revision. Additionally, if there is any way the pins can be configured to high-impedance before they are hung up (via a firmware patch) that could be a big win. Please let me know if there is anything I can do to help here. With the FDwfDigitalIOOutputSet command, can I use that on a channel enabled for PWM? That is, can I set a PWM and then use the FDwfDigitalIOOutputSet command to mix it? Basically, I want a 38kHz carrier signal to send arbitrary opcodes for IR transmission.
  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 deterministic amount of time and/or if it consistently went to the same state (i.e. low). However, it doesn't seem to be consistent in either case. Is there any way I can mitigate this? I have tried setting the idle state to hi-z, but it doesn't help here. Of course, I can increase the time constant on my PWM low-pass, but I would really like to avoid that. What causes this? I assume the FPGA states are being reset during this time. Ideally there would be no delay at all. However, if the pin went to hi-z during this case that would be highly preferred...
  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), channel_name, channel_label) print(str(channel_name.value), str(channel_label.value)) num_nodes = c_int() dwf.FDwfAnalogIOChannelInfo(hdwf, c_int(i), byref(num_nodes)) for n in range(0, num_nodes.value): node_name = create_string_buffer(32) node_label = create_string_buffer(16) dwf.FDwfAnalogIOChannelNodeName(hdwf, c_int(i), c_int(n), node_name, node_label) print(" ", str(node_name.value), str(node_label.value))