i found this detailed tutorial on the arduino site about how to turn any digital pin in to a PWM pin
http://arduino.cc/en/Tutorial/SecretsOfArduinoPWM
i was wondering how one would do this on the maple.
ideally i would need some sort of PWM control on 16 pins.
thanks for any advice. stephan
gbulmer
Moderator
stephanschulz - IIRC Maple has 15 hardware PWM pins, so writing code to generate PWM is less necessary than on the Arduino, which only has 6 PWM outputs.
If you really only need 16 PWMs, and can use the Maples 15 hardware PWM pins, then the code example at that link:
void setup()
{
pinMode(13, OUTPUT);
}
void loop()
{
digitalWrite(13, HIGH);
delayMicroseconds(100); // Approximately 10% duty cycle @ 1KHz
digitalWrite(13, LOW);
delayMicroseconds(1000 - 100);
}Would give the 16th.
If this isn't enough PWM outputs, then you are going to have to write some more sophisticated code.
How experienced are you at writing embedded C?
It might help you judge by reading the following approaches.
If you want far more PWMs than there are PWM pins, then here are several basic techniques:
1. Event-based simulation (http://en.wikipedia.org/wiki/Discrete_event_simulation)
If you imagine you have the schedule (time) when each PWM pin is going to change, sorted by increasing time, you can set an alarm to "wake up" on the next scheduled pin change. The "alarm" is triggered by a timer, set to go off at that pin-change time in the future, and the "wake up" is done by an interrupt service routine which toggles the pin(s) scheduled to change at that time.
2. 'Continuous' simulation (http://en.wikipedia.org/wiki/Continuous_simulation)
Imagine the PWM resolution is like an Arduino (4us), with 256 'time slices' to make a 1ms cycle.
Declare an array of short int (16 bits), pwmbits[256]; where the nth bit controls the nth PWM pin.
Maintain the PWM pattern for all pins in that array, so analogueWrite(7, 23); would set, say, the 7th bit of every entry in pwmbits[], in this case the first 23 array entries would have a 1 in bit position 7, and the other 233 (256-23) would be 0.
Copy a an element from pwmbits[i]; to a 16bit port every 4us. So all 16 pins of the port are outputting a PWM signal.
Edit. Copying pwmbits[i] to the GPIO port would be executed in an interrupt service routine, triggered by a timer.
Improvement 1, do the copying with a Maple DMA controller, so this all happens without any CPU (software) activity.
Improvement 2, maintain several arrays, one per 16 bit port, and use all of the pins as PWM pins.
3 Combine the two techniques. IMHO this is tricky, and unlikely to give significant benefits.
4. SPI is a shift register, so the data-out pin sends 8bits at a time as a serial bit stream. Feed 256 bits (unsigned char bits[32];) into an SPI peripheral and it will generate a pulse train (and hence could do more things than simple PWM).
An analogueWrite(pin, value); would set the 256 bits in bits[] to have value 1s, and 256-value 0s. Use an interrupt routine to feed a byte from bits[] into the SPI peripheral. There are two SPI peripherals, so this gives 2 PWM pins.
Improvement 1. use a DMA controller to transfer bits[] into the SPI peripheral, hence their is no CPU (software) involvement once the equivalent of analogueWrite() has initialised the array
(Full Disclosure: I am not a member of LeafLabs staff)
thanks for the reply.
i am using the maple mini which only has 12 pwm pins.
your suggested code would it create flicker is i use the serial or other interrupt suff?
thx
maybe there is a way to use one of the hardware timers???
gbulmer
Moderator
stephanschulz - "i am using the maple mini which only has 12 pwm pins."
Ooops, sorry.
"your suggested code would it create flicker is i use the serial or other interrupt suff?"
I am not sure what you mean by flicker. If you mean might there me extra PWM signal changes, which might visualy look like flicke (or be observed using an oscilloscope), then no, there would be no extra signal changes.
If you mean might the number of PWM signal changes be correct, but the duration of a PWM signal might not be exactly what it would be if it were generated by a hardware timer (i.e. measured on an oscilloscope), that is often called 'jitter'.
Yes, depending on the priority of interrupts, signals may jitter. You may theoretically be able to control that on Maple, by changing interrupt priority, and hence may be able to order the interrupt priorities so the time sensitive signals do not jitter. However that adds an extra dimension of complexity which you might (reasonably:-) want to avoid.
This is partly why I mentioned using DMA. Even using DMA to load data from SRAM into GPIO registers may have jitter, but it should be of the order of a few cycles, I guess much less than 100ns (even then, only when contending with the CPU for buses), and so smaller magnitude, than the potential scale of jitter caused by higher interrupt priorities, which is the duration of the interrupt service routine (i.e. maybe us). If the time slice of PWM is 4us, then less than 100ns is under 2.5%, and compared to the 1ms cycle for PWM is 0.01%.
How accurate must the PWM duration be?
"maybe there is a way to use one of the hardware timers???"
PWM is generated by the hardware timers, so should I assume you are asking if PWM 'simulation' could be driven by a hardware timer?
In their simple forms, approach 1, 2 and 3 (as posted in my response) are triggered by a hardware timer.
For 256 level PWM at 1ms cycle, the difference between 1 and 2 is whether you set the timer to trigger every 4us (option 2) , or on the next change of a PWM pin (option 1). As you only want 5 extra PWM pins (use one timer channel to trigger the interrupt service routine), setting the clock to trigger at the next actual pin change is much more efficient because that only generates 6 interrupts/msecond vs 256 interrupts/msecond. However, option 2 (256 'events'/millisecond) can be much more easily turned into a DMA driven mechanism, which needs no processor time at all once the array of bits to control the ports is set up, though it does contend for buses 256 times in every 72,000 cycles.
since i am new to maple i am not sure how to implement the hardware timer correctly; i.e. .setPeriod .setOverflow ...
i would greatly appreciate some example code.
thanks a lot.
gbulmer
Moderator
stephanschulz - "since i am new to maple i am not sure how to implement the hardware timer correctly; i.e. .setPeriod .setOverflow ..."
So the documentation at http://leaflabs.com/docs/lang/api/hardwaretimer.html#lang-hardwaretimer
isn't sufficient?
The wonderful thing about MCU-boards like Arduino and Maple, is the libraries enable you to do simple experiments. Only using the on-board LED and printing messages up the serial monitor, it is practical to learn quite a lot. It is pretty safe to use those, and there is no need for extra electronics.
Also, you could find some examples of people asking for explanations by using the Search at the top right of every page. Search for setPeriod, setOverflow, etc
As an example, their is https://github.com/leaflabs/projects/tree/master/thx/thx_pwm
mentioned on thread http://forums.leaflabs.com/topic.php?id=863
(Full Disclosure: I am not a member of LeafLabs staff)
thanks for pointing me to the thx_pwm example.
i made this like test code based on the example.
next step is making 16 independent LEDs.
boolean ledState = false;
unsigned int counter = 0;
unsigned long myTimer = 0;
int dim = 0;
int dir = 1;
void handler_t(void) {
if(dim < counter){
ledState = true;
}
else{
ledState = false;
}
digitalWrite(5,ledState);
digitalWrite(12,ledState);
digitalWrite(14,ledState);
digitalWrite(20,ledState);
counter++;
if(counter > 50) counter = 0;
}
void setup(void) {
pinMode(5,OUTPUT);
pinMode(12,OUTPUT);
pinMode(14,OUTPUT);
pinMode(20,OUTPUT);
pinMode(BOARD_LED_PIN,OUTPUT);
Timer2.setPrescaleFactor(1);
Timer2.setOverflow(500); //1079);
//Timer2.setCompare1(1); // overflow might be small
Timer2.attachCompare1Interrupt(handler_t);
SerialUSB.println("done setup");
}
void loop(void) {
if(millis() - myTimer > 15){
myTimer = millis();
toggleLED();
dim = dim + dir;
if(dim > 50 || dim == 0) dir = dir * -1;
}
}
gbulmer
Moderator
stephanschulz - Good progress.
Let me offer a few suggestions.
An idiomatic way of changing the sign of a number is dir = -dir;
Do you understand the meaning of the type qualifier volatile?
There are a bunch of places that explain its meaning, for example:
http://publications.gbdirect.co.uk/c_book/chapter8/const_and_volatile.html
You will need to apply volatile to variable definitions to reliably communicate values to the interrupt handler.
It is possible to directly set the state of a GPIO pin if you know its address, e.g. *PORTD_PIN5 = ledState;
This runs in about 1/20th (maybe faster) the time of a digitalWrite().
Hence using it in the interrupt handler would drastically reduce the time spent servicing the timer interrupt.
Further, upto 16pins, in the same port, can be written in one assignment. That would ensure the PWM signal for multiple pins would be synchronised.
This isn't relevant now, but might become useful. There are several threads on the forum about using that technique, and you might want to resurrect one if it isn't clear.
here my progress.
i have an array of 16 pins that each are at a different dimming stage.
i found one solution to gbulmer suggestion for eliminating the digitalWrite(). which is using gpio_write_bit(GPIOA, LED_BIT_ARRAY[i],dimStates[i]);
next would be to look in to writing to the whole port at once.
#include <gpio.h>
volatile unsigned int counter = 0;
unsigned long myTimer = 0;
int dim = 0;
int dir = 1;
int ledAmt = 16;
int counterLimit = 160;
boolean dimStates [] = {
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
volatile int dimValue [] = {
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
const char ledPin[] = {
15,16,17,18,19,20,21,22,27,28,29,30,31,0,1,6};
const int LED_PORTref_ARRAY[] = {
1,1,1,1,1,0,0,0,0,1,1,1,1,1,1,0};
const int LED_BIT_ARRAY[] = {
7,6,5,4,3,15,14,13,8,15,14,13,12,11,10,5};
//15 ,16 ,17 ,18 ,19 ,20 ,21 ,22 ,27 ,28 ,29 ,30 ,31 ,0 ,1 ,6
//b7 ,b6 ,b5 ,b4 ,b3 ,a15 ,a14 ,a13 ,a8 ,b15 ,b14 ,b13 ,b12 ,b11 ,b10 ,a5
int dimDir [] = {
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1};
void handler_t(void) {
for(int i=0; i<ledAmt; i++){
if(dimValue[i] > counter){
dimStates[i] = true;
}
else{
dimStates[i] = false;
}
if(LED_PORTref_ARRAY[i] == 0) gpio_write_bit(GPIOA, LED_BIT_ARRAY[i],dimStates[i]);
if(LED_PORTref_ARRAY[i] == 1) gpio_write_bit(GPIOB, LED_BIT_ARRAY[i],dimStates[i]);
//digitalWrite(ledPin[i],dimStates[i]);
}
counter++;
if(counter > counterLimit) counter = 0;
}
void setup(void) {
for(int i=0; i<ledAmt; i++){
pinMode(ledPin[i],OUTPUT);
dimValue[i] = counterLimit/ledAmt * i;
}
pinMode(BOARD_LED_PIN,OUTPUT);
Timer2.setPrescaleFactor(1);
Timer2.setOverflow(500); //1079);
Timer2.attachCompare1Interrupt(handler_t);
}
void loop(void) {
if(millis() - myTimer > 15){
myTimer = millis();
toggleLED();
for(int i=0; i<ledAmt; i++){
dimValue[i] += dimDir[i];
if(dimValue[i] > counterLimit || dimValue[i] == 0) dimDir[i] = -dimDir[i];
}
}
}
gbulmer
Moderator
stephanschulz - I would suggest trying to slow everything, and use digitalWrite() to get something working.
Once speed matters, you might want to look at an approach to quickly changing a pin:
http://forums.leaflabs.com/topic.php?id=737#post-22300
to clarify the code i posted works fine. so no need to go back to use digitalWrite()
i was even thinking of replacing the gpio_write_bit with gpio_toggle_bit which mean i don't have to store the bit state.
You must log in to post.