Go Down

Topic: It is brilliant - lock it down. (Read 6028 times) previous topic - next topic


Feb 25, 2010, 10:22 pm Last Edit: Feb 25, 2010, 10:27 pm by roypardi Reason: 1
analogWrite may sound like a nice intuitive name but its not really very helpful because its behaviour appears odd to people that don't understand why only certain pins can be used, and only if some other library is not using them, and with values that have a different range from analogRead.

I have seen many non-technical people come unstuck when introduced to  analogWrite because they expect it to be similar to analogRead - in the same way as digitalWrite is similar to digitalRead.  

Guess I am in the minority on this but as a non-engineer I think 'analogWrite' is appropriate. Here's why I think this:

digital = on/off - binary
analog = range/continuous

True, analogWrite might be more accurately named simulationOfAnalogOutput but that is not necessary for the less technical user to understand, at least at first. PWM is the way this simulation is achieved/implemented. The PWM pins available, etc. I see as simply FOL details with specific boards.

I guess I see analogWrite in the same way as setup & loop - simplifications/higher level abstractions that are easier for new users/less technical people to grasp.

No matter - just thought I would offer this POV.


It's certainly a valid point of view. But as a number if beginners have noticed, analogWrite is not a  very good simulation of analog output if you try to read the output from analogWrite on another arduino using analogRead (or anything else that needs a true analog signal).

The simplification would be less troublesome if analogWrite did not have significant differences from the way analogRead is used.


The simplification would be less troublesome if analogWrite did not have significant differences from the way analogRead is used.

Yep, you can put lipstick on a pig but you should still call it a pig.  ;D

Sorry, I've been watching the health care debates all day and I guess it's affected me a little.  ;)




As usual you're absolutely spot on and we share the same view.
1.0 is about consolidation and making sure documentation/examples/api match and stop shifting too much so that people can teach/write books/etc without having to constantly follow the API around.

this opens the door to a more "experimental branch" where we can play more without the fear of confusing a beginner.

Thanks smiley for the kind words here and on Avr-chat where the hate for arduino is so intense it's ridiculous :)

To the rest of the people I can only say this : analogWrite stays... move on to something else :)


analogWrite stays...

I think the request is not to eliminate analogWrite but to eliminate the confusion caused by analogWrite not working the way beginning Arduino users expect it to.


How about a version of the IDEA that is pretty much as is and called it the 'Lite' version? Ideally suited for beginners.

Then the Pro version could be more advanced, i.e. a proper IDE.


To the rest of the people I can only say this : analogWrite stays... move on to something else
hmmmm so much for open source open exchange of ideas.  I haven't been around long but I reckon I've seen 3 different people come here wondering why their "analog" output is behaving strangely.


Mar 12, 2010, 04:20 am Last Edit: Mar 12, 2010, 04:27 am by gbulmer Reason: 1
Arduino is genius, but I prefer to recognise defects and decide what to do.
IMHO, the major defects were:
- printing PWM on the board, but calling it analogWrite,
- calling it analogWrite when it's a simulation of analogue, and
- the none-0.1" pin header spacing.
I really do think that is amazingly good. I wish everything were that good (we'd still moan, but that's just the "conservation of misery principle" TM in action)

To break things for cleanliness this late feels to me like "throwing the baby out with the bathwater". There seems to be little benefit, and quite a lot of damage. So Uno Punto Zero will carry these through.

So do we ever fix defects (not that I expect anyone to agree with my list)?
How do we help folks prepare for the change, and alter their existing projects to work with the new thing?
Will some changes just be too big for backward compatibility?
If we do change Arduino, what is the process, and what do we call the thing which has incompatible changes?
Is it only when crossing a major version number that all bets are off, or is their some other way to understand that incompatible changes are coming?

I feel that clearly stating guiding principles and answering these types of questions helps us decide how to best proceed.

There are some useful experiences from other Open Source projects that we can draw on. I think Arduino has extra challenges because it has physical existence too.

My $0.02



I would add the confusion of using libraries (that are not included in the standard distribution) to your list of defects highly in need of attention.

But I agree with your characterization of amazingly good!


Go Up