search

siemens / meta-iot2050

SIMATIC IOT2050 Isar/Debian Board Support Package
MIT License
131 stars 77 forks source link

Unable to read MMAPed memory location for GPIO #551

Open RoyBellingan opened 5 months ago

RoyBellingan commented 5 months ago

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 commented 5 months ago

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 https://github.com/siemens/meta-iot2050/commit/43c85ac457bffc5faa406da3596462e458f0f2d8...

RoyBellingan commented 5 months ago

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 commented 4 months ago

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

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.