Please don't change a thing. Please don't even be tempted to seriously consider changing anything.
Featuritis (adding cool new features) is a disease and IMHO 'improvements' to Arduino risk killing it.
I don't know whether you guys designed in or stumbled upon the secret for a beginner's microcontroller, but the system 'as is' is genius.
Steve Jobs also possesses this secret and is somehow able to resist the temptation to add features to Apple products thus keeping it usable by the masses. Those of us who know a lot about embedded systems don't need any additions, we have other tools, those who are just starting out don't need to be distracted by adding any clutter.
I'm fully capable with advanced tools, but I use the Arduino all the time for quick checks on hardware prototypes. Firing up AVRStudio/WinAVR and AVRDude is a hassle and I'm glad to have a simple short cut.
I know that a lot of threads get started by folks who exhaust what the Arduino does easily and they want various changes - but IMHO they should move on to other tools and let the Arduino serve its original purpose as a platform for novices and for tinkering.
Just received my Nuts and Volts mag in the mail yessterday and see you have another Arduino project in there (part 3). Haven't had a chance to read it yet but I'm glad you continue to spread the Arduino spirit.
Actually it is the Nuts&Volts series that convinced me that the Arduino is both brilliant and in danger because of its success. I see lots of questions being asked here and on AVRFreaks from folks seem to having problems with aspects of Arduino and wanting it to do things it wasn't designed for. Arduino makes many things very easy, but these folks are expressing a real need to do things that aren't easy to do on the Arduino. So lots of folks are wanting this or that added to the Arduino and I'm afraid many of the changes I've seen proposed will rip the heart out of what made Arduino successful in the first place.
So I am urging a lock down of the good stuff and then if folks want to expand and make new features they should very cautiously explore new options that won't dilute the Arduino brand. I'm sure the core team is already well up on this, but I just want to add my voice to those who want to keep it simple.
I certainly understand what you are saying and not against leaving most alone. However analogWrite() was a brain fart name and should be renamed pwmWrite(), change in now.
I think most innovations can/should be brought on board in the form of user library additions or new example sketches rather then making them part of the 'core'. That way if you don't use it or need it, you don't have to learn about it. A good general purpose sleep library might be one example, or a general purpose watchdog timer library.
Making too many fundamental IDE or core library changes/additions probably would make the learning curve longer for new comers and not in the spirit of the original idea. Except for that damn analogWrite() name.
When I put on my engineer hat, I fully agree with you. But when I try to put myself in the place of a novice, I wonder.
You and I know what PWM means, but a novice?
One might expect smart folks who actually have a shot at learning to use the Arduino to begin without even a well-formed concept of the terms digital and analog. I think most folks kind of know that computers are digital and that the stuff that comes out of the wall socket and can kill you is analog.
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.
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
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!
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.
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()
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()".
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.
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...
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.
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.
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
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.
