Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by BogdanVanca

  1. Hello @Kris Persyn, Please try commenting the fallowing line "while (XUartLite_IsReceiveEmpty(BaseAddress))"; from xuartlite_l.c. Best Regards, Bogdan Vanca
  2. Hi @ozden.erdinc, The board files are not a necessity. We only create them to give a more flawless user experience. Yep, you should be fine.
  3. Hello @ozden.erdinc, What board are you referring? From what I know all of our capsules have -1 speed grade. Yours is -2.
  4. Hello @rcjhy8, Yes, it is in Vivado constraints. Go to "Sources" in your Vivado project. Right click and select add sources. Select "Add or create constrains" and click Next. Create your own constraint file in which you add the fallowing two lines: #set_property -dict { PACKAGE_PIN W18 IOSTANDARD LVCMOS33 } [get_ports { jb_p[3] }]; #IO_L22P_T3_34 Sch=JB4_P #set_property PULLUP true [get_ports jb_p[3] ] #set_property -dict { PACKAGE_PIN W19 IOSTANDARD LVCMOS33 } [get_ports { jb_n[3] }]; #IO_L22N_T3_34 Sch=JB4_N #set_property PULLUP true [get_ports jb_n[3]] where jb_n[3], jb_p[3] have to have the names of your signals used into your project.
  5. Hello @rcjhy8, Try to "#set_property PULLUP true" in xdc for both SCL and SDA.
  6. BogdanVanca

    OV7670 and BASYS3

    Hello @trian, You have to write a simple state machine or a process that controls the write enable signal for the frame buffer. You have to pull it down after you successfully transferred a frame image. That's all.
  7. Hello @Sara234, The tutorial also applies for Zynq based designs. There are small drop-down controls that guide you for creating a Zyng block design.
  8. Hello @Sara234, We have a vivado library that includes all of our pmods. You can clone or download the library from here: After you have it, you need to add it to your vivado project repository. Most of the pmods from this library including PMOD DA1 (check in here have drivers for SDK. Before you go trough everything that I presented above, please have a look at our PMODs tutorial This tutorial along with others useful information can be accessed from PMOD DA1 Resource Center page
  9. Hello @shantaramj, The IP has it's own constraints and set-ups that would fail if you reset them in a different Vivado Version. Please use the recommended version of Vivado for this project, go trough syntesys, implementation and generate bitstream. If everything works as expected you can open the project in 2018.2, but please make sure that you don't reset the output products for this ip. If you need although to go trough a reset, please lock the ip before doing that. Best Regards, Bogdan Vanca
  10. Hello @Antonio Fasano, You simply have to activate one ore more I2C interfaces from your PS side and work with it from SDK. Each interface comes with an example project. I would recommend you to go trough the tutorials that are present in this book From PL you can use the AXI2C IP. You can find more support about this ip by accessing the fallowing link:
  11. Hello @Antonio Fasano, Why you are not using the I2C from PS?
  12. Hello, First, As you may think you have to write your own UART vhdl/verilog module, with an RS323 interface. After you make sure that it works correctly, you have to add to your code and axi lite interface. There are two ways for doing that: 1. You add it by your own, and keep your code as a module. 2. Package your module as an custom ip and use the template given by Xilinx. Personally, I will probably go with the second option. And that is because, the template is clearly written and commented. Inside this template there is a state machine that gives you access to a couple of registers.Trough these registers you can pass data from PL to PS side. After you have your own IP, you can add it into a block design and connect it trough the AXI Interconnect. On this stage your IP will have it's own address into the address editor. With that, you can access trough the lite interface each individual register. Best Regards, Bogdan Vanca
  13. Hi @giamico, This happens when you lose the connection with the Board. Please try on with a different USB cable.
  14. Hello @rcjhy8, Each pmod pin can be individually controlled by using the axi gpio core. This core provides a general purpose input/output interface to the AXI Interface. Trough the AXI interface you can easily control the state of your led. If you want a dynamic control, you have to implement a command parser on a serial terminal, such as putty or teraterm. Best Regards, Bogdan Vanca
  15. Hello @Tejna, Please try running the fallowing tcl command: set_property IS_LOCKED false [get_files "your xci files for the PWM ip".xci]. After that, try to reset output products and generate output products. Best Regards, Bogdan Vanca
  16. Hello @Tejna, First, you have to reset output products for your block design. After that, you have to generate output products. You need to go to your source window, right click on block design, select output products, and generate output products. Best Regards, Bogdan Vanca
  17. Hello @bitslip, Yes, you are correct. Theoretically you can rescale the image at any size, even at 1000x1. I'm saying theoretically because I never tried it, not because I think it's not possible. The sensor doesn't have any kind of constraints that could stop you to do that. Or, at least I couldn't find any into the datasheet. The VDMA has to have a fix number of bytes for each individual transfer. So, if you are playing with the number of bytes, you have to reinitialize the function above for each transfer, as it was done in the DEMO.
  18. @bitslip To answer your questions. 1. Yes. You can can output any image size that is described into the sensor datasheet. This can be done on the fly if you reprogram the right registers. Part of this is already achieved by the demo project. The change resolution option from the user interface reprograms the sensor for each resolution. For more info you can dig into the fallowing function: pipeline_mode_change(vdma_driver, cam, vid, Resolution::R1280_720_60_PP, OV5640_cfg::mode_t::MODE_720P_1280_720_60fps); The OV5640_cfg namespace has 3 different modes for each individual resolution. Each mode is correspondent to a structure that stores all the registers values needed for that resolution. To be more specific, all the registers that are responsible for image windowing (0x3800 to 0x3807), are configured in these structures. Let's take for example the cfg_1080p_15fps_ structure. If you want to calculate the output X size, you would have 2287(0x3804, 0x3805 registers) - 336(0x3800, 0x3801) - 16(0x3810, 0x3811) which is equal with 1919. The registers 0x3808 and 0x3809 are configured for 1920, so the image is basically un-scaled. For image windowing you have to rewrite those registers. 2. Yes and No. It depends on how many resolution do you want to add. Unfortunately I cannot give you a number, because I'm not sure how versatile is the current design. For now it works for 3 different resolution, but is hard to tell how many you could add on. Each individual resolution may have a different pixel clock, or as I said before, a different set of image constants. For now, I would probably start to understand how to configure the above registers, and I would start playing with them. You also need to make sure, that the vdma transfer works as expected. As you may see, the pipeline_mode_change function reconfigure the vdma_driver object for each resolution.
  19. Hello @bitslip, Sorry, my bad. I was referring to the Video Timing Controller not "Trimming". This IP simply generates timing parameters for the desired resolution. Check this link:
  20. Hello @bitslip, Things are a little bit more complicated. Indeed, for changing the resolution you have to rewrite some registers. But you also need to make sure that the Video Trimming controller ip generates the required constants for you resolution. I wouldn't recommend to write all the needed registers from the control interface (it would be agonising) Instead I would go with the existent logic for changing the resolution, which is adding a new structure with all the register values. As an example, you can check the OV5640.H file. I much simple and quicker solution would be to use our video scaller ip. This ip was written in HLS and it was used in the fmc pcam adapter demo for re-scalling the video at a 640x480 resolution. You can check the design in here: Best Regards, Bogdan Vanca
  21. Hi @learni07, If you want to save a specific setup, you can use putty or termite. Best Regards, Bogdan Vanca
  22. Hi @learni07, Can you please check the baud rate from Tera-Term? For this, click on Setup->Serial port and check Baud Rate down-menu. It has to be 115200. Best Regards, Bogdan Vanca
  23. Hi @Joel Richard, The fastest way of verifying your Verilog code is by using Test-Benches. Furthermore, if you want to do a live capture of your design you can go with ILA. If you want to speed-up your synthesis, you can increase the number of jobs used by Vivado. The Number of jobs is proportional to the number of local processors to use when launching multiple runs simultaneously. Best Regards, Bogdan Vanca
  24. Hello @Artoria, Please try to install Xilinx USB/Digilent cable drivers. Follow these instructions: Best Regards, Bogdan Vanca
  25. Hi @flying, I’ve opened your Vivado project and I faced the same issues. Your problems are probably related to the fact that you generated your IP’s output products before you changed the target device. In order to successfully generate the bitstream file, you need to select the Zc010 device and after that, you must update your IPs, generate their output products and finally generate the bitstream. The next step is to export your design into the handoff folder and regenerate the bsp file in SDK. Also, before you generate the bit file you must deactivate the DEBUG module from MIPI_CSI_2_RX_0 ip. If you dont do that, the project will not fit in the z10 variant. Underneath you can see all the steps that I went through. 1. First, I cloned the ZYBO Z7 DEMO project from here: 2. After that, I updated the Vivado library repository folder using the following repository: 3. After this, I moved back with 3 commits in the master branch. In this way I could generate the project using our old tcl Vivado flow. The same tcl file that you used. 4. I deactivated the Debug Module within MIPI_CSI_2 IP and I run create bitstream. 5. I exported the bitstream file in the handoff folder and I regenerated the bsp file in SDK. You can find the complet functional project on this link: For video processing you can use Vivado HLS. You cannot install OpenCV in PS. An alternative is to write down your own video processing algorithm in HLS and from there you can export it as an ip in Vivado. From what I know HLS includes the OpenCV interfaces. Best Regards, Bogdan Vanca