On Fri, Jan 24, 2014 at 4:32 PM, GoatZilla <[email protected]> wrote:
> 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. > If you do it "proper" at some point, I'll be happy to take a contribution. > > 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. > You can do that, but I would be REALLY surprised if what you're describing is the actual behavior. More likely it is sufficient to set the channels to some "zero" state in order to re-arm it after loss of communications. > > > > > 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]> 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]. >>> 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]. > 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]. 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.
