Does PWM run in the background?

[airman00]

Hello,
When I do a PWM on a pin does the PWM run in the background? Using the example below , will the LED turn on after the PWM went through 1000 pulses , or will it turn on while the PWM is doing it's 1000 pulses?

Code: [Select]

// do simultaneous pulse output on OC1A and OC1B pins with different frequencies
//OC1A will be at  50Hz for 20 seconds (1000 pulses)

// start OC1A output
pulseT1ASetFreq(50);
pulseT1ARun(1000);

LED_on;   // turn on the status LED


[mbateman]

I'm not sure how the specific calls you reference work, but if you directly use the OCRnA settings, it will run in the background. Here is a link to my post that has some code I wrote for the Axon, but should be easy to modify for any of the atMega chips.

http://www.societyofrobots.com/robotforum/index.php?topic=5590.0

Also, typically the "1000" is would be the length of the PWM pulse, not the number of pulses.

[Half Shell]

The unfortunate answer: depends.

Many microcontrollers have PWM modules that, when called, will take care of PWM signal generation seperate of the chip's main processes. This means signal generation does not take precious processor time! This isn't always the case though, especially when you're generating PWM on a chip that doesn't have these modules.

Look at the data sheet for your uC - the answer should be there!

[izua]

Always check what happens in the source code: http://ccrma.stanford.edu/courses/250a-fall-2002/docs/avrlib/pulse_8c-source.html
Pulse t1a toys with the channel A of timer 1. So, it will alter the hardware's channel settings. Which should mean - in this case - that it will 'run' in the background.

[airman00]

Specifically on the ATmega168 there are 6 PWM channels. Does PWM on those pins run in the background?

Also what exactly am I looking for in the datasheet. What kind of phrasing?

Thanks

[creedcradle]

Specifically on the ATmega168 there are 6 PWM channels. Does PWM on those pins run in the background?

Also what exactly am I looking for in the datasheet. What kind of phrasing?

Thanks

Actually you are referring to a multi-threading process. Say, you have the following tasks to do:

PWM1(20hz)
PWM2(30hz)
PWM3(100Khz)

Then, you can not execute this easily with a simple "bitbang" (for MCU with no built-in PWM) thus, the solution is multithreading...

Here's a good example by zer0w1ng from his home page:
http://geekzone.freehostia.com/

or visit the forum discussion
http://www.electronicslab.ph/forum/index.php?topic=1509.40

-creedcradle

[airman00]

Here's a good example by zer0w1ng from his home page:
http://geekzone.freehostia.com/

Where exactly is it there?

Also if I am not bit-banging and I have hardware PWM channels, then I could do PWM1 ,PWM2, PWM3 successively and it will run in the background , right?

[mbateman]

For what you are doing on the atMega, this will effectively run in the background. It is based on hardware and uses internal timers and compare logic. You will not be able to use the accociated timers for anything else, but once set up, they will pump out a steady stream of the correct PWM on their own until you change the value of the compare register. Then they will start sending PWM of the new duty cycle. Your code can set the value and then forget it until it needs to change to a different value. The rest happens without taking cycles from your application.

Also remember that 3 pins share the same timer. This means that you have the same base period for all 3 (typically 20mS for servos), but can have separate duty cycles (pulse width) on each one.

[mbateman]

I just noticed that you are using the atMega168. It has 2 pins on each timer instead of 3. Also, only Timer1 is 16 bit, so you will need to do some work on the clock div and OCRxx values on the 8 bit counters to get them to the right base period and pulse widths.

Also, using all 6 PWM will use up all of your timers (0,1,2) so that may cause other problems if you need timers elsewhere. You can still read them, but you should not change or reset them, and you must understand what they are doing for PWM if you intend to use those readings for anything else.

[airman00]

heres my application : ATmega168 that uses UART and control 6 PWM channels based on what data the UART receives.
The UART is getting data in a constant stream , now you know why I need the PWM to run in the background.

[mbateman]

That will work, but the problem you are going to have with the atMega168 is that two of the three sets of PWM are on 8 bit timers. It is nearly impossible to get much resolution in the range you need. For example if you are trying to drive servos at appox 50Hz, and you have a 1Mz clock, you would need to use prescale of /64 to get a top value that fits in 8 bits (156). Then to get typical servo pulse widths, you would have the following settings for the OCRxx registers.
1.0 mS = 8
1.5 mS = 12
2.0 mS = 16

That gives you a total of 8 steps using integer values.

It would be much easier and get better resolution if you use a chip with enough PWM on 16-bit timers such as the atMega640.

[airman00]

I'm not necessarily controlling servos, rather LEDs . I would definitely want more than 8 steps - more like 256. I need PWM because I have three LEDs- Red , Green, Blue. I use PWM to change the colors.

 

value that fits in 8 bits (156)

You mean 256 , right?

So any chip you'd recommend that has 1 UART and 6 PWM channels . And I guess I would need 16 bit timers by each channel?
I'm only confused because shouldnt a 8 bit timer should have 256 resolution , right?

[mbateman]

With PWM, you have two durations that are important. 1) The base frequency. 2) The pulse width. Using the built-in PWM functions, you use ICRx to set the base period (with respect to the system clock divided by the prescale). Then you use OCRxx to set the pulse width.

ICR = Clock freq / (base frequency * PRE * 2). This needs to fit into the size of your timer. So for an 8 bit timer, this must be less than 256.

So in my example of a 50Hz servo and a 1Mhz sys clock, you would use an /64 prescaler and an ICR setting of 156.

You would then be able to use OCRxx settings of 1 to 155 to get the full range of possible duty cycles. With a servo, only a tiny range of duty cycles is used, so your number of possible steps would be greatly reduced since most of the possible 155 settings are not within the range the servo uses.

Now for your LEDs, you probably want to use the whole range of duty cycles and don't care as much about the base freqency, so you can get the whole 255 range from each one with the 8-bit timers and it would work fine.

You could use a prescale of /64 and an ICR of 255 which with your 1MHz chip would be a base freqency of approximately 30Hz. Then use OCRxx settings of 1-254 to get the full range of duty cycles on each pin. You could also use a prescale of /8 and have a base frequency of approx 244Hz.

[dunk]

hey Airman,
have you read this:
http://members.shaw.ca/climber/avrtimers.html
it's a good starting point on AVR hardware timers and PWM.


dunk.

[airman00]

You could use a prescale of /64 and an ICR of 255 which with your 1MHz chip would be a base freqency of approximately 30Hz. Then use OCRxx settings of 1-254 to get the full range of duty cycles on each pin. You could also use a prescale of /8 and have a base frequency of approx 244Hz.

I am running my chip at 8mhz, so how would that affect it? It would increase the amount of "steps" in the PWM to the maximum 255 ( for 8 bit) , right?

@dunk
Thanks , I'm going to read it tonight

[mbateman]

Basically you just need to determine which base freqency is most suited to your needs. At 8Mhz system clock, you could various ICR settings to get a full 256 resolution. To do that, use an ICR of 255, and then the following prescalers will determine your base frequency:

/1 1.953 KHz
/8 244 Hz
/64 30.5 Hz

Base Freqency = Clock Freq / (ICR * prescaler *2)

Then just use OCRxx of 1-254 to set your duty cycle.

This is all assuming you use Phase Correct PWM mode. If you use Fast PWM mode, you will get 2x those numbers for the base freqency. It sounds like you are just trying to set the intensity of the LEDs using PWM, so you can use Fast PWM without issue, I would think.

[creedcradle]

Here's a good example by zer0w1ng from his home page:
http://geekzone.freehostia.com/

Where exactly is it there?

Also if I am not bit-banging and I have hardware PWM channels, then I could do PWM1 ,PWM2, PWM3 successively and it will run in the background , right?

My bad airman00. His page has been updated but I have his old page here :
http://www.microelektronics.com/index.php?sel=free

Tiny Threads - Tiny Multitasking Threads for Microcontrollers
by: Regulus Berdin

    * Idea based on http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html.
    * Only 1 byte RAM needed per thread.
    * Very small overhead context switching.

Limitations:

    * Maximum 254 lines per thread.
    * Thread context switching will not work within a switch block.

Usage example:

     TT_DEF(1)
     {
        TT_BEGIN(1);
        while (1)
        {
           ...
           TT_SWITCH(1);
           ...
           ...
           TT_WAIT_UNTIL(1,keypress);
        }
        TT_END(1);
     }
     
     TT_DEF(LED_TASK)
     {
         TT_BEGIN(LED_TASK);
         while (1)
         {
             LedOn();
             delay=DELAY_1_SECOND;
             TT_WAIT_UNTIL(LED_TASK,delay==0);
             LedOff();
             delay=DELAY_1_SECOND;
             TT_WAIT_UNTIL(LED_TASK,delay==0);
         }
         TT_END(LED_TASK);
     }
     
     void main(void)
     {
         ...
         ...
         while(1)
         {
             TT_SCHED(1);
             TT_SCHED(LED_TASK);
         }
     }

Download for the header file and example is on the same page.

-creedcradle

[Webbot]

Since you're only controlling LEDs and so the PWM doesn't need to be 100% accurate then you could always use the scheduler from:
http://www.societyofrobots.com/robotforum/index.php?topic=541.0

This only uses one timer and you can use the service routine to flip the port  pin on any pin - so now you can make any, or all, of your IO pins into PWM

[izua]

I wouldn't rely on threading if the MCU is not fast enough, except maybe very slow tasks (blinking a led, sending 2400 baud data, reading a button).
Software PWM in separate threads is an easy way to ask for trouble

[creedcradle]

Software PWM in separate threads is an easy way to ask for trouble

Yeah. This is just the same thought with what I had before. But tiny thread has magic in it.
Speed of the MCU is not a deal. Try it for yourself first. Give it a chance. 

-creedlcradle

[airman00]

Since you're only controlling LEDs and so the PWM doesn't need to be 100% accurate then you could always use the scheduler from:
http://www.societyofrobots.com/robotforum/index.php?topic=541.0

This only uses one timer and you can use the service routine to flip the port  pin on any pin - so now you can make any, or all, of your IO pins into PWM

Webbot does that service routine run in the background , and also can I run multiple PWMs at the same time using that routine.

Let me be a bit more clear about my application
I am sending packets from RF and in between each packet ( which is 4 bytes) is a 2ms delay. The receiver outputs teh UART data that it receives to the microcontroller . Now the microcontroller has 2ms in between packets to do all six PWMs at the same time. The six PWM channels are connected to two RGB LEDs, so I use PWM to dim either the R,G,or B.

@mbateman I think I understand now . I'll do some more research at it.
Thanks

[TrickyNekro]

I don't know exactly man... But you can use timer for that...
Set timer to run as a timer not as counter, Set whatever prescaler you want
Set the compare value and finally enable the output at OSC pin...

Now, if you get a continuous stream of data why don't you just use the RX interrupt when
you are not using the PWM and get any new value...
I really did something like this with two servos and a continuous stream of data...

I had one microcontroller to collect data from photoresistors and another to
drive the servos, as a neuron system...

But you can definitely use a timer and RX buffers, simultaneously!

Best Regards,
Lefteris

[airman00]

But still can I run mutliple PWM at the same time using the timer?

Also , I only have 2ms between packets to do PWM on six pins . You think I will be able to do a regular software PWM ( the same type of technique used to control servos) for all six pins at the same time - I would have to do the PWM on a resolution of uS in the code , right?

[Webbot]

Sorry for my delay in responding. Been away - and recovering from some of the nonsense that people have posted.

@izua

I wouldn't rely on threading if the MCU is not fast enough, except maybe very slow tasks (blinking a led, sending 2400 baud data, reading a button).
Software PWM in separate threads is an easy way to ask for trouble

This isn't threading - its doing stuff under interrupts. Surely you dont have a problem with that - else you must have a problem with AVRlib as it does that all that time by attaching callback methods to the timer interrupt. The post I referenced just gives a very elegant (IMHO) routine for you to be able to queue up lots of call backs to happen at certain times in the future. Also airman00s specific question was about 'blinking LEDs' so you've shot yourself in the foot anyway ( as in - 'Hey airman dont use this to blink LEDs unless you want to blink LEDs'). Perhaps you would like to explain why its asking for trouble? I use this method to PWM motors/servos (by having a timer that is interrupted quite often) and it works like a dream. So you must know something that has never happened in my real world and I'd like to know what it is. If your servo/motor control is critical then you would have an encoder anyway to help adjust it to the correct place and this would make up for the small inaccuracies of the scheduler.

@airman00 The link I gave just allows you to queue up some code that is called later on under interrupts (in the background). The scheduler code keeps track of all the items in the queue and is well optimised so that the 'next' callback is easily tracked. So on every timer interrupt it can quickly check if something needs to be called. So in the case of PWM you can queue up events to toggle the output pins where the delay between on/off is dictated by the duty cycle. So 'yes' you can do PWM on whatever IO pins you want (unless its very high frequency PWM whereby the interrupt scheduler takes longer to run than the PWM cycle time). The granularity of the scheduler depends on how often the timer interrupt happens. So, for example, if the timer interrupt only happened every 1ms then the callbacks could only happen every multiple of 1ms - not good for servos. But you can always make the timer interrupt happen more often. The number of PWM channels is dictated purely by the size of the queue and the scheduler allows you to easily allocate more memory to the queue to allow for more queued callbacks.

At the end of the day - my link showed some code that works. Whether it works for you unmodified, or needs to be (easily) changed for smaller timer intervals, the fact is that its a very useful piece of code that works very well. I 'tip my hat' to the author 'groovy9' and regret that he hasn't returned to SoR for nearly 2 years - we would all benefit from such contributors.

[airman00]

Thanks for all teh replies guys

Heres what I think is the easiest thing to do right now

Code: [Select]

UART on interrupt
when it isnt in an interrupt do a PWM on the pins using servo-type software or hardware timer based
From what I understand I can use one hardware timer to generate the proper PWM for six pins at the SAME time. Is this correct?
Also if I were to do PWM using the servo type software - ( set high , wait certain amount of time, set low ), would I have to do the "certain amount of time to wait" in a resolution of uS(instead of the usual mS that servos use) , so I get a better PWM , because if it were in mS the UART interrupt could disturb the PWM frequency ?Obviously the delay after the software PWM would be more than the usual 50hz that servos use. Can anyone clear this up for me?

[Webbot]

From what I understand I can use one hardware timer to generate the proper PWM for six pins at the SAME time. Is this correct?

Yes - you can set the output high and use the scheduler to set the output low at a later date - under the tiimer interrupt in the background

would I have to do the "certain amount of time to wait" in a resolution of uS(instead of the usual mS that servos use) , so I get a better PWM

Since servos tend to work in the range 1ms to 2ms (or thereabouts depending on manufacturer) then you need a better level of control than just ms. So uS is the next best bet. But don't do this in the foreground by just wasting time in a delay loop else you will neglect all the other servos and your main loop could grind to a halt.

Using the scheduler you can say: set the output high and queue an event so that in 1.5ms I will toggle the bit low. In the meantime you get on processing other servos. So your main loop doesn't suffer from 'delays' whilst processing each servo.

[airman00]

But doesnt the timer interrupt interfere with the UART interrupt ? Can I establish an interrupt "hierarchy"?

[Webbot]

It doesn't 'interfere'. They are two seperate interrupts. The mcu will call each interrupt service routine in turn. NB I'm assuming that your UART is using the standard hardware Tx/Rx interrupts - if you are using AVRlib to perform software UART on other pins then it may be different.

[airman00]

I mean what happens in a scenario when the timer interrupt and a UART interrupt occur simultaneously , or if the UART interrupt occurs right before the timer interrupt is destined to be activated, thus screwing up the timer and the PWM.

[Webbot]

The timer interrupt sets a hardware flag, and the UART sets a hardware flag. The mcu will call the service routine for one of them and (on return from your interrupt routine) will see that another interrupt is pending and call it. So the mcu does the prioritisation. So, as long as your interrupt routines are short, then nothing will get lost (and effects on your PWM will be brief if the UART code is called first and is quick).

If your interrupt routines are too long say: responding to a UART receive, then further 'receives' may get lost if you are processing one. So keep'em brief an all is fine.