next topic »

[on:]

Im looking at the wiring_analog.c file and I noticed that if val == 0 it outputs LOW as a digital signal and if val == 255 the output is digital HIGH. I see that if val is not 0 or 255, it goes to the timer. Usually we need to map the input signal to 0 and 255 because you get weird data if the input is less than or greater than 0 and 255.

Why not make set a limit in the wiring_analog.c file, instead of val == 0 (LOW) or val == 255 (HIGH), make it val <= 0 (LOW) and val >= 255 (HIGH).
My reason I noticed that when I mapped my data, I still for some reason got out numbers greater and less than what I wanted to get.

Example, controlling two independent motors from one value ranging -255 and 255, negative number would represent reverse and likewise for positive.

So I did,

DRVFor = map(Drive, 0,255,0, 255); // not really needed
DRVRev = map(Drive, -255,0,0,255);
MotorFor = analogWrite(9, DRVFor);
MotorRev = analogWrite(6, DRVRev);

But when the I did a print out of the Motor1 & 2, this is what I noticed.  When Drive was less than 0, MotorFor was a negative number and when Drive was greater than 0, MotorRev was negative. Why is that?

So this was when I checked the analog Read/Write file.

In the end, I changed my code and used an IF/ELSE statement, but it's still weird to see that if a number is negative (and mapped that way), the results will be wrong. I was looking to get 0 when Drive was negative for DRVFor, but nope.

Again, it's just a suggestion.

[Reply #1 on:]

My reason I noticed that when I mapped my data, I still for some reason got out numbers greater and less than what I wanted to get.

You could always apply this function before calling analogWrite.
I don't see why a library should be subject to bloat.

[Reply #2 on:]

I don't see why a library should be subject to bloat.

Huh?

[Reply #3 on:]

Im looking at the wiring_analog.c file and I noticed that if val == 0 it outputs LOW as a digital signal and if val == 255 the output is digital HIGH. I see that if val is not 0 or 255, it goes to the timer. Usually we need to map the input signal to 0 and 255 because you get weird data if the input is less than or greater than 0 and 255.

I believe this was the result of a patch several years ago to the original analogWrite function where if you did a analogWrite(pin#,0); instead of a pure 0% duty cycle you actually got a duty cycle that had one timer bit time of HIGH. This could easily be seen with a scope on the output pin, so they decided to just patch the function to digitalWrite a hard LOW if a 0 duty cycle value was sent to the function. Not sure why the clamp for the 100% value also but I'm sure it's related to the hardware timer behaviour.

Lefty

[Reply #4 on:]

From: http://arduino.cc/en/Reference/AnalogWrite

Syntax

analogWrite(pin, value)

Parameters

pin: the pin to write to.

value: the duty cycle: between 0 (always off) and 255 (always on).

Returns

nothing

So, why are you assigning the return value to a variable?

[Reply #5 on:]

From: http://arduino.cc/en/Reference/AnalogWrite

Syntax

analogWrite(pin, value)

Parameters

pin: the pin to write to.

value: the duty cycle: between 0 (always off) and 255 (always on).

Returns

nothing

So, why are you assigning the return value to a variable?

Exactly. analogWrite() doesn't return a value, it is a void function,
so there is no telling what you get for the assignment.

In the larger picture I do think that analogWrite() should check for >= HIGH
instead of == 255 to provide a "known behavior" for values outside the real range.
This may start to be an issue as people use hard coded numbers like 255, 1023, etc
or even mapping functions that return values outside the usable range on the
different "..duino" boards and the code starts to be used on different processors
since they all may not have the same range.

For this specific case, wouldn't it be easier to use absolute value: abs() instead of map() since
there is no real need for mapping?


--- bill