How about adding an optional frame size parameter to shiftout in Arduino0011. This would be convenient with ints, and there are some chips, such as the 5940? PWM LED driver chip that have odd frame sizes. Right now this would require checking the code and writing your own function.
Paul
Hi paul,
the problem with the TLC5940 is not really an odd framesize (96 or 192bits fit nicely in 8bit frames), its the clock-signal that is at 0V on idle with the shiftout function. True SPI-interfaces let you setup the idle value of the clock (low vs. high).
With shiftOut() the clock is fixed to HIGH. This will probably lead to a wrong timing on the TLC5940.
I guess you know that you can use the Hardware SPI-feature of the Arduino instead which allows to set the clocks idle state.
But I'm curious, are there really devices that use a bit-length that does not fit into the 8bit scheme of a byte?
Eberhard
Eberhard.
I know I've used something with an 11 or 12 bit frame size, but I am at a loss to remember what it was.
It would also be handy for beginners to output an int without having to bitshift high and low bytes - somewhat tricky since it has to be done differently with MSB and LSB schemes. Somehow the framesize option found it's way into the Basic Stamp and other easy-to-use micros. I think the BASIC Atom even implemented some clock control options.
As to the SPI hardware - I haven't puzzled my way through this, but would love to see this implemented in shiftout asap.
Advantages:
fast
flexible
frees up processor by using on-board hardware
Disadvantages:
???
One quirk is that it uses pin 13 which has an LED on it in some hardware implementations. Still the AVR outputs have really impressive ability to source and sink current so this shouldn't be a big deal, as long as the LED's have series resistors.
Paul
Hi Paul
It would also be handy for beginners to output an int without having to bitshift high and low bytes - somewhat tricky since it has to be done differently with MSB and LSB schemes.
Seems to be a good idea initially, but almost every documentation or tutorial on SPI-devices uses bytes or arrays of bytes.
Since ints and ints are so different nowadays (2bytes - 8 bytes long) using the plain byte as common currency (in documentation) is the easiest way.
Somehow the framesize option found it's way into the Basic Stamp and other easy-to-use micros. I think the BASIC Atom even implemented some clock control options.
But it would add another parameter to the function, that has to be documented and explained.
As to the SPI hardware - I haven't puzzled my way through this, but would love to see this implemented in shiftout asap.
With CPOL anfd CPHA there would be 2 more params. Now we would already need a setup-function.
Hardware SPI is always available. You actually need it, when you deal with devices that not only receive, but also send data. (EEProms, ADC's DAC's etc.).
I think a library for Hardware-SPI would be a good idea, and should not be to difficult to create.
Could you do some testdrives with your TLC5940 when I send you some code?
Eberhard
Odd frame sizes is only a tiny edit to the code and is rare so I dont see any point to building it in.
Anyone requiring it can easily do it.
But it would add another parameter to the function, that has to be documented and explained.
How about optional parameter with default being byte. Such as C++ style optional param on random.
Since ints and ints are so different nowadays (2bytes - 8 bytes long)
Arduino ints aren't going to change anytime soon. I wouldn't argue for 8 bits not being default.
Odd frame sizes is only a tiny edit to the code and is rare so I dont see any point to building it in.
Anyone requiring it can easily do it.
Most users aren't going to want to fuss with "wiring.c" or have to copy and paste function contents. As I said earlier it would help out beginners avoid the low-byte / highbyte fuss of outputting ints. Such as when using 16 bit driver chips 
More flexibility == easy-to-use microC platform. One might mistake this slogan as an add for the Basic Stamp.
These are trivial fixes which collectively help round out rough edges in the language.
It seems reasonable to add another parameters that specifies the number of bits - probably defaulting to 8. Paul, do you want to email the developers list with the suggestion? I'd like to discuss these kinds of changes there before incorporating them into the code.
I think a library for Hardware-SPI would be a good idea, and should not be to difficult to create.
xSmurf has been working on a Hardware-SPI library, not sure where it's at currently.
--Phil.