Matrix user forums

Wrong !

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

Hello,

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

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.

Hello,

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

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.

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

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

Here are the latest component files.

it's better
Thank You

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

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.

Hello,

I tried, it does not change ...

Change .div to a long as well.

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

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.

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.)

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

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