Ok, I feel the need to get on the SoapBox again, because I'm currently working with Swing UI and pin control.
I have made tonnes of mistakes, the stuff I'm refactoring now could be a shiney example of what "not to do". With that said, I think Arduio's following functions were a mistake :
- digitalWrite
- analogWrite
- digitalRead
- analogRead
- pinMode
Linux & C from the beginning of time have had
- read
- write
One of Linux & C's success is the simplicity of "everything" having the same capability of reading and writing. They do not have 'special' reads and writes. This is true for 'everything' Linux can see - you can 'read' or 'write' to any device.
Arduino has chosen to create digitalWrite & analogWrite. Why the added complexity ? Shouldn't I just be able to write the appropriate value weather its 1 or 255 ? And why do I need to use the correct PinMode if I'm reading or writing. Isn't the fact that I'm doing one of these functions gif enough information for the pin to put itself in the correct state ?
Imagine the amount of children eaten by Raptors, if Linux did not maintain its wonderful standardization. We need to close the door, is that digitalWrite or analogWrite ? Was the pinmode set ? Gaahhh! Munch Munch Munch....
Perhaps MRL should offer a read & write which hide these complexities ?
I looked up BeagleBoard's pin calls and they do it the 'same' way .. Whyyyyyyy !
PIN Read and Write and Pin Modes
I'm OK with added methods for read and write, but the old methods still need to remain, since so many are already using them,
And of you want to do it good, i2c read/writes and SPI read/writes should be built the same way.
So for read and writes, some type of open/close statement would be needed, to specify if it's a pin/bus/port that you are reading/writing to.
Aye .. I have no intention of
Aye .. I have no intention of removing the complexity, but it would be nice for a way around it if desired..
Old school is a good
Old school is a good school
open close write read ... to me these make sense
I think I might understand what the Arduino group was trying to do now on closer inspection ..
The problem is the overlap of the value "1"
PWM 0 & Digital 0 overlap - but effectively mean the same thing
PWM 1 & Digital 1 - have very different meanings
Anything > 1 - there is no overlap - it has to be PWM
Problems like this could be solved by reading or writing to a different address value, but I could understand them no wanting to make things more confusing where 1 pin is accessed by 2 address values.
And then I guess digitalRead & analogRead to make it symmetric