next topic »

[on:]

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:

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:

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:

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.