is there a high level document that explains all of that?
I see you have the usual oxygen sort of documentation. But to understand even that, I would still need to invest in a detailed study of the FlexPWM in the RM.
The challenge that I am trying to solve, is to keep A and B running accurately, while I am running a loop in software.
Thank you.The T4 has 2 x GPT (general purpose timer), which are 32-bit, which will simplify your application a lot, I think. Each GPT has 3 x output compare registers, so I think what you would need to do is select 2 pins that can be assigned to 2 of the output compare functions of either GPT1 or GPT2. Both pins should be on the same GPT.
I think the GPT can be configured to use either the 24 MHz or 150 MHz clock. Either one is okay in your case because either would support 1 us pulses and long periods (seconds) between pulses. Generating a B or C pulse could be done something like this:
- start with the output low and set for toggle on match
- read the value of the timer
- set the output compare to generate the rising edge
- enable the match interrupt
- on the rising edge interrupt, set the output compare for the falling edge
- on the falling edge interrupt, set the output compare for the next rising edge
If you think of this is as describing the B pulse, the C pulse would be done the same way, with the rising edge of C set to 0.5 us sooner than the rising edge of B. Because both B and C are running on the same timer, it's easy to compute the value of the timer for:
- rising and falling edge of C
- rising and falling edge of B
All 3 output compare functions share one interrupt, so the ISR has to check flags to see which match has occurred and what to do next. It will be tricky to set up, but it will take almost no CPU time, so it won't get in the way of whatever else needs to be done.
Thank you.
The problem is that I can't run an ISR during the readout. It will mess up the timing.
But now, after finally starting to grok the PWM section in the RM, a bit, it seems like a good solution might be to use three PWM modules.
Is it possible to reassign the external Teensy 4 pins among the PWM's?
Because you want to control the relationship between A/B/C, or at least between B and C, you probably want 3 PWM channels from the same module. I'm guessing that you're asking about pin assignments to use whatever pins you chose for your existing hardware?
Why do you say you can't have interrupts during the readout? The nice thing about using input capture and output compare is that the signal timing is independent of the interrupts, so you only have to ensure that the ISR gets executed before the next event.
Are you disabling the 1-kHz time tick?
#define CLOCKREAD (CORE_PIN5_PINREG & CORE_PIN5_BITMASK)
#define SETCNVST (CORE_PIN9_PORTSET = CORE_PIN9_BITMASK)
#define CLEARCNVST (CORE_PIN9_PORTCLEAR = CORE_PIN9_BITMASK)
inline void SensorReadOutLoop_() {
uint16_t *p16 = bufferp;
int i;
// Read on each rising edge
p16 = bufferp;
for (i=0; i<NREADOUT; i++){
while ( CLOCKREAD ) {} // wait while high
while ( !CLOCKREAD ) {} // wait while low
SETCNVST;
//delayNanoseconds( 710 );
delayNanoseconds( 670 );
CLEARCNVST;
*p16++ = SPI.transfer16(0xFFFF);
}
}I don't see why it's necessary to do it that way. Generally speaking, this is what timers are for.
You're welcome. I'll just make one more comment. You can get less jitter with output compare than you have now with polling. Input capture and output compare are done in hardware, so there is no interrupt response latency.Thank you for the discussion so far though, it has been helpful. With that and re-reading the PWM a few times, I am starting to get it.