shiftOut() docs should not reference SPI

The shiftOut() reference seems to claim to be SPI. This should be corrected; not only does it not use the ATmega SPI hardware, it doesn’t even have MISO (master-in-slave-out, i.e. the serial data input from the peripheral).


Good point. I deleted that sentence.

Sorry to tag onto this thread (doesn't seem worth a new one), but I have some other proposed minor documentation cleanups.

The main reference page mentions 11 data types, however the variable declaration page only lists 9 data types. The boolean type and arrays and strings are missing.

This leads to the next issue, why are pointers not mentioned, are they simply too complex?

Further along, the boolean page does not give any indication of the data size (1 byte assumed). Also, it starts with this sentence "boolean variables are hold one of two values, true and false." There seems to be an extra word "are" in there.

Moving along to row two of the reference page brings us to the functions. Many of these references do not declare the types of various arguments. Perhaps it is felt that in some cases, in particular when constants are meant to be passed in, that this is not necessary? However, this makes it hard for someone to create another function which calls one of these functions and then needs to accept that same parameter. To further compound the problem, this page which is linked to continues to obfuscate the types. Which, of course, leads us to the next dilema, :) but before we move on, more on this one: perhaps that Constants page should also be linked to from the shiftOut() page and the MSBFIRST and LSBFIRST constants should be described there?

Some of these arguments take new types uint8_t!!! Why new types? Why not explain these types?

All of this leads me to ask, are the docs a wiki, because I do not see a way to modify them? If not, why not? These types of simple fixes should be encouraged by users/readers, shouldn't they?

Lastly, this one is more of a library design issue than a docs issue, but why not provide a digitalSetPullup () function instead of overloading the digitalWrite() function to do this? I understand that this is probably how the Atmel chip works, but it seems like this should be mostly hidden from arduino users in the normal development environment. Adding a simple function to make this more explicit and clear to newbie users seems more inline with the arduino objectives.

I know this was a laundry list, but they are mostly minor issues. Thanks for the great environment.