Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#14 PWM duration fix

None
closed-out-of-date
Scott Dattalo
None
5
2013-06-29
2006-12-27
No

The PICs PWM has a 10 bit accuracy, but counts crystal cycles. The 0.22.0 code uses this 10 bits for counting processor cycles, wich results in a timer cycle being 4 times the programmed cycle.
Here is a fix for correctly simulated PWM durations.

BTW: the PWM patch for version 0.20 is now obsolete.

Discussion

  • Scott Dattalo
    Scott Dattalo
    2006-12-29

    Logged In: YES
    user_id=11911
    Originator: NO

    This patch causes the ccp sim_pwm877a regression test to fail. I'm going to hold back applying this patch until I can confirm that either the regression test is wrong or there's a bug in the patch.

    Scott

     
  • Robert Pearce
    Robert Pearce
    2006-12-29

    Logged In: YES
    user_id=481175
    Originator: NO

    I've just checked some real code that uses TMR2 for PWM on a 16F871
    GPSim gives a cycle time of 800us, or 1.25 kHz
    The real hardware runs at my intended 5kHz
    So the problem looks real, but I'm not totally convinced by the patch. The 14bit tmr2 code seems to assume the frequency changes by a factor of 4 when in PWM mode, which is wrong, but the patch doesn't change that. So I would suggest a dig into the underlying code structure, since the patch looks to address symptoms rather than causes.

     
  • Scott Dattalo
    Scott Dattalo
    2006-12-29

    Logged In: YES
    user_id=11911
    Originator: NO

    Robert,

    Thanks for verifying against real hardware that the gpsim PWM timing problem is real. I know what the fundamental issue really is: the 10-bit PWM hardware has higher timing resolution than gpsim's cycle counter. gpsim's cycle counter has the same resolution as the instruction clock which is fosc/4 while the PWM hardware can change states on fosc edges.

    I think the proper solution here is to follow through with the real time clock changes I started a few weeks back. I won't belabor this bug report with the details, but the real time clock design allows for multiple timing sources to independently control the simulation timing. The current gpsim design restricts multiple time sources to be referenced to the cycle counter (which in turn is referenced to the simulated processor's CPU frequency). gpsim currently cannot accurately model anything that runs faster than the instruction cycle counter.

    After a diversion with the I2C module, I returned to working on the real time design. The reset and sleep real time events need to be modelled before we can began to roll the design into the peripherals and modules. I'm using the 12c509 (because it's simple) as a test bed and am creating regression tests for reset and sleep. This is almost done. After that I'll implement the reset and sleep models in src/clock_phase.[cc|h]. Once this is completed, let's take a step back and see how we wish to proceed with the PWM timing. Meanwhile, anyone needing the PWM timing corrected for 10-bit PWMs can use Jean-Etienne's patch.

    Scott

     


Anonymous


Cancel   Add attachments