Technical Forum Moderator
  • Content Count

  • Joined

  • Last visited

Everything posted by artvvb

  1. I reread your post, and to answer the specific question, this sounds correct to me, but you will need to ask Xilinx to make sure, as they are the ones that created the IP. Thanks, Arthur
  2. I have only used Continuous Channel Sequencer mode personally (caveat for the following). I believe that the DRP interface is largely independent of the conversion process (hence tying the den_in and eoc_out ports together). This means that data should be captured from do_out when drdy_out goes low and you have provided a stable daddr_in signal, largely ignoring the End Of Conversion signal for this process. I am curious how you are driving daddr_in, is it tied to GPIO/Buttons/Switches, or is it floating currently? This port is the address port for the DRP interface and needs to be s
  3. @bit5huang We currently do not have a Pmod IP core for the TMP2. I would suggest that you use the TMP3 IP core to get an I2C connection going. From the TMP3 drivers, only the TMP3_begin, TMP3_IICInit, TMP3_ReadIIC, and TMP3_WriteIIC functions should be used, as these interact directly with a generic IIC controller. From there, review the ADT7420 data sheet to determine the correct way to configure the device and grab data. Page 13 of this data sheet contains the register map of the device, of these registers, the most important will be the temperature registers (0x00,0x01) and the status
  4. @drewphysics The V_N and V_P pins are indeed grounded on the Basys 3. You can find all of the connected pairs of XADC pins in the Basys 3 schematic, in Bank 35, on sheet #6. Thanks, Arthur
  5. @flexible111 It depends on if your project includes a Microblaze processor or not. If it does, check out this tutorial. It may be a little outdated, but I don't see any major problems from a quick skim. Thanks, Arthur
  6. To add to my comments on possible performance problems: Running this masking algorithm in the Zynq PS will likely be inherently slower than running it in the PL. Adding a stage to the output pipeline in hardware is likely going to be a better approach, with the caveat that it would be a significant amount more work. This stage would likely need to be created as a custom IP core that either: 1. Takes in an AXI stream and outputs an AXI stream, probably placed near the AXI stream converter IP in the pipeline (if I am remembering things correctly, I don't have access to Vivado at the mo
  7. @Shuvo Sarkar Are you selecting the output frame using the serial interface to the demo? I assume that what is currently being displayed on stream is a single captured frame with the masking applied? If this is the case, it is likely possible to modify the demo further so that it runs the "copy, scale, and mask" algorithm repeatedly. By this I basically just mean placing the modified DemoScaleFrame function inside of a while loop. Caveat: I not certain what the performance cost of doing this would look like, so it may be worth looking into how quickly the algorithm runs (perhaps a li
  8. It would probably be easier to just switch to something like Tera Term, see the link I provided above. Our demos are validated with Tera Term, rather than the SDK console. It is possible that the flush cache doesn't see the '\r\n' until after it has already continued to the change res function. If this is the case, instead of flushing, you may need to call something like the following: int n=0; while (n<2) { n += Uart_Receive(...); } This will make sure to pick up the two newline characters.
  9. Could you try using Tera Term instead? I am unfortunately not super familiar with the SDK console, and have had trouble using it in the past.
  10. @Andrea_cau What serial terminal application are you using? If I recall correctly, Tera Term automatically sends any characters typed, so pressing enter is not required to send the '1' character. Thanks, Arthur
  11. @Shuvo Sarkar What exactly needs to be done depends on what you mean by "region of interest" and "binary mask". I will assume that you are trying to replace some area of what is being displayed on the screen with a rectangular image. A good starting point would be to take the input stream and output it with modifications. The DemoScaleFrame function in video_demo.c does this. The resolution scaling being done by this function also may or may not be desirable for your project. The Bilinear interpolation function implemented on line 473 of the original source is the primary point of interes
  12. This question has previously been answered here. Thanks, Arthur
  13. I should also note, definitely make sure that the "Apply Board Preset" checkbox is checked in the Block Automation dialog. This way you don't have to manually choose the RAM settings and other complicated things.
  14. @Skybird It is possible to configure the UART 1 peripheral in the Zynq block to connect to the FPGA through EMIO. In this case, some super simple C code should be able to set up a passthrough. Verilog modules can be added to a block design by right clicking in the Diagram pane and selecting "Add Module". You can then manually connect the module's rx and tx pins to the TX and RX pins of the Zynq block's new UART_1 interface. The C source would look something like the following (note I haven't tested this): #include "xuartps.h" #include "xparameters.h" typedef XUar
  15. Thanks! For the Pmod OLED, I have looked into it, and the pin that is usually connected to the ext_spi_clk port is tied to s_axi_aclk instead. This could cause problems if the AXI clock is running faster than 160MHz. I don't foresee this being an issue for the majority of users. This was an issue in the Pmod OLED's entry in the table at the top of the Pmod IP getting started guide. I have since fixed the error in the table. Thank you for bringing this to our attention. You should now be able to follow the guide to get the Pmod OLED running (ignoring the part where ext_spi_clk is connected
  16. To get some clarification, you want the output of the app to be the logo overlaid over the input stream? Function 8 (grab video frame and scale to display resolution) may provide some help here. Code for this can be traced back from DemoRun() in video_demo.c. It should be relatively straightforward to modify the DemoScaleFrame function to insert the pixels of the logo into the destination frame, at least as a starting point. For the launch issue, it sounds like if the HDMI cable is plugged into the source when the demo is launched, the demo does not detect it, but it does detect the sourc
  17. @alpha94 This was an error in the Pmods Supported table of the Pmod IP tutorial, thanks for bringing it to our attention. The Pmod OLED IP does not have an ext_spi_clk port, as the internal pin that is normally sourced by a port with this name is tied to the AXI clock. If the AXI clock is faster than ~160MHz, then this implementation will cause problems, otherwise, it should be fine. I will make sure that this gets made more consistent in the next validation pass, and will update the wiki page. The IP core should work as is (Vivado version depending, as always). Thanks, Arthur
  18. @alpha94 Could you create a new thread in the FPGA subforum as well as provide what version of Vivado you are working with, and a screenshot of your block design as it currently is? Posting in an existing thread may or may not create notifications for everyone who has posted here before. Thanks, Arthur
  19. @Shuvo Sarkar Have you connected the board to your PC over a serial connection? If I recall correctly, the HDMI input project does not automatically scale the output resolution based on the detected input resolution. However, you can manually set the output resolution through the serial connection as briefly described in the project wiki page. Thanks, Arthur
  20. I would just like to add that it would be a lot easier to figure out what is going on in the code if you would attach a zip file with your .v files to a post.
  21. You can try grabbing this repository from our Github. Once it is extracted, the repository can be loaded into Vivado through Project Settings -> IP -> Repository Manager. This contains the same interface definition as the repo subdirectory I mentioned back in July. The same process can also be used to add the repo subdirectory's vivado-library copy to the IP Repositories list. Note that this is one of the things that the create_project script is trying to do, so if it fails before it manages to do this, then that could explain the problem. Apologies for the hassle here, version
  22. @[email protected] Part of the issue here seems to be a failure of the comments in the UART transmit buffer module (and in the project in general). So, to talk a little about what this project is doing. The PS2Receiver module captures data from the PS2 port, and exposes it to the rest of the project with a keycode and a flag. The keycode consists of one or two bytes of PS2 data (key press on a code and byte count = 1, key release on a code with a 0xF0 and byte count = 2). The flag is a single bit wide and states that a new sample is ready and that data is valid. The '[email protected](keycode)' bloc
  23. @[email protected] It looks like the main addition you have made to the code is the Process module? I may just be missing it, but where is the count register being changed? Is it meant to stay constant 2'b00? -Arthur
  24. artvvb

    DPG1 Pmod

    Also, update on the DPG1 IP, it is now fully supported by the tutorial you linked.
  25. artvvb

    DPG1 Pmod

    @Sandokan The only code that is needed in SDK is to control the things connected over AXI. The way that I think about it is that since the C code is running on the ARM processor, which is contained within the Zynq IP in the block design, the only C code that gets written is the stuff that controls the things that the Zynq block is connected to. The above block diagram is intended as a generic example, in that the two Pmod GPIO cores can be replaced with other relevant IPs (AXI Quad SPI or AXI IIC, for example). Note that if an IIC pmod needs to be used, there is some extra work that