update GPIO driver

[Ho3eintaji]

• Full GPIO driver
• Driver functions are put in several levels of abstraction. Although abstract functions like gpio_config wrap up several function calls by passing a configuration structure, the driver still provides lower-level functions.
• Apps are updated based on the driver

[davideschiavone]

please check all the applications:)

[Ho3eintaji]

please check all the applications:)

All the affected apps were updated

[Ho3eintaji]

@JoseCalero conflicts with rv_plic commit must be resolved now.

[Ho3eintaji]

@JoseCalero should be ready now

[JoseCalero]

can you do a quick check about the conflicts on "example_power_gating_core/main.c" (it is due to one of the latest merges in main)

[Ho3eintaji]

can you do a quick check about the conflicts on "example_power_gating_core/main.c" (it is due to one of the latest merges in main)

done

[JoseCalero]

@Ho3eintaji i have done a check for all the apps, both in compilation and run mode.
For the freertos blinky app, I think that something is happening with the GPIOs, as only the red one is activated, can you check it?

[JoseCalero]

can you run freertos app?

[JoseCalero]

can you run freertos app?

ok, i know what is happening, we modified the xdc constraint file for the pynq when we did the PDM integration, so we used pins 21 and 22. So, @Ho3eintaji no need to test it, i will modify the constraint file and the freertos app

[davideschiavone]

can you run freertos app?

ok, i know what is happening, we modified the xdc constraint file for the pynq when we did the PDM integration, so we used pins 21 and 22. So, @Ho3eintaji no need to test it, i will modify the constraint file and the freertos app

hi @JoseCalero - if you are using GPIOs 20 and 21, you do not need to modify the constraints file, just set the multiplexer to "GPIO mode" rather than "I2S mode".

    pad_control_t pad_control;
    pad_control.base_addr = mmio_region_from_addr((uintptr_t)PAD_CONTROL_START_ADDRESS);
    pad_control_set_mux(&pad_control, (ptrdiff_t)(PAD_CONTROL_PAD_MUX_I2S_SCK_REG_OFFSET), 1);
    pad_control_set_mux(&pad_control, (ptrdiff_t)(PAD_CONTROL_PAD_MUX_I2S_WS_REG_OFFSET), 1);

In practice, in sw/./device/lib/drivers/pad_control/pad_control_regs.h, the make mcu-gen generates the PAD configurations, which is defined here.

As you can see here, the GPIO 20 goes now to the PAD i2s_sck multiplexed with the signal i2s_sck coming from the I2S.
By default, the PAD gets the I2S signal, so you need to set the multiplexer to "GPIO mode" (as above) to tell the PAD to get the GPIO signal instead (in the example above we set both the PAD I2S_SCK and I2S_WS to GPIO mode to get both gpio 20 and 21).

So no need to modify the constraints file, but just modify the application to include those lines

[JoseCalero]

@Ho3eintaji can you add those changes to the freertos app?

[Ho3eintaji]

@Ho3eintaji can you add those changes to the freertos app?

Yeah, I will change it.

[JuanSapriza]

When the I2S was introduced, it was decided to use GPIOs 20-22 (because they were the last ones).
These were already mapped to the RGB LED5, so they were re-mapped so that GPIOs 15-17 were assigned instead (in the pin_assign.xdc).
This change was never reflected in the example_freertos_blinky, which continued to use GPIOs 20-22.

The only change needed for it to work is to change the #define GPIO_LD5_* xx to their proper numbers.

There is no mux to change, as I2S and LED5 go to different pins in the FPGA board.

I will make a PR to this branch with this change and a merge of main.

[JuanSapriza]

Just merged with main and fixed conflicts. Tested involved apps in verilator and are working.

I did a pass over the HAL looks good to me.
@davideschiavone can we merge this?

[Ho3eintaji]

Just merged with main and fixed conflicts. Tested involved apps in verilator and are working.

I did a pass over the HAL looks good to me. @davideschiavone can we merge this?

Great, thanks @JuanSapriza
let's see if it is finally gonna merge or not 👀