Actions
Forum Thread Details
  • State Not Answered
  • Replies 2 replies
  • Subscribers 328 subscribers
  • Views 967 views
  • Users 0 members are here
Related

axi gpio (PL) read/modify/write on PS?

Former Member

So, I had to choose a forum :P

I have added a GPIO to my PL, and I am pretty sure it's done properly; I can read my inputs and write my outputs (...) from the PS side of things.

I have used the GPIO output port for some control lines; I need to set these in overlapping sequences;

Trying to get that working I realised I don't get the value I wrote to the output; I get zero.

That's fine, but the BSP function XGpio_DiscreteSet does read/modify/write; which of course doesn't work right if the gpio returns zero (you get the last thing you set).

I wonder if I'm doing something wrong in the GPIO configuration either on the PS side or the PL side?  Maybe it's expected behaviour?

It's not the end of the world to maintain the state of the outputs separately, but it would be nice if the source of the state was the actual output register.

Parents
  • 0

    I couldn't quite understand what you were getting at with the GPIO_IO bit; there was something that looked a bit like a bidirection bus interface - the GPIO interface - not sure that is what you meant?

    I have been using GPIOs with two channels, one out, on in because that's the way the IOCC Tutorial does it.
    When I added my PMOD stuff, I just copied the IOCC example and then added a second GPIO for my stuff, also with one out, one in; that's where I got the confusing behaviour with r/modify/w.

    So, I added a third gpio to my PL, this time a single channel and redirected my physical PMOD output pins to it.
    Then I tried two builds of the PL : with and without wiring the inputs to the outputs (gpio_io_i to gpio_io_o).

    From the software side, the only way I get r/modify/w is with the inputs wired to the outputs; no combination of fiddling with the control registers on the software side seems to fix that.

    Vivado ties the PL gpio_io_t tristate stuff to ground if you leave it disconnected... I have a logic analyser hooked up to the physical pins - I _know_ I'm writing to the outputs - so I'm sure that bit is ok.

    Anyway, since I'm not sure there's any arbitrary limit on having more gpios, I guess I'm happy and some very weird behaviour is explained :)

    The other thing that the IOCC tutorial does is go straight to the gpio_io_i/o ports when Vivado wants to connect the GPIO interface thing (which I still don't understand)...

    I will trawl Xilinx for a document less obscure than "LogiCORE IP AXI GPIO v2.0, Product Guide PG144"

Reply
  • 0

    I couldn't quite understand what you were getting at with the GPIO_IO bit; there was something that looked a bit like a bidirection bus interface - the GPIO interface - not sure that is what you meant?

    I have been using GPIOs with two channels, one out, on in because that's the way the IOCC Tutorial does it.
    When I added my PMOD stuff, I just copied the IOCC example and then added a second GPIO for my stuff, also with one out, one in; that's where I got the confusing behaviour with r/modify/w.

    So, I added a third gpio to my PL, this time a single channel and redirected my physical PMOD output pins to it.
    Then I tried two builds of the PL : with and without wiring the inputs to the outputs (gpio_io_i to gpio_io_o).

    From the software side, the only way I get r/modify/w is with the inputs wired to the outputs; no combination of fiddling with the control registers on the software side seems to fix that.

    Vivado ties the PL gpio_io_t tristate stuff to ground if you leave it disconnected... I have a logic analyser hooked up to the physical pins - I _know_ I'm writing to the outputs - so I'm sure that bit is ok.

    Anyway, since I'm not sure there's any arbitrary limit on having more gpios, I guess I'm happy and some very weird behaviour is explained :)

    The other thing that the IOCC tutorial does is go straight to the gpio_io_i/o ports when Vivado wants to connect the GPIO interface thing (which I still don't understand)...

    I will trawl Xilinx for a document less obscure than "LogiCORE IP AXI GPIO v2.0, Product Guide PG144"

Children
No Data