Pages: [1]   Go Down
Author Topic: frame size on shiftout  (Read 991 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Sr. Member
****
Karma: 0
Posts: 267
dinosaur cork
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Wuppertal/Germany
Offline Offline
God Member
*****
Karma: 1
Posts: 895
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
 

Logged

0
Offline Offline
Sr. Member
****
Karma: 0
Posts: 267
dinosaur cork
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

« Last Edit: November 24, 2007, 03:08:48 pm by paulb » Logged

Wuppertal/Germany
Offline Offline
God Member
*****
Karma: 1
Posts: 895
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Paul
Quote
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.

Quote
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.

Quote
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
Logged

Brisbane, Australia
Offline Offline
God Member
*****
Karma: 1
Posts: 593
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

0
Offline Offline
Sr. Member
****
Karma: 0
Posts: 267
dinosaur cork
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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.


Quote
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.


Quote
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 smiley

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.



Logged

Forum Administrator
Cambridge, MA
Offline Offline
Faraday Member
*****
Karma: 12
Posts: 3538
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

New Zealand
Offline Offline
God Member
*****
Karma: 0
Posts: 999
Arduino pebbles
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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.
Logged

Pages: [1]   Go Up
Jump to: