Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
some type issue with AnalogWrite ?
20-06-2013, 09:56 PM,
#1
some type issue with AnalogWrite ?
I see now that, for PIC18F2550, the x.4 library assume the argument passed to the AnalogWrite function should be a u8, while previousely it was accepting integer (x.3) as it is normal for a 10 bit PWM port.

void analogwrite(u8 pin, u8 duty)

I have to rewrite my code limiting the values passed up to 255 (and it works fine). Previousely it was 1023.

something strange ? Huh
Reply
21-06-2013, 03:15 PM,
#2
RE: some type issue with AnalogWrite ?
Hello,

(20-06-2013, 09:56 PM)druilhe Wrote: I see now that, for PIC18F2550, the x.4 library assume the argument passed to the AnalogWrite function should be a u8, while previousely it was accepting integer (x.3) as it is normal for a 10 bit PWM port.

void analogwrite(u8 pin, u8 duty)

I have to rewrite my code limiting the values passed up to 255 (and it works fine). Previousely it was 1023.

there was a change in analog.c from revision 787 to 792.

r787: void analogwrite(u8 pin, u16 duty)
r792: void analogwrite(u8 pin, u8 duty)

The complete difference is here.

In the changelog is a comment from Regis: "P8: fixed analogWrite"

Maybe a change for compatibility with Arduino? I don't know...

druilhe Wrote: I have to rewrite my code limiting the values passed up to 255 (and it works fine). Previousely it was 1023.

Does your application need a resolution of 10 bits?

Oliver
Reply
22-06-2013, 12:23 PM,
#3
RE: some type issue with AnalogWrite ?
Hi Olivier,

It is not an issue, it is just that I discovered that at the last minute, while I have already tested this part of my program wilth the x.3 release, and that there were no compiler warming neitheir documentation updated.

What is the process to update the documentation ? how can I help ?

Rgrds,
Reply
22-06-2013, 03:30 PM,
#4
RE: some type issue with AnalogWrite ?
analogWrite() has been written for 10-bit PWM resolution (PR2=255 @ Fosc=48MHz, Tmr2 prescaler to 1) but, for unknown reason, it seems the previous version didn't work fine so I came back temporarily to something compatible with Arduino.

Previous version (u16 duty) :

CCP1CON = 0b00001111;
CCPR1L = duty & 0xFF; // 8 LSB
CCP1CON |= (duty >> 8) << 4; // 2 MSB in <5:4>

Actual (limited) version (u8 duty) :

CCP1CON = 0b00001100;
CCPR1L = duty;
It is easier to complain than it is to do, but it is better to do than it is to complain.
Reply
22-06-2013, 08:48 PM, (This post was last modified: 22-06-2013, 09:33 PM by druilhe.)
#5
RE: some type issue with AnalogWrite ?
Regis,
I've updated the Wiki (with u8 format). I hope it is fine for you.

Regis,

In your previous code:

Previous version (u16 duty) :

CCP1CON = 0b00001111;
CCPR1L = duty & 0xFF; // 8 LSB
CCP1CON |= (duty >> 8) << 4; // 2 MSB in <5:4>

there is no protection in case duty exceed 1023, as so it could happen that duty >> 8 been expended with "sign" negative, meaning you can have the two upper bits to 1 (in case duty >= 32768).
you should try to protect this by doing:

CCP1CON = 0b00001111;
CCPR1L = duty & 0xFF; // 8 LSB
CCP1CON |= ((duty & 0x300) >> 8) << 4; // 2 MSB in <5:4>

regards.
Reply
25-06-2013, 03:52 PM,
#6
RE: some type issue with AnalogWrite ?
You're right but then I would say (duty & 0x3FF) because PWM has 10-bit resolution.
But the problem comes from else where as you can see if you try the following example (from examples/03.Analog/Fading/Fading.pde). It seems PWM resolution is not to the max ...
Quote:u8 ledPin = 10; // LED connected to digital pin 10 (CCP1 for Pinguino 26J50)

void setup()
{
pinMode(ledPin, OUTPUT);
}

void loop()
{
// fade in from min to max in increments of 5 points:
int fadeValue;

for (fadeValue = 0 ; fadeValue <= 1023; fadeValue +=5)
{
analogWrite(ledPin, fadeValue);
delay(30);
}

// fade out from max to min in increments of 5 points:
for (fadeValue = 1023 ; fadeValue >= 0; fadeValue -=5)
{
analogWrite(ledPin, fadeValue);
delay(30);
}
}

Let's try together to make analogWrite work.
So, you know analogWrite() uses PWM module and the maximum PWM resolution (bits) for a given PWM frequency is given by the equation :

PWM Resolution (max) = Log ( Fosc / Fpwm ) / Log ( 2 )

If 10-bit (max) resolution is needed, then Fpwm must be <= Fosc / 1024.
For ex. if Fosc = 48 MHz then Fpwm must be <= 46875 Hz

If Fosc = 48 MHz and Fpwm = 46875 Hz and Prescaler = 1, then :
PWM Period = 1 / Fpwm = [(PR2) + 1] • 4 • TOSC •(TMR2 Prescale Value)
PR2 = ( Fosc / Fpwm / 4 / TMR2 Prescale Value ) - 1
PR2 = 255

So if PR2=255 then we get max. PWM resolution.
Do you agree with it or did I make a mistake somewhere ?
It is easier to complain than it is to do, but it is better to do than it is to complain.
Reply
25-06-2013, 06:45 PM,
#7
RE: some type issue with AnalogWrite ?
Ok, forget about what I said, I think I fixed it. Do you want to try this :

CCP1CON = 0b00001100;
CCPR1L = ( duty >> 2 ) & 0xFF; // 8 LSB
CCP1CON |= ( (duty & 0x300) >> 8) << 4; // 2 MSB in <5:4>

If it works for you I will commit it soon ...
Anyway, thank you for your help.
It is easier to complain than it is to do, but it is better to do than it is to complain.
Reply
26-06-2013, 08:56 AM,
#8
RE: some type issue with AnalogWrite ?
Sorry to interfere (and you may call me a nit-picker or VERY old-school), but why that back-and-forth shifting? I see no sign issues (and very likely the compiler would optimize this on its own, so possibly for readability?), but since the relevant bits are already masked out, (x>>8)<<4 should be pretty much the same as x>>4. OK, I AM a nit-picker.
Reply
26-06-2013, 10:05 AM,
#9
RE: some type issue with AnalogWrite ?
Yes, off course, you're absolutely right Blush. Thanks.

(26-06-2013, 08:56 AM)trollpatsch Wrote: Sorry to interfere (and you may call me a nit-picker or VERY old-school), but why that back-and-forth shifting? I see no sign issues (and very likely the compiler would optimize this on its own, so possibly for readability?), but since the relevant bits are already masked out, (x>>8)<<4 should be pretty much the same as x>>4. OK, I AM a nit-picker.
It is easier to complain than it is to do, but it is better to do than it is to complain.
Reply
29-12-2013, 10:38 PM,
#10
RE: some type issue with AnalogWrite ?
Hi !

I reply to this (quite) old thread because I'm a new Pinguino user and I discovered that 10 bits resolution is back in the current version.

However, it is not Arduino compatible... Arduino uses (for Due model) two new functions : analogWriteResolution(bits) and (for analogRead() for which the same issue occurs) analogReadResolution(bits).

If Arduino compatibility is a objective, couldn't this be a solution ?

Just my 2 cents,

Ajaborsk

(21-06-2013, 03:15 PM)pinguPlus Wrote: Hello,

(20-06-2013, 09:56 PM)druilhe Wrote: I see now that, for PIC18F2550, the x.4 library assume the argument passed to the AnalogWrite function should be a u8, while previousely it was accepting integer (x.3) as it is normal for a 10 bit PWM port.

void analogwrite(u8 pin, u8 duty)

I have to rewrite my code limiting the values passed up to 255 (and it works fine). Previousely it was 1023.

there was a change in analog.c from revision 787 to 792.

r787: void analogwrite(u8 pin, u16 duty)
r792: void analogwrite(u8 pin, u8 duty)

The complete difference is here.

In the changelog is a comment from Regis: "P8: fixed analogWrite"

Maybe a change for compatibility with Arduino? I don't know...

druilhe Wrote: I have to rewrite my code limiting the values passed up to 255 (and it works fine). Previousely it was 1023.

Does your application need a resolution of 10 bits?

Oliver
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)