PWM Arduino MEGA

[cubitus54]

Wrong !

PWM.gif

(63.46 KiB) Downloaded 2593 times

[Benj]

Hello,

Is your clock speed setup correctly in the project options? If you do a one second flasher loop then are the delays on the hardware coming out as 1 second?

http://www.flowcode.co.uk/wiki/index.php ... ED_flasher

[cubitus54]

Hello,

On the cards Adruino Mega (2560 R3) the clock is set to 16MHz it can not be changed in "projet"

projet.gif (15.43 KiB) Viewed 10819 times

[Benj]

Hello,

Looking at the ATMEGA2650 datasheet the equation is like this.

FoscPWM = 16000000 / (2 * 1 * 101) = 12.625us Period

However if your hardware is running differently then it could be we have missed something. I will see if I can dig out a Arduino Mega 2560 to test.

[cubitus54]

Hello,

It's more serious than that. The value "period" has no effect on the output frequency.

[Benj]

It looks like the period overflow is not working as it should be and is defaulting to 256.

16000000 / (2 * 1 * 256) = 32us Period

Looking deeper it appears that the ATMEGA2560 does not have the registers to allow for variable PWM period. I will see if we can add a warning message to the output to inform the user when this happens.

AVR_CAL_PWM.c

(19.49 KiB) Downloaded 407 times

[cubitus54]

C:\Program Files (x86)\Flowcode\V6\CAL\/AVR\AVR_CAL_PWM.c:550: error: conflicting types for 'FC_CAL_PWM_ChangePeriod_1'

[Benj]

Ah sorry yes there have been other recent PWM changes. Hmm.

Here are the latest component files.

PWM.fcpx

(7.8 KiB) Downloaded 405 times

cal_pwm.fcpx

(8.08 KiB) Downloaded 370 times

[cubitus54]

it's better
Thank You

[cubitus54]

Hello,

I made a PWM function that works.
But there is a bug that I do not understand ...

Exemple :
MX_UINT8 FCL_CS1 = (0x0);
MX_UINT16 FCL_RC = (0x0);
MX_UINT16 FCL_DIV = (0x0);

.div = 16000
.RC = (.Rapport_cyclique * .div) / 100

.RC = 8000

OCR1B = FCL_RC; Wrong (the real value is about 500 max))

If I put the value directly

OCR1B = 8000; is OK

ok.gif

(49.98 KiB) Downloaded 2524 times

nok.gif

(59.33 KiB) Downloaded 2524 times

[kersing]

Looking at the information in your message:

MX_UINT16 FCL_RC = (0x0);

That 16 bit variable can hold a value of 0 to 65535.

The formula:

.div = 16000
.RC = (.Rapport_cyclique * .div) / 100

And in your debug window:

.Rapport_cyclique = 50

This results in .RC = (50 * 16000) / 100, which means the controller will first calculate 50 * 16000 = 800000. This is very much > 65535 so the result will become 800000 % 65536 = 13568 (only the remainder is kept, the overflow is discarded), which will be divided by 100, results in .RC = 135. You need to use either a MX_UINT32 (long) for .RC or restructure the calculation to make sure the (intermediate) result does not exceed the maximum value of your data type.
Simulation is not a 100% match for what happens on the controller.

[cubitus54]

Hello,

I tried, it does not change ...

PWM.fcfx

(6.87 KiB) Downloaded 348 times

[kersing]

Change .div to a long as well.

The formula:

Code: Select all

.div = 8000000 / .Frequence

Has the same problem with .div being an 16 bit (unsigned) integer.

[cubitus54]

sorry

But I think there is no problem ...

What matters here is the result variable div, the result of the operation will not exceed 16 bits.

[kersing]

Try it to make sure you are right.

Or take a look at the generated assembler code to make sure that is not a problem. I think you will find the compiler generates a sequence where it loads the (too large) value in a 16 bit register and perform the division next. (Another solution could be to use 8000000l in the formula to force the compiler to use 32 bit while performing the calculation.)

[cubitus54]

OK. Sorry! You were right: oops:: roll:

To make this work we had put in the 32-bit variable .div