Alrighty. Also already noticed a minor bug in my code (should update acc and Rs at the same time).
All I am concerned with is this PPM generation at this point, so disabling the sequencer is fine. As a first pass, I think I'm just going to hijack the existing PWM code (or maybe put a switch in or something) since this practically is the same interface. Down the road, maybe a single message containing all or multiple channels would be more efficient. One other thing is I think I will need the PPM to fire up as soon as possible, because I think if the receiving unit doesn't get some valid frames near powerup, it goes into "bind" mode. Hopefully turning OC1 on at PWMInit() time will be OK. On Friday, January 24, 2014 10:48:05 AM UTC-6, Ytai wrote: > > The general idea seems to be correct (I haven't looked in closer detail, > and it seems like you know what you're doing). > One thing to keep an eye for is that the interrupt vector table is in > Flash and that the sequencer modules already defines handlers for the OC > interrupts. > You can either disable the sequencer if you don't care, of implement a > layer that emulates a RAM-based IVT, allows clients to register handlers in > runtime and forwards the interrupt to the currently registered handler. > > > On Thu, Jan 23, 2014 at 5:41 PM, GoatZilla <[email protected]<javascript:> > > wrote: > >> Ah. I probably should have read the PWM docs a little closer. I guess I >> can start writing code since I’m in “waiting for shipping-land”. >> >> Is there much penalty for 32 bit math? >> >> When I enable “Edge aligned PWM” with the interrupt flag on, is the first >> interrupt actually the very first sync (of the initial values loaded into >> OCxR prior to enable)? Or am I off-by-one here? >> >> >> Pseudocode: >> >> #define NR_CHANNELS 8 >> >> #define FRAME_PERIOD (frame_period_ns/clk_period_ns) >> >> #define PULSE_WIDTH (pulse_width_ns/clk_period_ns) >> >> unsigned long clk_period_ns = 500; // 2MHz; max period is ~32mS >> >> unsigned long frame_period_ns = 22000000; // or NR_CHANNELS * 2ms + 4ms? >> >> unsigned long pulse_width_ns = 500000; // 0.5ms >> >> unsigned int idx; >> >> unsigned int acc; // accumulator >> >> unsigned int pulse_period[NR_CHANNELS]; >> >> setup() { >> >> setup stuff; >> >> idx = 0; >> >> acc = 0; >> >> OC1R = PULSE_WIDTH; >> >> OC1RS = pulse_period[idx]; >> >> enable PWM; >> >> } >> >> OC1_int() { >> >> // width/period registers are buffered and will be loaded on next sync >> >> if (idx >= NR_CHANNELS) { >> >> idx = 0; >> >> acc = 0; >> >> } >> >> else { >> >> acc += pulse_period[idx++]; // Am I accumulating an error too? >> >> } >> >> if (idx < NR_CHANNELS) { >> >> OC1RS = pulse_period[idx]; >> >> } >> >> else if (idx == NR_CHANNELS) { >> >> OC1RS = FRAME_PERIOD - acc; >> >> } // You're watching the "Pad Channel" >> >> } >> >> >> >> >> >> >> On Thursday, January 23, 2014 11:27:58 AM UTC-6, Ytai wrote: >> >>> This has not yet been implemented. You don't need a timer I believe as >>> the OC modules have dedicated timers and in PWM mode will have shadow >>> registers for updating the duration with no jitter. 500us is plenty of time >>> at 16MHz if you use a high interrupt priority. >>> On Jan 23, 2014 12:02 AM, "GoatZilla" <[email protected]> wrote: >>> >>>> I noticed there was an earlier thread about PPM output being a >>>> possibility, but I don't see it being implemented yet. Am I reading that >>>> right? >>>> >>>> It does look like it's possible to do with the hardware compare (is >>>> Timer2 still free?), as long as the interrupts get serviced within the >>>> shortest pulse timing... Which is a ~500uS pulse with 500uS until next >>>> pulse. >>>> >>>> That sounds kind of tight with the way the double comparator only >>>> interrupts on the falling edge, so maybe two single comparators -- one for >>>> all the rising toggles, and one for all the falling toggles? Or perhaps >>>> more? >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ioio-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> >>>> Visit this group at http://groups.google.com/group/ioio-users. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "ioio-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/ioio-users. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- You received this message because you are subscribed to the Google Groups "ioio-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/ioio-users. For more options, visit https://groups.google.com/groups/opt_out.
