This is the code I am running on my Jupyter notebook:
PMOD_D4 = GPIO(GPIO.get_gpio_pin(0), ‘out’)
PMOD_D0.write(1)
The problem is I can’t make any changes to any outpot in the board (I’ve tried addressing LVDS lines as well using an AXI_GPIO and constraining it to a proper leg but it did not work as well).
In the code snippet you posted above you are initializing D4 but writing to D0. I assume that isn’t the issue itself and you just didn’t include all the code? What you have otherwise shown doesn’t make clear why it shouldn’t work. One other little thing that probably isn’t the issue is to make sure you are probing the right pin on the PMOD connector without any PMOD attached.
One other thing that comes to mind, some of the PMOD pins could be connected to the PS using dedicated UART, I2C and SPI. You wouldn’t be able to drive those pins as MIOs if the PS was configured to use the dedicated pins. You can verify this by looking at the PS multifunction pin settings in Vivado for the original Overlay (if your custom overlay was created from the default one you can look at your custom one). It is also in the tcl but it is convoluted in there, best to just use the Vivado gui to inspect. Changing these pin functions for the PS for you to control through Python will probably require a rebuild of the SD card image because the PS settings generate code that is run on boot up. Simply loading an Overlay into the PL doesn’t change the boot code. Device tree settings may also need changed. I don’t recollect what I set those PMOD pins to be over 4 years ago if you are using the one in github for Microzed. I can say for sure we never used the built in PMOD for anything with that build, the work done with it involved purely the PL.
With respect to using AXI GPIO, that takes a different approach and doesn’t involve the PS pin settings, OS or boot code. This is a link to newer than v2.6 but that IP’s Python hasn’t changed: AxiGPIO — Python productivity for Zynq (Pynq)
Also, I had a typo years ago in a post that said Microzed “v2.7” with 2020.1 tools. If you are using 2020.1 tools, the release is PYNQ v2.6, the github comments and release are accurate and say v2.6. That said whether it is v2.7 or v2.6 doesn’t make any difference to your issue.
Thank you pynqzen for the answer.
There was indeed a typo in the snippet that I sent, but it was not the problem.
I solved it by adding a target_label in the get_gpio_pin(pin_number, target_label=None) function.
Note that when not specifying the target label, it will add an offset to the pin number.
For instance, I found that the board LED is gpio953 (906+47), but without the target_label it addressed 906+47+54.
The gpio pin addressing from PetaLinux does have this quirk of requiring an offset, good to know your issue is resolved. The only thing I recall not working with the Microzed build is that the Ethernet MAC address is not read out of the EEPROM. It will not play nice if more than 1 board is on your LAN and any assigned IP will changed each boot. If you have fixed that issue, maybe you could do a PR, no worries if not.
Apparently, the problem was not fully solved.
For some reason I can access PMOD_D4 and PMOD_D7, but not the rest of the PMOD ports (0:3,5,6).
I can still control the board LED. I am connected to a board in which these PMOD ports are connected to an SPI of two ti DAC3484.
If anyone knows what are the differences between the MIO’s, and how to address them in PYNQ (especially while using a Microzed board), I would really appreciate it.
