Shop OBEX P1 Docs P2 Docs Learn Events
PWM using counters or not using counters? — Parallax Forums

PWM using counters or not using counters?

MicksterMickster Posts: 2,588
edited 2012-04-23 10:41 in Propeller 1
Got frustrated with the search feature...PWM is too short I guess.

Anyway, do I understand that there are two methods of generating PWM on the Prop, either straight PASM or using the counters?

Cheers!

Mickster

Comments

  • LeonLeon Posts: 7,620
    edited 2012-04-20 11:25
    There is also a Parallax app note, AN001, on the counters, which includes PWM generation.
  • MicksterMickster Posts: 2,588
    edited 2012-04-20 12:44
    Many thanks, gentlemen. I actually want to avoid using the counters for this purpose but had it in my head that they were at least the "better" method.

    I have a million ideas for the Prop but don't have as much time as I'd like to hunt down some of these answers so I apologize if I appear to be taking the easy way out.

    All the best,

    Mickster
  • HarpritHarprit Posts: 539
    edited 2012-04-20 13:52
    Counters are very easy to use for pwm
    PUB DoPWM(Pin)|Wav_Len, period         'subroutine to create pwm
      'dira[brk..dir]~~
     ' outa[brk]~  
      dira[Pin]~~                                          'sets pin direction for the pwm pin
      ctra[30..26]:=100                                 'sets usp PWM mode
      ctra[5..0]:=Pin                                     'pin spec           
      frqa:=1                                                'sets frqa decrement
      Pul_Wid:=0                                         'initial pulse width      
      Wav_Len:=clkfreq/1000                        'wave length
      period:=cnt                                         'initial period count
      repeat                                               'loop
        phsa:=-Pul_Wid                               'sets pulse width as negative, NOTE NEGATIVE                 
        period:=period+Wav_Len                  'wait period for wave length to complete                              
        waitcnt(period)                                 'wait
    

    In the above code
    pin is the where the signal will appear

    H
  • MicksterMickster Posts: 2,588
    edited 2012-04-20 15:45
    I was considering using the counters for high speed encoder counting by doing the quad decode in hardware (flip-flops). I use a lot of 6000+ RPM servo motors, equipped with 4096 line (16,384 counts/rev) incremental encoders. My goal is to close four PID loops @512uS and perform motion profiling for all four axes on a single Prop.

    Regards,

    Mickster
  • ErNaErNa Posts: 1,738
    edited 2012-04-20 16:06
    Hi, I started to do PWM generation in an ASM-loop for microstepping purposes. You find the sourcecode in http://forums.parallax.com/showthread.php?136328-Anyone-interested-in-a-microstepping-stepper-object&p=1056155#post1056155 but this was just a proof of concept. Quit and Dirty I didn't make an optimized version, using the inherent symmetries of the sinusoids, do it using CASE in ASM and setting up parameters in Spin.
  • jmgjmg Posts: 15,140
    edited 2012-04-20 22:03
    Mickster wrote: »
    I was considering using the counters for high speed encoder counting by doing the quad decode in hardware (flip-flops). I use a lot of 6000+ RPM servo motors, equipped with 4096 line (16,384 counts/rev) incremental encoders. My goal is to close four PID loops @512uS and perform motion profiling for all four axes on a single Prop.

    A little external conditioning sounds a good idea.

    You could use a small PLD, to turn Quad into Two Counter pulses, so a pair of counters manage the value.
    One is Up, one is Down, and the difference is the result. Counters are inside the Prop, conditioning is external.

    Practical limit in a 44 pin CPLD (sub $2) is 8 Quad Channels, and it can include an Error-Gatherer feature, which can catch any Double-edge instance, and those indicate the CLK is too slow for the Quad-Data (or noise). Just count pulses on the Error pin.

    Maximum Clock speed ?
    With no margins, and if we do the Count on Level=LOW (sparse edges are 1 clk =\_/= ) and assuming a 80Mhz clk is avail, and the PLD prop times are ok, I think it will (amazingly) run to 80MHz accumulate rates.
    A practical system might choose a lower clock, to save power/emc ?
    In that case, you would swap to edge mode on the Prop Counters.
  • MicksterMickster Posts: 2,588
    edited 2012-04-21 06:43
    A little external conditioning sounds a good idea.

    You could use a small PLD, to turn Quad into Two Counter pulses, so a pair of counters manage the value.
    One is Up, one is Down, and the difference is the result. Counters are inside the Prop, conditioning is external.

    Exactly! However, I was thinking on the lines of a simple 74xx74 (Opinion?)

    Quad decode.PNG



    Practical limit in a 44 pin CPLD (sub $2) is 8 Quad Channels, and it can include an Error-Gatherer feature, which can catch any Double-edge instance, and those indicate the CLK is too slow for the Quad-Data (or noise). Just count pulses on the Error pin.

    Very interesting. Any recommendations on a painless way to get involved with CPLD's?

    All the best,

    Mickster
    361 x 251 - 21K
  • ErNaErNa Posts: 1,738
    edited 2012-04-21 09:55
    If you run 6000/min = 100/sec @ 16khz this gives 1.6MHz what can be directly decoded by the quadrature object in obex. So there is no need for a CPLD which adds additional cost, space, firmware to program etc. So don't bother about that: use the propeller as it is made for such things like no other controller
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-04-21 10:03
    I've used the 74xx74 circuit in an industrial setting for a conveyor, and it worked fine. I'm glad to see someone else independently "discovering" it. :)

    -Phil
  • Graham StablerGraham Stabler Posts: 2,507
    edited 2012-04-21 11:22
    Counters might not be required but if used the same cog can do something else at the same time, very handy. That said if you want to have 4 channels of encoder it makes more sense just to dedicate a cog.

    If you have one cog doing all 4 encoders then you could have two cogs running the PWM and doing the PID, each cog could uses timers for two channels of PWM.

    Graham
  • MicksterMickster Posts: 2,588
    edited 2012-04-21 11:55
    Counters might not be required but if used the same cog can do something else at the same time, very handy. That said if you want to have 4 channels of encoder it makes more sense just to dedicate a cog.

    If you have one cog doing all 4 encoders then you could have two cogs running the PWM and doing the PID, each cog could uses timers for two channels of PWM.

    Graham

    Yes, I've been around and around with these various configuration options and here's my latest reasoning:
    • I don't need more than a few 10s of kHZ for PWM
    • My encoder count frequency requirement could easily increase in the future (commercially available motion controllers can handle 18+MHz)
    Now I'm very much a noob so maybe I misunderstand the programming possibilities so please go easy on me but here's my latest concept:
    • Cogs 1 - 4 dedicated to generating the PWM motor command for axes 1 - 4.
    • Encoders for axes 1 - 4 feed the counters of the respective cogs (quad decode via external 74xx74)
    • PWM loops grab the counter values and write to hub for use by the PID/motion profiling cog
    • Cog 5 takes care of all four PID loops and motion profiles at a sample rate of 512uS (reads encoder counts from hub and writes PWM cmds to hub)
    • Cog 6 pre-processes commands, checks for over-travel limits and general purpose PLC
    • Cog 7 serial communications
    • Cog 8 possibly serial communications or video output
    I realize that there are several ways to skin this cat.

    Thanks for the input.

    Regards,

    Mickster

    P.S. This is not a cost sensitive project and I will be adding a differential line receiver to take advantage of the complementary encoder outputs to help the noise immunity.
  • JonnyMacJonnyMac Posts: 8,912
    edited 2012-04-21 12:31
    Cogs 1 - 4 dedicated to generating the PWM motor command for axes 1 - 4.

    I've done simple motor control on a couple projects. In fact, just last week I coded a 3-axis camera platform that used encoders for positioning and speed control.

    Attached is an object I recently ported from Spin to PASM to control two motors using the counters. There are three pins for each: pwm output, direction, and an enable pin (the chip my project uses has a motor enable, you can specify -1 in this parameter for non use). With this object you can run one or two motors; this would cut your pwm cogs requirement down by two.
  • jmgjmg Posts: 15,140
    edited 2012-04-21 14:47
    Mickster wrote: »
    Exactly! However, I was thinking on the lines of a simple 74xx74 (Opinion?)

    That gets points for simplicity, but it only decodes one edge in four, so you need four times the precision in your sensor, for the same system resolution. Usually, that 4x jump in sensor costs much more than Silicon.
    It is also self clocking, so the edges fed forward to the Prop, are async in timing & there is no minimum pulse guarantee on a noise spike, and the behavior on a common mode spike is a lottery..
    The Edge Counter mode should tolerate async timing, at low enough speeds, but it cannot help the other issues.
    Mickster wrote: »
    Very interesting. Any recommendations on a painless way to get involved with CPLD's?

    Cheapest starters kits are the Lattice Breakout boards : [ LC4256ZE-B-EVN LCMXO2-1200ZE-B-EVN ]

    If you are not cost-sensitive, the LCMXO2-1200ZE board has some serious logic capability, and those boards are cheap enough you can even drop them into a project.


    Highest logic density in the low macrocell CPLDs ($1-3) are Atmel ATF750CL/ATF150x, where I use the simpler/faster CUPL for design entry.
    (think ASM level code - Boolean equation entry)

    CUPL can also support the smaller 16V8 & 22V10 and can create Logic Test vectors, which will work with a Device Programmer to allow real silicon testing.
    (16V8 & 22V10 need special programmers, whilst ATF150x also works on JTAG : Pgmr ATDH1150USB shows $46 @ Mouser )

    Lattice uses a higher level HDL entry, and timing simulation.
    /* CUPL code for that Dual FF is easy enough */
    QaQ.ck = QaPin;
    QaQ.d  = QbPin;
    QaQ.ar = !QbPin;
    
    QbQ.ck = QbPin;
    QbQ.d  = QaPin;
    QbQ.ar = !QaPin;
    

    HDL code for that could be a challenge with the linked D,AR, but you'd tend not to use HDL on Two FF.
    Mickster wrote: »
    My encoder count frequency requirement could easily increase in the future (commercially available motion controllers can handle 18+MHz)
    It is always a good idea to have margin here.
    Plenty of stories from the field, where the real-world was not as nice as the back-of-an-envelope
  • Graham StablerGraham Stabler Posts: 2,507
    edited 2012-04-22 04:46
    As I suggested and Jon demonstrated one cog can do two PID loops and two PWM channels. When you do the PWM you have a lot of time in between cycles to do the PID processing.

    Cog1: PID/PWM for two motors the read encoder position from cog3 and commanded position from cog3.
    Cog2: PID/PWM for two more motors
    Cog3: Reads 4 encoders
    Cog3: Motion control, sends commands to cogs 1 and 2.
    Cog4: etc etc

    Graham
  • MicksterMickster Posts: 2,588
    edited 2012-04-23 01:25
    Cog3: Reads 4 encoders
    Graham

    It still strikes me as bass-ackwards (?) I need a minimum of 1.6MHz encoder reading capability for EACH axis.

    Regards,

    Mickster
  • Graham StablerGraham Stabler Posts: 2,507
    edited 2012-04-23 03:29
    Hmm decisions decisions

    Looking again and considering the need for 1.6Mhz and more potentially I might do the following:

    Cog 1: PWM and PID for all 4 channels, using Phil's object which can do 8 channels at 23Mhz with 8 bit resolution in one cog: http://forums.parallax.com/showthread.php?104121
    Cog 2-5: Encoder reading and anything else you want them to do at the same time

    Also seems not so good, an alternative would be to use a second micro for the encoders and just request current positions from it via serial at your PID loop rate (lower than PWM normally).

    My concern about your idea is that on the face of it, fairly low frequency PWM sounds fine to hard code but it is not the period but the minimum on time that creates programming issues. If you take 20khz as your PWM frequency then 8-bit resolution means the minimum on time is only 15 clock cycles, so you are reaching a limit already for the resolution vs period, the counter based PWM generation can go right down to a single clock count (because it uses the counter a little like a oneshot), something you can't do with waitcnt. Phil's object is great because you get all those channels in one cog but is also limited in resolution in this way.

    The other complication is that the time you have left over to process other things becomes variable and the minimum is the PWM time period/2. You would have to ensure that you do your processing in on or the off time, choosing the largest.

    If you CAN combine the non hardware PWM and the PID in one cog then your idea does seem to be a good one.

    Just FYI below is the expected resolution vs frequency for counter driven PWM:
    Time period for a given PWM frequency in clock cycles also determines the resolution
    
    T = CLKFREQ/F
    
      F in Hz       T/resolution (80Mhz clock)        possible asm instructions in loop (theoretical)                  
        1000            80000     (more than 16bit)               20000        
        2000            40000     (more than 15bit)               10000
        3000            26666.66  (more than 14bit)               6666
        4000            20000     (more than 14bit)               5000
        5000            16000     (more than 13 bit)              4000
        6000            13333.33  (more than 13 bit)              3333
        7000            11428.57                                  2857
        8000            10000                                     2500
        9000            8888.88                                   2222
        10000           8000                                      2000
        15000           5333.33                                   1333
        20000           4000                                      1000
        25000           3200                                      800
        30000           2666.66                                   666
        40000           2000                                      500
         etc
         etc
         
        MAX frequency for given resolutions:
    
      Bits      resolution     Max frequency (CLKFREQ/T)
    
        8            256             312500  (312.5 kHz)
        9            512             156250  (156.25 kHz)
        10           1024            78125   (78kHz)
        11           2048            39062.5 (39kHz)
        12           4096            19531.25(19kHz
        13           8192            9765.625(9.765khz)
        14           16348           4893.564 
        15           32768           2441.4  
        16           65536           1220.70
    

    Cheers,

    Graham
  • MicksterMickster Posts: 2,588
    edited 2012-04-23 10:21

    Just FYI below is the expected resolution vs frequency for counter driven PWM:

    Perfect! Thank you. This was going to be my next question. So for a PWM frequency of around 20KHz, I can expect an effective DAC resolution (filtered) of around 11bits?

    This thread has been a very great help to me.

    "jmg" put me on to a quad-decode chip some time ago and I see that they have one that outputs up/down counts that I could tie to the Prop's counters.

    I think I will reduce the axis count and use the counters for both command and feedback.

    Phil's 8-bit pwm is perfect for driving DC-coil solenoid valves, I bet.

    Thank you all, once again!

    Mickster
  • Graham StablerGraham Stabler Posts: 2,507
    edited 2012-04-23 10:41
    Yes that's right you get 11bits roughly at 20khz.

    It is just a shame we cannot find a way to read an encoder with one counter (using the second pin and logic) but it seems impossible as the counter always accumulates.

    Graham
Sign In or Register to comment.