PWM for general/sensor family dsPICs too, multiple channels

[OT]

The current help file indicates that the PWM library currently only works for a module on the motor control family of dsPICS. There are cases where this is much wanted for the other dsPICS, for instance to control the temperature in a precision instrument, or a quick and dirty way to make an analog output.

Also, support for more than one channel is much wanted, for instance to control multiple pumps in an instrument. Just being able to control duty cycle on multiple channels would go a long way; I personally do not really see much need to control frequency of each channel (if even possible). I know this has been wished for the PIC version before, but not granted so far (with pointer to complex example as I recall), I do not really see why there should not be a library with support for multiple PWM channels when there is multiple channel AD converter support. It would not be very acceptable to provide support for only 1 AD channel on a 40-80 pin PIC/dsPIC would it
--
OT[/b]

[zristic]

We are about to put our hands on dsPIC compiler(s) and we will work hard on the PWM issue among others. We will try to get the maximum out of the chip.

We will take two directions:
1. DS engine support
2. Extension of support for standard peripherals (PWM, SPI, CAN)...

[OT]

The PWM support for the motor control family seems very nice with multiple channels supported.

However, it seems that we still do not have PWM for the general/sensor family of dsPICS. Any chance we are seeing this in the forseeble future

I might be wrong, however the these PWM modules seems to be of the same type as on the PICs, so would it take much to adjust/compile the one-channel library for PICs for dsPICs? (PWM_simple.. )

[zristic]

it seems that we still do not have PWM for the general/sensor family of dsPICS. Any chance we are seeing this in the forseeble future

I am not sure that I understand your question. My impression is that we supported every dsPIC that has PWM. Please clarify.

would it take much to adjust/compile the one-channel library for PICs for dsPICs

They are quite incompatible, but we will do our best to support any PWM module that exists on dsPIC.

[OT]

it seems that we still do not have PWM for the general/sensor family of dsPICS. Any chance we are seeing this in the forseeble future

I am not sure that I understand your question. My impression is that we supported every dsPIC that has PWM. Please clarify.

The output compare modules on the general/sensor family (i.e. 30F6014) support simple PWM. The compiler does not seem to support this at the moment.

[zristic]

The output compare modules on the general/sensor family (i.e. 30F6014) support simple PWM. The compiler does not seem to support this at the moment.

Ok, got it. Added to the WL.

[jpc]

Hi OT ,

i just started playing with the dsPIC family , succeeded to produce 4 PWM-outputs with the output compare module's ( the dsPIC30F4013 has 4 )
Actually it was quite easy to do so after studying a little on the datasheet.
As these module's share the timer , all channels run at the same frequency. This frequency is related to the resolution. Do you have some idea of what would be a convenient syntax , i will put everything in a unit but would like to know what is preferred. I could imagine some init_multi_pwm( frequency ) and next set_pwmx(dutycycle) . For the frequncy i would like to know a practical range. Resolution of less than 1% should be avoided i think. If you are interested , give me some idea's. I prefer to see this kind of simple units to be written by the users and have them published with source above putting them on the wishlist. mE should build compilers , not deal with the library's for all the module's Microchip provides.

[OT]

Great if you want to contribute to this! I certainly agree that it is nice to have the source code available. Syntax, let us see, the PIC family has
Pwm_Init(Frequency:byte);
Pwm_Change_Duty(duty_ratio : byte);
Pwm_start and
Pwm_stop.

The dsPIC version for motor control have similar names with more parameters, and already support multiple channels, is more complicated to use and is not avilable on the general/sensor family. So I think Multi in the name is not needed since this is standard on dsPIC.
What about
Pwm_CCP_Init(Frequency:Word); to distinguish from the Motor control modules?
(Another alternative would be to include the word simple).

If it is to address multiple channels, each with their own duty cycle there is need to specify which pin or CCP module to use.
Pwm_CCP_Set_Duty(duty_ratio : Word; channel : word);
Pwm_CCP_start(channel); and
Pwm_CCP_stop(channel);
where channel would be CCP module no. The use of channel instead of ....x (for instance Pwm_CCP_Set_Duty1(duty_ratio : Word); ) avoids having to create extra procedures for each CCP module and is partly consistent with syntax for Motor control PWM on dsPIC, I do not know if that makes it more difficult to implement, either would work.

[jpc]

ok , as a first exercise :

Code: Select all

unit PWM_CCP;
{ @JPC 2006
  first attempt to ccp_pwm-support
  should be improved for wider frequency-range by using prescaler for timebase .
  uses Timer2 , Output Compare modules 1..4 .
   in it's current version , this unit running the dspic at 80 mhz gives usable frequency-range 306 hz ~ 30 khz
  }
  
implementation
var tmp : longint;

function  Pwm_CCP_Init(Frequency:word): word;
var tmp : longint;
begin
  PORTD := 0;
  ClearBit(TRISD,0);
  ClearBit(TRISD,1);
  ClearBit(TRISD,2);
  ClearBit(TRISD,3);
  tmp :=  clock_khz;
  tmp:= tmp * 250;
  pr2 := tmp div frequency;
  T2CON  := %1000000000000000;      // Timer2 on , no prescaler
  OC1RS := 0;                       // all duty-cycles to zero
  OC2RS := 0;
  OC3RS := 0;
  OC4RS := 0;
  result := pr2;                    // return resolution
end;

Procedure Pwm_CCP_start(channel: word);
begin
  case channel of
    1 : OC1CON := %0000000000000110;
    2 : OC2CON := %0000000000000110;
    3 : OC3CON := %0000000000000110;
    4 : OC4CON := %0000000000000110;
  end;
end;

Procedure Pwm_CCP_stop(channel : word );
begin
  case channel of
    1 : OC1CON := %0000000000000000;
    2 : OC2CON := %0000000000000000;
    3 : OC3CON := %0000000000000000;
    4 : OC4CON := %0000000000000000;
  end;
end;

Procedure Pwm_CCP_Set_Duty(duty_ratio : Word; channel : word);  // duty-ratio range 0..resolution

begin
  case channel of
    1 : OC1RS := duty_ratio;
    2 : OC2RS := duty_ratio;
    3 : OC3RS := duty_ratio;
    4 : OC4RS := duty_ratio;
  end;
end;
end.

was tested on easydsPIC2 with

Code: Select all

program ccp_pwm_test;
{ demoprogram for using pwm_ccp unit }
uses pwm_ccp;

var i             : word;
     resolution : word;

begin
  resolution := Pwm_CCP_Init(10000) ;   // initialize at 10000 hz
  i := 0;
  Pwm_CCP_start(1);     // start ccp_pwm-channels individually
  Pwm_CCP_start(2);
  Pwm_CCP_start(3);
  Pwm_CCP_start(4);
  while TRUE do
  begin
    for i := 0 to resolution do
    begin
      delay_ms(1);
      Pwm_CCP_Set_Duty(i,1);
      Pwm_CCP_Set_Duty (resolution-i,2);
      Pwm_CCP_Set_Duty (i,3);
      Pwm_CCP_Set_Duty((i div 2),4);
    end;
  end;
end.

[OT]

Hi jpc,
Very, very nice! Thanks for doing this. It compiles and runs fine with proper cyclic dimming of the diodes. The code looks surprisingly simple, however I know it takes time to extract the needed information out of the data sheet. I have a coming project in mind for this, and it will be nice to not have to use a separate chip just for to add simple PWM.
It seems that you have covered a good frequency range, and with the higher possible clock frequency of the dsPIC a better resolution than the simple PWM on the PIC. For my purpose it would be quite adequate.

The comment for the Pwm_CCP_Set_Duty indicates a duty range of
0-1000. I assume that should be 0..resolution? It might be needed to specify a somewhat higher minimum frequency with dsPICS run above 80 MHz, else the Word varible that stores resolution would overflow; that could go into the documentation.

Again very nice, may be it is time for ME to open up a projects page for the dsPIC too?

[jpc]

you are right about the 0..1000 range , sorry , changed it. I started looking for that appraoch but finally decided that as resolution depends on the frequency it would make more sense to give the reolution back at init-time.This allows for the highest precision . Regarding the lowest frequency's , for the time beeing i use no prescaler on the timer , it could be implemented , /8/64/256 are the options. Maybe the /8 is even a better choice .

[OT]

I am little uncertain whether it is desirable to go lower, 300 Hz is already quite low. One would still have a chance of overflowing the resolution variable, unless the clock frequency is is reduced? Would there be a reduction in max frequency?

Lower frequency means a longer time constant for the filter and bigger components in applications like cheap DA output, where one wants to smooth the output.. The same applies to power applications where one would want to smooth the output voltage with an inductor and a capacitor. 30kHz is actually a good frequency for such an application.

Perhaps someone else have other ideas?

[LGR]

I can see the potential in the long term for some more advanced PWM library functions, such as H-bridge drive (to create a class-D amplifier), and a 3-phase sinusoidal output using three channels with variable frequency and amplitude, for motor drive. Making these kinds of functionalities available in a library would add a lot of power to the complier.

[OT]

Aren't these specialiuzed applications that it is better to use the motor contol modules for (motor control family only)? jpc's unit is for providing PWM with the CCP modules, primarily on the general/sensor control family, of course with the limitation of one common frequency for all the CCP modules. Perhaps you were responding in a wider context? I was looking for responses from others regarding which freqency range to be covered by the PWM_CCP unit.

[jpc]

i can already announce that i started working on the motor control chips , enjoying some trouble with the QEI - module but once that is fixed will take a close look at the Motor Control PWM. As the dsPIC is more complicated , it will take some extra time to figure out how these peripherals work but in the end it is almost always quite simple.
Regarding the CCP-PWM , i think one frequency is not a handicap , running beyond audible is possible with acceptable accuracy (~0.1% ) and higher frequency's give more switching-losses.