dbkincaid

Members
  • Content count

    15
  • Joined

  • Last visited

About dbkincaid

  • Rank
    Member

Recent Profile Visitors

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

  1. dbkincaid

    Zybo Z7 UART0

    Wow thanks!
  2. dbkincaid

    Zybo Z7 UART0

    I am trying to add UART0 on to the PMOD JF connection (the PS PMOD) I have configured this in the Zynq on the block design. I select MIO 10/11 as the UART pair but no matter what I have tried the BSP that is generated does not contain UART0 (I am trying to add this to an existing SDK project, bare metal) Any ideas that I can try?
  3. dbkincaid

    Comparison between Pynq and Arty

    I have both a Pynq and a ZyboZ7. The Pynq has been able to run Arty examples, and the XDC files are basically identical. There might be one peripheral change (microphone?) but everything else that I can remember is 1:1. I don't have any experience with PetaLinux, but I think if you want to go that direction you should try to find a group of users or examples for your board. The most likely place will be on Arty or Zybo. Pynq is more or less marketed to Jupyter users and research. One last thing, if you are looking into video HDMI I would recommend the ZyboZ7 because it has 'cable hider' equalization devices on board to clean the signal. This helps the device lock to HDMI. I have been much happier with my ZyboZ7 for video RX.
  4. dbkincaid

    Direct PMOD pin access bypassing GPIO

    I created two Vivado IP's for this purpose. One is PMOD out and the other is PMOD in. The verilog is basically wire in and assign out. This way I can map the 'PMOD' interface on the block design and connect to one of the PMOD board components. -Brian
  5. dbkincaid

    Zybo Z7 HDMI project build issue

    Ok I wondered if I was the only one with the issue. I was able to work around, I was actually kinda hoping for a TCL guru to pop-in and say oh if you want to auto-update all IP's just write blah blah blah Is the new release going to be 2016.4 or 2017.4?
  6. dbkincaid

    Zybo Z7 HDMI project build issue

    I'm on ZYBO-Z7-20 The file I have is Zybo-Z7-20-HDMI-2016.4-1.zip it's 135MB, and was created Nov 6, 2017 I'm almost completely certain I downloaded the zip from the page.
  7. dbkincaid

    USB HID -> PS/2 PMOD board ?

    I would love to see a PMOD USB to HID that could work as either a controller (takes input from HID devices) or as a slave (meaning, it acts like a keyboard or mouse) The pro micro arduino does this and I have one. It's pretty great, but not in a PMOD format.
  8. dbkincaid

    Zybo Z7 as standalone FPGA

    Juan, When learning/frustrated with Zynq I had the same questions. The main thing is that the system clock will typically come from a Zynq processor block. I would encourage you to drop down a Zynq block and use AXI_GPIO blocks to talk to each other to start off. As an example set up one as output only and the other as input only. This will simplify your (C) program. These blocks will route themselves on the block design using the automation tool. When you have learned the basics of using the GPIO blocks in the SDK (C) you will be ready to do lots of general communication and easier debug. At that point you are all set for stand-alone FPGA design, and can drop back Zynq to just the processor and clock out, or you can continue to use AXI_GPIO blocks as stimulus and capture for your logic design. Good luck!
  9. dbkincaid

    Zybo Z7 HDMI project build issue

    Hi Jon, I'm on 2016.4. When you move to 2017.4 I'll also move all my projects over.
  10. dbkincaid

    need guidelines for adding a ipcore to zybo board

    Pujith, Also when you add the PMOD to your design you might have some issue with Vivado's handoff to the SDK. Most errors can be cleared by rebuilding the BSP (right click option) in the SDK. I had a problem where I actually had to delete the BSP from the SDK project and then create a new BSP (with the exact same name), then the project was able to correctly build the BSP with the new PMOD.
  11. dbkincaid

    Zybo Z7 HDMI project build issue

    When building the HDMI project using the Vivado TCL command line I get errors after the block design section when the script attempts to build a wrapper. The source of the issue is that the block design pulls a HDMI core that is older than the one in my repository, so there is a 'update library' warning/error but it crashes the build with errors downstream. I was successful with a workaround by breaking the build into (everything to block design).tcl and (everything after block design).tcl and I update the IP on the block design in between. I was hoping someone more familiar with the tcl scripting could propose a solution to the 'update IP' issue. Thanks!
  12. dbkincaid

    PMODGPIO build on Zybo (2016.4)

    Awesome, this is what I needed. SDK seems to have a lot of 'hold your tongue just right...' things. It's a bit of learning curve and I would not consider myself a novice programmer.
  13. dbkincaid

    PMODGPIO build on Zybo (2016.4)

    I am attempting to build upon the hdmi demo, here is what I want to accomplish: Take over PMOD_C port as a general purpose digital output (8 pins) Here is what I have done (aside from debugging for hours) I dropped down and wired a PmodGPIO_0 block in my design and connected it to PMOD_C (JC), used the auto-connection automation function in Vivado. The build seems to work just fine, exported hardware, etc as normal. In SDK I get a drivers/ directory in hw_patform_1 with PmodGPIO_v1_0 and everything looks fine. Here are the exact steps I followed from here to where I am now: copied PmodGPIO.h down to hdmi/src (build project directory) copied code (functions) from PmodGPIO.c into video_demo.c (build main .c) copied code (init, main, close) from output_demo.c into appropriate places in video_demo.c Question 1) The code would not execute, because it appears the XPAR_ for PMODGPIO does not feed correctly into xparameters.h. Is this normal? I tried to workaround by checking system.hdf and found the base address for my PMODGPIO 0x40000000 and hard-coded it. This would allow the code to compile, but it does not run correctly, it hangs in GPIO_begin on the statement Xil_Out32(InstancePtr->GPIO_addr+4, bitmap);. This is the first statement where it attempts to write to the mapped memory. I have a feeling that something with the PmodGPIO IP is not building correctly for me, but I don't know how to correct it. I have tried several times to clean and rebuild the project, but again I don't know if I am taking the right steps. Question 2) Is there some type of 'build' that I need to do in SDK or somewhere else to initialize the IP correctly and be able to write to the PmodGPIO ? Thanks!
  14. dbkincaid

    Arty-Z7 GPIO0 access

    Ah, thanks for the hint! The GPIO I put together ended up on EMIO 31:0 which mapped to XGpioPS 2 (not GPIO_0 as the Zynq7 indicated). Once I changed the two lines that referenced the port it works!
  15. dbkincaid

    Arty-Z7 GPIO0 access

    Hello, I am having trouble with the last bit of my project where I have modified the video_demo of the Arty_Z7 example I added a 32bit GPIO to the Zynq7 in Vivado and exported it to the SDK. Note I am 'not' using the AXI, I am using the direct GPIO access. The .bit is automated from the block design. I have read and re-read the example in SDK for initiating a port read for this XGPIOPS Here is the code I think has an issue: (at define block and globals) #define GPIO_DEVICE_ID XPAR_XGPIOPS_0_DEVICE_ID XGpioPs Gpio; /* The driver instance for GPIO Device. */ (at beginning of function) XGpioPs_Config *ConfigPtr; u32 InputData; (later where the code is executed) /* Initialize the GPIO driver. */ ConfigPtr = XGpioPs_LookupConfig(GPIO_DEVICE_ID); status = XGpioPs_CfgInitialize(&Gpio,ConfigPtr,ConfigPtr->BaseAddr); /* Set the direction for all 32 pins to be input. */ XGpioPs_SetDirection(&Gpio, 0,0); /* Read the state of the data so that it can be verified, press any key to stop */ while (!XUartPs_IsReceiveData(UART_BASEADDR)) { InputData = XGpioPs_Read(&Gpio, 0); xil_printf("%08x\n\r",InputData); }; What this is supposed to do is blast the UART with the GPIO_0 data coming from the fabric, I confirmed on the Vivado side using ILA that the GPIO_0 data is running counters, etc as I designed it. What I actually get from the .ELF run is a constant value. I think this means I am either reading from the wrong place or I am somehow misunderstanding the function and just repeating the 32bit address of the memory location (instead of the data) Can anyone look this over and point out my error?