Add support for reading ADCs using Zephyr

[ikerperezdelpalomar]

• Find out how Zephyr does dynamic pin allocation.
• Checkout the default pin setup in zephyr for stm32g and if needed apply changes to our devicetree to support adc and opamp.
• Decide if the dynamic pin allocation should be implemented at this stage or i future changes.

[ikerperezdelpalomar]

Bloodlight firmware allocates pins PA3, PB1 and PB2 dinamically for ADC or OPAM. In order to do the same in Zephyr I believe that the pin mux driver needs to be used.

There is an specific stm32 pinmux driver too: pinmux_stm32.c . So I wonder if the the pin mux driver would call this driver directly.

[ikerperezdelpalomar]

At the beginning I considered created a pinmux.c file that would contain all the pin allocations in one place. This I would involve creating the pinmux file listing the desired pins and configure them depending on the board revision. Then source.c file would need to be modified to use this file somehow (I still need to discover how to do that).

However, other possibility would be to replace the functions taken from linopencm3 with functions from zephyr. This approach would be a provisional solutions I believe, since the previous method is the one I see mostly being used in the zephyr project.

[ikerperezdelpalomar]

So far I have discovered that for the first approach the next would be needed:

• The pinmux.c content would be executed in the system initialization with SYS_INIT().
  • First I would need to set the pins with pinmux_pin_set
    • I need to understand what are the PINMUX_FUNCTIONS .
  • I need to create mux device pointing at a device tree pinmux definition. Like here:
    • Device tree definition: https://github.com/zephyrproject-rtos/zephyr/blob/2134f9b72dc205ffb08aef5f2d9fc5cfacd58fee/dts/arm/atmel/samd2x.dtsi#L99
    • Creation of the mux device in pinmux.c: https://github.com/zephyrproject-rtos/zephyr/blob/2134f9b72dc205ffb08aef5f2d9fc5cfacd58fee/boards/arm/atsamd21_xpro/pinmux.c#L13
  • Finally I somehow need to prove that all this actually creates a relationship between the pins and the pin multiplexer.

[ikerperezdelpalomar]

So I found pinmux_stm32g4x.h file where it seems like the functions are described, however is clearly stated on it that all those macros are deprecated. So I don't know which is actually the way to go...

[ikerperezdelpalomar]

I decided to discard the pinmux approach, because I haven't been able to clarify the doubts described above and even i posted some questions in various channels in the Zephy's slack workspace I was never replied.

I started applying the APIs included in zephyr/include/drivers/gpio.h.

[ikerperezdelpalomar]

When replacing the gpio_mode_setup for gpio_stm32_configure API I wasn't sure if I was going to be able to configure multiple pins in the same call, so I decided to first configure one at a time and once the firmware is up and running when can check whether that can be done.

[ikerperezdelpalomar]

stm32g4 series needs to be awaken from deep sleep mode, in the original firmware this was done using the adc_disable_deeppwd api in the acq.c file.

Zephyrs adc_stm32_init disables deep sleep mode for G4 family by default here, therefore I will delete lines 407 to 409.

[ikerperezdelpalomar]

It seems like I will need to modify completely the adc driver if I want to make it Zephyr style, to my understanding currently it's used the bl_acq_adc_s structure to hold the parameters that "describe" the adc, such as, base address, whether it's enabled or not, calibration etc. This is not based on devicetree in any way. On the other hand, zephyr uses devicetree for all this and has it's own adc_stm32_data and adc_stm32_cfg structures to hold all those parameters.

[ikerperezdelpalomar]

I found two possible ways to adapt the adc support to Zephyr:

1. Stop using the adc APIs created in adc.c and implement the ones in zephyrs adc driver. This might not be as straight forward as it looks, because I believe that zephyr adc driver doesn't perform exactly the same actions that are performed in the bloodlight driver. I need to double check this.

2. Replace the APIs taken from libopencm3 that are used in the bloddlight ADC driver by Zephyr's APIs. However, zephyr doesn't have (or I haven't found) APIs with similar functionality as the ones from liboencm3 that bloodlight's uses, so workarounds would be needed to achieve the same results. Some of the missing APIs are:

   • adc_enable_regulator and adc_disable_regulator.
   • nvic related
   • adc_set_multi_mode
   • Etc

I believe that the best option is to completely replace the bloodslight ADC driver by zephyrs one, since this would reduce maintaining work and it would keep up to date with zephyrs firmware. However Ben Brewer was concerned about this and mentioned about my previous comment that:

adc's can be statically configured to some degree probably
although it was always intended that it be dynamic since the configs change a lot, without looking at what device tree wants to make static, I'm not sure

[ikerperezdelpalomar]

After doing more research I found out thatthe APIs decribed above are not supported by zephyr but by the "zephyr ecosystem". That means that the "hal" drivers are included as modules and they can be used. So far the only when that is missing is adc_set_multi_mode.

[ikerperezdelpalomar]

I have been working on understanding the zephyr adc driver and I believe now that it performs very similarly to the current bloodlight adc driver. Therefore, I will proceed to adapt the current adc support to zephyr's adc driver.

[ikerperezdelpalomar]

Zephyr dma driver doesn't have dma support for now. Here I could work on a patch adding dma support, I could add the adc driver without dma or maybe a workaround could be done.

[tlsa]

Moved to here: https://github.com/CodethinkLabs/bloodlight-zephyr