ZigEmbeddedGroup
Start RCC update to use ClockHelper v2.0 data
Note: This is not the final version; renames and configuration corrections are still planned.
- add clockhelper fork as a internal HAL import
Includes tests for the following microcontrollers (tests are also valid for all microcontrollers in the same sub-family):
- STM32F103
- STM32F303
- STM32L476
- STM32H723
Note on recursive expressions:
After analyzing the latest bug fix during unit testing for U575, I noticed that some expressions are not actually recursive. What happens is that the reference name ends up being the same as the node name, resulting in confusion during code generation.
Hopefully, by fixing this problem, support for F7/WB/N6 and MP will be restored.
Just one more small detail: translate flags to booleans instead of optional in out.config
And separate configurations in out.config into Advanced, Normal, and Flags, just like the configuration.
@RecursiveError i see that there is a massive diff for this PR. Let's put data files in their own repo, what should I call it?
@RecursiveError i see that there is a massive diff for this PR. Let's put data files in their own repo, what should I call it?
Or could we generate them instead and not check in the file?
@mattnite Well, they actually already have their own repository. This module is basically a copy of it, because I didn’t want to introduce an external dependency.
That said, if the idea is to create one under the org, I originally named it something generic like “ClockHelper”, so I think that name could work. (I do like the name CubeMZ, but I admit it’s kind of a stretch for just clock configuration 😄)
I agree that keeping it as a separate repo makes more sense anyway — there are still going to be a lot of updates coming. I mainly need feedback at this stage to know what should be changed.
Let me know if you need help solving the conflict. I have change the hal.zig file. and move it back to the STM32F103.zig file. That might be the source of it.
The clockhelper is ready for now.
@mattnite Regarding separating the data files into their own repository, do you have any ideas in mind? I intended to just add the original repository as a dependency of this module and pass hal_imports as an argument in the init() function of chips.zig.
@RecursiveError I think the best way to split it up would be to incorporate the ClockHelper repo into microzig, but keep the mcu_data directory as a data repository. Then what I'd like to see is file generation on the fly. Ideally we'd only generate what we need, not every clock tree for every device. This way code generation for the clock tree looks pretty similar to how Regz works.
@mattnite That makes sense. I can modify the code generator to emit individual clock trees, or even a small set on the fly, instead of producing everything upfront.
What I’m still not fully clear on is how the pieces are expected to be wired together: how would the generator receive information about what needs to be generated, and how should the generated code be exposed or integrated so that the HALs can actually consume it?
Understanding that interface/flow will help me align the generator with the intended architecture.
What I’m still not fully clear on is how the pieces are expected to be wired together: how would the generator receive information about what needs to be generated, and how should the generated code be exposed or integrated so that the HALs can actually consume it?
I have no clear idea too but I guess once this is merge we can start pushing more RCC related work to the common folder. And I got the feeling that clocks is core components for HAL so it would really improve STM32 HAL. :)
@RecursiveError I'm going to be diving into this patch further tomorrow so I can better determine what the interface should be.
@RecursiveError I have some ideas. First off, we have something workable, the main reason I want to structure things differently is so that generated code, with potentially very large changes every once in a while is something I'd like to keep in separate repos. One exception of note is the Chips.zig file for our stm32 port, I don't think there's a way around that one.
I've created a repo for you: https://github.com/ZigEmbeddedGroup/ClockHelper, essentially what I want you to do is move everything under stm32-clocks there. From what I understand, we should have a very clean interface which is very similar to how things work currently: a single ClockHelper module which is imported by every stm32 target in the port. I know I said I wanted to separate things chip-by-chip but let's kick that can down the road.
From my understanding of this single module, it has all the clock trees for all the chips, and we currently select which one by chip name at comptime using a mapping function.
This should provide a great starting point that we can iterate on. Thank you for all this amazing work, and putting even more effort into integrating it with MicroZig.
what I want you to do is move everything under stm32-clocks there.
I don't have permission to make the initial commit to the repo :(