Ionut

Digilent Staff
  • Content Count

    20
  • Joined

  • Last visited

  • Days Won

    1

Ionut last won the day on November 21 2018

Ionut had the most liked content!

About Ionut

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi kenken, If you look at your screenshot, from left to right: - The first circled item is the initial value for DIO14 and DIO15 (F = false = logic 0); you can leave it the way it is; - The second circled item is a flat sequence with a delay time inside; the value of the delay time is given by a local variable called "Pretrigger time (ms)", which takes its value from the front panel control with the same name. This delay is necessary so that the oscilloscope input has time to acquire the samples corresponding to the pretrigger time (i.e. the time before the rising edge that you trigger on). You can leave this the way it is too. However, you can change the value of the front panel control called "Pretrigger time (ms)", to adjust the position of the pulse on your front panel waveform. - The third item is the high value of the pulse on DIO14 and DIO15 (T = true = logic 1); you can leave it the way it is; - The fourth item is a delay corresponding to the pulse duration, in ms. Now it is 1ms, but you can change it to other values as well. - The fifth item is the final value of the pulse (F = false = logic 0). You should leave this too the way it is. Best Regards!
  2. Hi kenken, In order to wait for 20ms between reading the waveform and displaying it in the VI, you can simply add a "Wait (ms)" LabVIEW function with 20ms at its input, inside a flat sequence structure, on the wire going to the Waveform Graph. I did this in the attached VI. Also, in your VI the pretrigger time was too large (500ms, when the entire acquisition time was 500ms); there was no way to see the pulse with that pretrigger time setting. Finally, before generating the 1ms pulse, you need to wait for the pretrigger time to elapse, so that Analog Discovery can read the corresponding pretrigger samples. I fixed this in the attached VI, and set the pretrigger time to 100ms; any setting smaller than the acquisition time should work. Best Regards! 1202_1_edited.vi
  3. Hi kenken, I'm not sure I understand your problem. Do you want to wait for 20ms between reading the waveform and displaying it in the VI? Or do you want to acquire data using the oscilloscope input 20ms after the pulse has been generated? The case where the pulse wave is not displayed on the oscilloscope refers to the triggering problem I mentioned in my previous post. I contacted a colleague bout this, and hopefully we will have a solution soon. I have another question: which of the two attached VIs did you use: 1202_1.vi or 1202_2.vi? Best Regards!
  4. Hi kenken, I'm sorry for the delay in answering you. Generating a pulse using the digital outputs would look like in the upper part of the attached VI (see comments in the VI block diagram for details). However, using this method you would not be able to control the width of the pulse very accurately, as this is controlled by software. A desired 1ms pulse width could end up being 0.5ms or 2ms in reality. Because of this, I recommend using the method described in my previous post above (Using Waveforms SDK and LabVIEW, for example), for which the timing is controlled by hardware, and it is therefore more accurate. Please note that for the VI attached to this post, there is also another problem: triggering on the oscilloscope input channels does not work when looping back the digital output channels to them. If you are happy with the software-controlled timing offered by this VI, I will contact one of my colleagues to further debug the triggering issue. Best Regards! 1127_edited.vi
  5. Hi kenken, Please look at the attached LV_with_Waveforms_SDK.zip. It contains the following items: - A version of the Digilent Waveforms library I imported into LabVIEW 2015 ("DwfLibrary" folder); - A LabVIEW 2015 test project with contains this library, together with a test VI in which I started adding the functions indicated in the AnalogOut_Pulse.py source code; - The AnalogOut_Pulse.py file; - The WaveForms SDK Reference Manual.pdf manual. To complete your project, you would need to continue to add functions to the Test VI, as indicated by the AnalogOut_Pulse.py source code. You can open the Python source code with any text editor. For extra information on the needed parameters, please follow the WaveForms SDK Reference Manual.pdf. Best Regards! LV_with_Waveforms_SDK.zip
  6. Hi kenken, If I understood correctly, you would like to generate a single 5V pulse? What length would that have? 1ms? In any case, the digital outputs on the Analog Discovery 2 can only generate up to 3.3V output, so they would not work for your intended use case. You can use instead one of the Waveform generator outputs to generate the pulse. However, the Digilent Waveforms VIs you are currently using do not provide the ability to reliably generate a single digital pulse. This functionality does exist in the Waveforms SDK, which is a library installed together with the Waveforms software. I've attached to this answer a Python example showing how to generate a pulse (AnalogOut_Pulse.py) using Waveforms SDK. If you would like to use LabVIEW instead of Python, you could import the Waveforms SDK library (called dwf.dll and found in the Windows\system32 folder) into LabVIEW (here is how: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Ls1SAE&l=en-US) and re-implement the attached Python script in LabVIEW. Please let me know if you have any other questions. Best Regards! AnalogOut_Pulse.py
  7. Hi Duncan, From your description, it seems the "bad" start condition is recognized for some transactions, but not for others. It most likely is marginal all the time, and sometimes the ADV7611 recognizes it correctly, on other times it doesn't. But it is weird that the problem only occurs when using the FMC interface pins, but not the Pmod pins. It would be interesting to compare the FPGA implementation results between the version using FMC for the I2C lines vs. the one using the Pmod pins: - Are the two internal circuits the same (I/O buffers, gates, flip-flops)? - Are the output flip-flop to FPGA pin delays relatively the same between the two implementations? Also, it would be worth checking, if possible, if there are any significant routing delays on the FPGA board, between the FPGA-to-FMC I2C pins and the FPGA-to-Pmod I2C pins. Best Regards!
  8. Hi Duncan, I'm sorry for the delay in answering you. Yes, you get the Acknowledge from the slave device, but only for the prior transaction(s), for example for the 0xFD byte. For the 0x99 byte, you do not get the Acknowledge anymore. So I would ask the question: do you see a "bad" start condition (like the one from your picture for byte 0x99) for other bytes, before the 0x99 byte? Or is the "bad" start condition only appearing in that one isolated case? Best Regards!
  9. Hi kenken, Thank you for sending the VI! I managed to run your VI and ended up at the following conclusions: 1. In your oscilloscope settings, you were setting the vertical range to only 1V, too small to see the entire signal you were generating. Once I set it to a value larger than the peak-to-peak level of your signal (at 5V amplitude, peak-to-peak would be 10V, so I set the vertical range to 20V), the correct signal level appeared. 2. The default buffer size for the oscilloscope input channels which is provided by Analog Discovery 2 is 8192 samples/channel (please see https://reference.digilentinc.com/reference/instrumentation/analog-discovery-2/reference-manual?redirect=1#refnotes:1:note15 for details). At your set sampling rate of 20kSamples/s, this means only 409.6ms, which you obtained. Once I lowered the sampling rate to 10kSamples/s, I managed to see the 500ms you wanted. 3. However, I could not reproduce the spikes on the waveform which you showed in your capture above. Every time I ran the VI, the waveform looks rectangular. Please make sure you connect both terminals of oscilloscope channel 1: the "+" needs to connect to Waveform Generator 1 terminal, while the "-" needs to connect to GND. I've attached the updated VI here, together with some comments next to where I made the updates. Please let me know if you encounter any other issues. Best Regards! function2.vi
  10. Hello, From the waveform you attached, it seems you are issuing a stop command after the first byte (which is 0xFD), and then you attempt a start command before the second byte (which is 0x99). However, it seems to me that the SDA low pulse during the respective start command is too short, and the corresponding SCL rising edge comes rather late. Therefore, the start condition may not be properly interpreted by the ADV7611. Please see the attached picture for more info (I edited the picture you attached). I think you should try to correct the Start condition generation, and then try to communicate with the ADV7611 again. Please let me know if you still see issues afterwards. Best Regards!
  11. Hi kenken, Would it be possible for you to attach the actual file you are showing in the screenshots (function[...].vi) to this thread? Thank you.
  12. Hi kenken, Could you send me the LabVIEW VI you are using (which you have shown in the screenshots)? Thank you!
  13. You're welcome! I am glad it is working. Yes, this thread should help others trying to run the Pcam 5C demo on Zybo Z7. Best Regards, Ionut.
  14. Hello, You only have the hardware platform in SDK. You need to import the other projects from the SDK folder (fsbl, fsbl_bsp, pcam_vdma_hdmi and pcam_vdma_hdmi_bsp) into SDK, by selecting File -> Import -> General -> Existing Projects into Workspace -> Next -> Select Root Directory as \Zybo-Z7-20-pcam-5c-master\sdk -> Select the above-mentioned projects -> Finish. Then follow steps 3 through 5 from the above post. Best Regards, Ionut.
  15. Hello, The debug module for the CSI-2 IP is only used for HW debugging inside the IP itself, it is not used for setting up parameters like camera resolution. For these parameters, the AXI-Lite interface is used instead. So the messages in the UART terminal should appear regardless of the IP Debug settings. After the bitstream is generated by Vivado, please make sure you do the following: 1. Export the hardware (File -> Export -> Export Hardware -> Include bitstream) to the \Zybo-Z7-20-pcam-5c-master\hw_handoff folder, overwriting the existing file. 2. Launch SDK from Vivado (File -> Launch SDK), setting up the Exported location to \Zybo-Z7-20-pcam-5c-master\hw_handoff and the Workspace to \Zybo-Z7-20-pcam-5c-master\sdk. 3. Left click on the pcam_vdma_hdmi project and then from the top menu select Project -> Build Automatically. 4. Re-generate BSP sources for fsbl_bsp and for pcam_vdma_hdmi_bsp, by right clicking on each of these projects and selecting Re-generate BSP Sources. 5. Left click on the pcam_vdma_hdmi project. From the top icons, select Program FPGA. Then, from the top menu, select Run -> Run -> Launch on Hardware (System Debugger). The Pcam 5C demo project should then work fine. Please let me know if you encounter any issues with this. Best Regards, Ionut.