Hrtim w dac trigger #11
Conversation
usbalbin
force-pushed
the
hrtim-w-dac-trg
branch
3 times, most recently
from
ed8bdaa to
8868eb0
Compare
| // Safety | ||
| // We will set up the real comparator before eev_input4 is | ||
| // connected to the timer output | ||
| core::mem::transmute::<(), Comparator>(()) |
There was a problem hiding this comment.
@AdinAck
This one is a bit interesting.
Here we want to set up the pwm timer to trigger the ref_dac which is used as the negative input for the comparator. The comparator is then via eev4 routed back to the pwm timer to reset the output on over current or similar.
In short
timer->dac->comp->eev4->timer
which is not possible to do in a safe way with the current interface
There was a problem hiding this comment.
Ah, If I understand what you're saying correctly, where we're heading does work with this.
Peripherals are comprised of many sub-states, for example the GPIOA peripheral has 16 sub-states for each pin's configuration (input, output, analog, AF).
In this case, the timer also has many sub-states. In the flowchart you wrote, it looks like the state machine has a circular dependency, when in reality both of your references to timer are actually different and independent sub-states of one timer peripheral.
Some dac state is entitled to timer state A and timer state B is entitled to some eev4 state.
Am I understanding correctly? I'm pretty sure this repo doesn't represent peripheral states as independent entities which are operated upon yet, but I believe that design paradigm resolves this issue. Correct me if I'm wrong!
There was a problem hiding this comment.
Sorry, I do not quite follow, I have a lot to learn when it comes to clever type system things (for lack of a better term :) ) and the theory there of.
Peripherals are comprised of many sub-states, [...]
Sure, makes sense
In this case, the timer also has many sub-states. [...]
Yes. In this case the timer is comprised of several types.
Too much information
Yes. In this case the timer is comprised of `HrTim<..>` mostly the actual counter, and its output `HrOut1<..>`, and its compare registers `HrCr[1-4]<..>`. Depending on how the entire timer was set up(represented using DacRst and DacStp type parameters), some combination of `HrTim<..>`, `HrOut1`, `HrCr2` may be used to trigger the dac. At the same time the `HrOut1` may be set up to listen for the timers external events which are owned not by this specific timer but the entire HRTIM peripheral(which has this timer and 5 others just like it). What events `HrOut1` listens to does not currently affect its type and can be done dynamically at runtime.What I do not understand is how we can ensure that things are set up in the correct order when we have a chicken and egg problem due to a circular dependency? Or do you mean that we somehow can side step this by splitting the types into sub types? But then how do we init them?
Or do you mean that we somehow in the type system build up our intended final outcome as a data type and then set up that in one go somehow?
Sorry, I am a bit out of my depth here
There was a problem hiding this comment.
I have a lot to learn when it comes to clever type system things (for lack of a better term :) ) and the theory there of.
Don't we all, this is bleeding edge stuff!
What I do not understand is how we can ensure that things are set up in the correct order when we have a chicken and egg problem due to a circular dependency?
In truth there is no circular dependency, that would imply the hardware is in error. Really, the interface is failing to express the hardware correctly and enters it's own virtual (fake) circular dependency.
Or do you mean that we somehow can side step this by splitting the types into sub types?
I wouldn't call this a "side step", but more the design is approaching hardware truth. Treating peripherals as collections of states (many sub-types/instances) is what I've been doing.
Or do you mean that we somehow in the type system build up our intended final outcome as a data type and then set up that in one go somehow?
Ah this is a good insight! This is necessary a lot of the time for traversing the hardware state machine. Something I have been curious about is whether state-wise entitlements (meaning state A may only be inhabited if state B is inhabited) can exist across registers. I've only ever seen it within the same register.
I just spent some time trying to understand how HRTIM, DAC, ... all work together in your use case but I just don't have enough time to understand this all. If you have a minimum reproducible example of this state dependency issue I'd be happy to take a look.
Sorry I can't be of more help, I myself am still figuring all this stuff out and have little time to work on it :(
There was a problem hiding this comment.
Thanks a lot for now! :)
I'll see if I can can figure something out or at least simplify the example use case
usbalbin
force-pushed
the
hrtim-w-dac-trg
branch
2 times, most recently
from
515c443 to
59bb877
Compare
No description provided.