-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add support for reading ADCs using Zephyr #113
Comments
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. |
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. |
So far I have discovered that for the first approach the next would be needed:
|
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... |
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. |
When replacing the |
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. |
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. |
I found two possible ways to adapt the adc support to Zephyr:
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:
|
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 |
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. |
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. |
Moved to here: https://github.com/CodethinkLabs/bloodlight-zephyr |
The text was updated successfully, but these errors were encountered: