Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to read MMAPed memory location for GPIO #551

Open
RoyBellingan opened this issue Jun 23, 2024 · 3 comments
Open

Unable to read MMAPed memory location for GPIO #551

RoyBellingan opened this issue Jun 23, 2024 · 3 comments

Comments

@RoyBellingan
Copy link

I am trying to read the value of 2 pin (Header X12 pin 5 and 6 the GPIO 18 and 19)

It totally works fine using mraa_gpio_read, but the problem is the high overhead associated.
This code will also be moved either in the Cortex®-R5F or the Pruss once the code prototype is ready (which I think I understood how to enable the Pruss but no idea yet for the R5F)

My problem is that following the https://www.ti.com/lit/ds/symlink/am6528.pdf I can not understand which memory location I have to monitor...

I tried with GPIO0_18 0x0011C048 and a few other but no results.

Using gpioinfo I have

gpiochip0 - 16 lines:
...
        line  12: "IO18-enable" "sysfs" output active-high [used]
        line  13: "IO19-enable" "sysfs" output active-high [used]

So I tried also 0x0011C030 (12x0x4 = 0x30) but no signal is detected.

Any idea how can I find the memory location ?

I tried to follow mraa that uses (probably) writer2 2578 root 40u REG 0,22 4096 24634 /sys/devices/platform/bus@100000/bus@100000:bus@28380000/bus@100000:bus@28380000:bus@42040000/42110000.gpio/gpiochip3/gpio/gpio449/value
writer2 2578 root 41u REG 0,22 4096 24649 /sys/devices/platform/bus@100000/bus@100000:bus@28380000/40b00000.i2c/i2c-1/1-0021/gpiochip1/gpio/gpio494/value

But I have no idea how to convert this in or track which memlocation it does belong.

@jan-kiszka
Copy link
Collaborator

I'm suspect @benbrenson is this more present than I which output pin is actually on which controller and directly accessible this way at all - he worked on the unprivileged mraa bits.

Did you already try to use gpiod (gpioget) instead of mraa?

This code will also be moved either in the Cortex®-R5F or the Pruss once the code prototype is ready (which I think I understood how to enable the Pruss but no idea yet for the R5F)

Note that the PRUs are all in use for Ethernet by default, and I'm not even sure which access they have to system resources beyond that purpose (I would not expect much). The R5F cores look better - if there wasn't 43c85ac...

@RoyBellingan
Copy link
Author

Ciao @jan-kiszka Thank you very much! even if the news are not the most uplifiting is still very important to be aware of that!

I will totally give a look at gpioget, I was not aware of him!

@bniedermayr
Copy link

Sorry for my late response...

If you want to control gpios directly you should consider that each gpio pin also has two other gpio pins that are acting as

  • external pulll-up/pull-down
  • input/output transceiver

So in order to control a gpio pin to a desired value, you need to set the other two pins accordingly.

You may take a look into the source code of mraa here where all gpio pins and related push/pull/transceiver pins were set up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants