Go Down

Topic: SPI.transfer(int count, *byte); //instead of SPI_CONTINUE (Read 1 time) previous topic - next topic

poodull

I really can't understand the logic behind the method signature of the new 'extended spi' functionality in the Due.

http://arduino.cc/en/Reference/DueExtendedSPI

There are really 3 issues I can't get along with:

1) I don't think forcing the CS pin as a parameter is good practice for standardization and will make libraries from 3rd parties even harder and more fractured than they are today.  I understand why it is there, but it would be better to use an instance of SPI (like SPI0, SPI1, SPI2).
Code: [Select]
SPI.transfer(4, myByte); // 4, or 10, or 52???

2) SPI_CONTINUE makes sense when you have exactly 3 items to send.  Any less and you don't need it, any more and it looks ridiculous to write out.  However, when you have n items to send, like an array of led values you'll have to loop with an extra funny line like this:

Code: [Select]
for (i=0; i < numLeds -1 ; i++) //less than AND -1???
{
    SPI.transfer(4, pixel[i], SPI_CONTINUE);
}
SPI.transfer(4,pixel[i]); //this extra line looks out of place because it is.


3) Why isn't there a single call to SPI to send an array?
Code: [Select]
SPI.transfer(int count, *byte); //instead of SPI_CONTINUE

I know the answer to all of this: write a helper library and shut up.  But I am still a very beginner with microprocessor coding and all of this is very hard for even me to understand... Which pin is CS, SK, MISO, MOSI, SPI, DSPI, etc.  I am imagining the others that are/will be left behind with this trying to figure out why this simple adafruit code doesn't work for their awesome Due.

The only thing (so far) I like about the Max32 is this DSPI interface.  It is very straight forward:

*) DSPI is broken up into 4 objects for each of the DSPI pins: DSPI0, DSPI1, DSPI2, DSPI3 (not static)
*) you set the actual speed you want in Hz, not some arbitrary clock scaler
*) send an entire array with spi.transfer(count, pointer);
*) send spi data asynchronously without having to figure out interrupts (which by themselves are a total nightmare, completely undocumented in almost every board I know of and even if it is, it's written so only master ECEs can understand it)

Anyway, I know this might put a few people off.  My concerns are simple and I think can be unilaterally understood:  Beginners will have some issues with this SPI usage AND advanced users who write libraries for beginners will have some issues utilizing this api cleanly.

unless I'm missing something.

Go Up