It is brilliant - lock it down.

Smiley,

Good points and I partly/mostly agree. Your post brings up a long held concern of mine that I'll contribute here rather than start a new thread.

That is:

I think it is important that new/intermediate users are aware of and understand, at least in the broad outlines, what is being simplified for them and what they are being shielded from. It doesn't have to be understood at first, or even in any great detail but the context should be there/presented so that the scope of learning and experience is not limited to 'Arduino' but can be scaled to a larger context.

This can be handled through documentation and overview type content. The Arduino project is very enabling and easy to work with. This is its brilliance. My concern is that having been buffered from the underlying complexity, users become locked into or see only the Arduino way of things. Said another way, I think the Arduino project should provide for users growing beyond Arduino, should they choose or need to.

It could be argued (if one agrees with this POV) that this task is best served by 3rd party books/sites. I would agree to an extent but I think there is a place/need on the Arduino site/within the docs to describe and detail what is being done (simplified), what the trade-offs are, and where limitations might be encountered. Also what some 'next steps' might be. This is not the sort of thing one does (or even can do) while a project is being developed but I think it is completely in scope and appropriate to an Arduino 1.0 milestone.

Oh, and I'd like line numbers displayed in the IDE :wink:

I'm picturing a workshop where an artist asks, 'What's that PWM mean?' and the teacher says 'Pulse Width Modulation, we'll get to that after the break.' What are the chances that the artist might just not come back? And I'm not picking on artists, just trying to further dramatize a metaphor.

Hey! I'm an artist! :slight_smile:

I think 'analogWrite' is right on.. (sorry). It pairs with 'digitalWrite' and that is the point/contrast/teachable moment. 'pwmWrite' is just acronym obscure. Engineers seem to love acronyms and abhor verbosity (or typing..) but neither are good for learners.

given that the term pwm is almost instantly used to describe the function of the "analog" write I see it both ways

"how do I use analog write? connect to a pwm pin, wth is a pwm pin? I want analog, bah!"

And when the day comes where the Arduino IDE decides to support some newer AVR chip that has on-board DAC outputs, I wonder what the command to output a specific value will be called?

Maybe call it realAnalogWrite(), or maybe notpwmAnalogWrite() :wink:

Lefty

dont be silly

it will be clearly labeled as multichannel-pwm-not-analog-analog-output / digital pin 23

(i jest of course)

aside from some ide request / bugs, and some syntax I think the system is all right :wink:

When I first started, as a complete electronic novice, the "analogWrite()" completely threw me. I was thinking of analog as inputs, and I didn't get what it was supposed to do. Luckily, I took a peek in the reference, and understood, but I do feel it would be easier if it were labeled "pwmWrite()".

Smiley: thanks for the comments.

Don't worry, the intention is not to add a bunch of new features or totally redesign / re-implement the interface. It's more of a clear milestone / version at which to tweak a few things that might not be backwards compatible, and to be deliberate about the design. Kind of like Python 3.0, for those that know it.

Renaming analogWrite() is of the right scope, although I personally would be inclined not to.

As a newbie and a person who is NOT a programmer at all, but am amazed at being able to actually "do" things with an Arduino - let me chime in on this thread...

I totally agree with Smiley's viewpoint on keeping the Arduino simple for us dumb folks who do not know programming. I do not wish to limit the upward movement of Arduinos, but keep at least one simple system for us.

I do sorta like pwmWrite() rather than analogWrite() - just makes more sense.... but I do understand it could open a whole can of worms in trying keep backwards Compatibility, so what ya'll folks come up with - I'll learn to deal with.... as in loosing my hex files into those darn temperatory folders with the move to 0018.

Thank ya'll for all the work.

Ken H>

Renaming analogWrite() is of the right scope, although I personally would be inclined not to.

mellis:

Far be it for me to say to you how to take this project, but rather than renaming it, could you just add another wrapper function around analogWrite() called pwmWrite()?

Or, alternatively, add a copy of the analogWrite() function named pwmWrite()?

I personally hate the second option, as it means duplicated code, but at the same time (although I don't know for sure), would a wrapper introduce more overhead on calls to the function because of the two levels of "indirection"? Or is the compiler smart enough to know what to do to eliminate this?

If not, you could make the function be called some other name, and make analogWrite() and pwmWrite() wrapper functions (at least then one wouldn't be slower than the other).

Then, in the documentation on the site and in the IDE, note that the analogWrite() function name is deprecated, and will no longer be supported in future versions, and that programmers should transition their code (where needed) to the new pwmWrite() function...

:slight_smile:

is the compiler smart enough to know what to do to eliminate this?

Yes, the compiler is smart enough not to include code that is not called, so a duplicated function with a different name would not add any overhead (assuming only one of the function names was called in a sketch).

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.

There is so much code out there using analogWrite that this should continue to be supported. But I expect many non-technical people would prefer to be introduced to a new function named something like pwmWrite that is clearly explained, rather than glancing at analogWrite and expecting it to behave like an output version of analogRead.

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. :wink:

Lefty

Smiley

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 :slight_smile:

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

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.

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

gbulmer,

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!

.andy