Is acquiring the sample not a multi-step process? Seems like something is initiated via DMA, then eventually a result comes back and is "logged". And it seems as though there are multiple sensors that need to be sampled? As Miro said, processing something (e.g. performing an FFT) isn't inherently stateful. It's just inline processing. The main purposes of states to me is that the reaction to the same event (e.g. button press) can be different depending on the state of the system. So by tracking the...
Yes. Let's say you have states A, B, C and D. And in certain cases, an event can cause a transition from one of those states to state Z. It doesn't even have to be the same event signal but often it is. And let's say no matter why you're in Z, or where you came from, when the stuff in Z is done, you want to return back to the state where you came from (could be A - D), that's literally what the History pattern is for. Note Gene: the PSSiC2 book dates back almost 20 years. The History diagram in the...
Yes. Let's say you have states A, B, C and D. And in certain cases, an event can cause a transition to state Z. It doesn't even have to be the same event signal but often it is. And let's say no matter why you're in Z, or where you came from, when the stuff in Z is done, you want to return back to where you came from (could be A - D), that's literally what the History pattern is for. Note Gene: PSSiC2 dates back almost 20 years. The diagram in the book matched the code at the time (version 4.0),...
Hi Gene, (Note: this doesn't directly answer your original question, we can address that too, but first things first...) I didn't open the model but from the PNG, I don't think this is doing what you think it's doing. You are never transitioning to the Sample state. I'm guessing you haven't done any code generation yet, then you'd see what you're really doing. For a transition to the Sample state, you'd need the arrowhead of a state transition to terminate at the boundary of the Sample state. The...
Hi Glenn -- there is nothing like developing to really learn how to use QP. This is indisputably true. Same thing with learning a programming language -- best way to learn is "learning by doing" -- you get good at "doing X"... by "doing X". Lots of people like to read, watch videos, run existing examples, but never stare at a blank sheet of paper with a goal in mind. One of my favorite sayings is "No way out but forward through" (there are variations of this saying...) There are quite a few people...
The way I've handled this in the past is to use a separate HW timer from the QP tick timer (and QP time events) and in the ISR used POST_X Hope that makes sense
Sorry if I had more time I'd fill in all the details for you but you seem like a smart guy so hopefully this is enough... There are at least 2 ways to do this (note that I am not commenting on anything other than answering your question -- in other words, generally I don't recommend breaking encapsulation etc. but right now I'll try to answer your question...) Approach #1: You can use QASM_IS_IN() (version 8.x) or QHsm_isIn() (version 7.x and earlier) For these you are "going through the front door"...
Sorry if I had more time I'd fill in all the details for you but you seem like a smart guy so hopefully this is enough... There are at least 2 ways to do this (note that I am not commenting on anything other than answering your question -- in other words, generally I don't recommend breaking encapsulation etc. but right now I'll try to answer your question...) Approach #1: You can use QASM_IS_IN() (version 8.x) or QHsm_isIn() (version 7.x and earlier) For these you are "going through the front door"...