Hello fellow Due users, what a fantastic board this thing is!
The SPI docs here:
say that the MOSI, MISO, and SCK pins on the Due are ICSP-4, ICSP-1, and ICSP-3 respectively. Really? If that's so, how do you access the actual SPI port on the Due using the SPI library. My understanding was that it would be bad idea to use the ICSP header because it is used for the interaction between the FTDI USB/serial conversion chip and the SAM3X chip.
Actually the SAM is not programmed through ICSP like the AVR Arduinos. So that is the only header they designed to access those pins. They have also provided extended SPI functions at http://arduino.cc/en/Reference/DueExtendedSPI
There is a bit more consolidated info at The 21st Century Digital Home: Arduino Due Hardware SPI
Also see this post Summary of mysteries about SPI and extended SPI library with Due - Arduino Due - Arduino Forum
I'm programming it through the "Programming" port which uses the FTDI chip on the board and very clearly has traces that are connected directly to the ICSP labeled header on the board near the FTDI chip.
Surprisingly, I have already read the 21stdigitalhome page but not the other Arduino form link posting you provided. I'm wondering if I made my question clear because the answer I'm looking for is about resolving a conflict that I see in the documentation versus what I'm seeing on those sites.
There are TWO headers on the Due board. One of them is located just behind the FTDI adapter chip and is labeled ICSP. I assumed this corresponded with the pin definitions in the documentation at the link I provided as ICSP-x (see 1st post above.) The other is located immediate adjacent to the SAM3X chip next to the infinity symbol and Arduino Due logo silk-screened onto the top side of the board. What is not clear to me is which one of these two the SPI library actually uses. The 21stdigitalhome link leads me to believe the latter, but the docs lead me to believe the former. I really am just trying to use SPI is all 
exedor:
I'm programming it through the "Programming" port which uses the FTDI chip on the board and very clearly has traces that are connected directly to the ICSP labeled header on the board near the FTDI chip.Surprisingly, I have already read the 21stdigitalhome page but not the other Arduino form link posting you provided. I'm wondering if I made my question clear because the answer I'm looking for is about resolving a conflict that I see in the documentation versus what I'm seeing on those sites.
There are TWO headers on the Due board. One of them is located just behind the FTDI adapter chip and is labeled ICSP. I assumed this corresponded with the pin definitions in the documentation at the link I provided as ICSP-x (see 1st post above.) The other is located immediate adjacent to the SAM3X chip next to the infinity symbol and Arduino Due logo silk-screened onto the top side of the board. What is not clear to me is which one of these two the SPI library actually uses. The 21stdigitalhome link leads me to believe the latter, but the docs lead me to believe the former. I really am just trying to use SPI is all
I am using SPI for two Adafruit thermocouple boards, I am using SPI library with SPI header that is next to the SAM chip and labeled SPI. I am also using PWM Pin 4 and PWM Pin 10 for chip select. I have not had any trouble.
Also, following installation instructions, I am not using FTDI driver:
"Navigate to the folder with the Arduino IDE you downloaded and unzipped earlier. Locate and select the “Drivers” folder in the main Arduino folder (not the “FTDI USB Drivers” sub-directory). Press “OK” and “Next” to proceed."
I am not sure why you are using FTDI driver.
One of them is located just behind the FTDI adapter chip and is labeled ICSP
The Due does not have an FTDI chip, it uses an Atmega16u2. The first header you refer to is a programming header for this Mega should you even need to reflash it.
The other is located immediate adjacent to the SAM3X chip next to the infinity symbol and Arduino Due logo silk-screened onto the top side of the board.
This is the actual SPI header and AFAIK the only access you have to the SPI port and therefore this is the header used by the SPI libraries.
Rob
The Due does not have an FTDI chip, it uses an Atmega16u2. The first header you refer to is a programming header for this Mega should you even need to reflash it.
Thanks for the clarification...that's what I meant. I'm not using the FTDI driver. I'm using the correct driver.
This is the actual SPI header and AFAIK the only access you have to the SPI port and therefore this is the header used by the SPI libraries.
Thanks, that's how I actually understood it. The docs threw me. So the docs are in error then? When they say ICSP-x for ISP pin assignment with ISP on the Due it really means ISP-x.
So the docs are in error then?
I would say so, probably a cut-n-paste from the Mega or something where that header was ICSP as well as SPI.
I gather you are referring to the small graphic that shows the pinout of the header, the fact that the "ICSP" label almost matches the location on the board (relative to the header, EI below whereas the SPI label is above) makes it really seem to refer to the 16U programming port and not the SPI header.
Rob
Yes, you got it. There are two clues. The fact that the pin-out diagram of the header on the doc page does say ICSP along with the table above labeling the actual pins as ICSP as well. The actual SPI header is clear over on the other side of the SAM3X chip and located nowhere near the ICSP header but yes as you said (I think) the ICSP header is adjacent to and even appears directly connected with the 16U programming port so yes...that is what was confusing. I tried using my forum creds to edit the page but they must be different because it doesn't work
Now I'm just hoping the pinout on the SPI header is what is accurately represented there or if it isn't then the pin-out for ICSP and SPI header are identical.
The pinout is the same but the headers are mounted in opposite directions, have a look at the unofficial pinout diagram.
http://forum.arduino.cc/index.php?topic=132130.0
Rob
Thanks for the thorough clarification on that. I'd already accounted for it. Thankfully, I at least know how to find pin 1 of most any header and IC.
How do you control how the SPI library manages your CS pins? i.e how to tell the SPI library that your CS pin you used in the begin, setXXXX, and transfer calls is active high or low?
I can't read that tiny pic in an ocean of white. A larger pic would be nice and/or a link to a data sheet.
How do you control the SPI library managing your CS pins active high or low?
With normal SPI you just select a pin and control it yourself. The Due has extended SPI which probably uses the SAM's dedicated CS pins but I don't know how that is implemented.
How do you control the SPI library managing the reset pin as active high or low?
You don't, reset has nothing to do with SPI. If you really want to reset that chip you have to use a spare pin and do it yourself.
What is the behavior of the reset pin?
Ummm, it resets the device Without a data sheet I don't know.
Rob
I modified my original posting probably while you were reading it
Thank you very much for the reply. I looked at the schematics and noticed that it was as you said and the reset pin is not something that gets written to but is rather connected to the SAM3X reset line I would imagine to either allow an SPI device to reset the SAM3X and/or allow an SPI device to get reset when the chip resets. That became pretty clear as soon as I understood where it went. I also noticed the attachment was tiny right after attaching it and since I already cleared up my question with the reset, I removed it but I'm posting it here again (and larger of course) so you can see that the CS pin on this particular package is sort of backwards from what most SPI devices use which is kind of the source of my problems. While I can manage it myself, which is what I was doing on the Arduino UNO with an older bit banging library, I was left with the impression from the docs that the stock SPI library does it for you.
In my case it will probably work because by default the library, I believe uses pin 52 or something way up there so as long as I call:
ISP.begin() and not ISP.begin(10) like I was doing it will be OK. It's also a good thing I'm not trying to use multiple SPI devices since this one's CS is goofy.
I'm thinking it might be nice to offer an overloaded begin that looks something like this:
ISP.begin(10, HIGH);
With the second param being the active state of the CS pin specified and being defaulted to LOW for calls that do not specify it.
It sounds like I'm going to have to dig into the implementation and climb through the SAM3X data sheet and all kinds of macros in underlying code to figure this out...bummer...
As there is no support for an active high CS signal you either have to add an external inverter or do it yourself with a GPIO pin.
ISP.begin(10, HIGH);
The polarity is set by the hardware, I don't think it's possible to invert it internally although if you dig deep into the data sheet there may be an option for pin inversion. There is on some CPUs but I've not seen that with the SAM.
Rob
Thanks, I was noticing that myself. I've spent the afternoon studying the data sheet. Holy cow it is VERY large and there are MANY MANY features of this thing. Some of which the Due doesn't even expose. For example, there are two hardware quadrature encoders. I just spent the last 2 weeks ironing out extremely efficient interrupt routines to do the same thing. I learned the pins those lines are connected are available on my project if I re-route pin 2 so I can use Pins 2, 13, an A7 (AD7) not sure which yet for the index pulses. I may do that when I get to it but for now the interrupts I've written seem to be doing a fine enough job.
I did find the 4 bits in the register that are used for managing the CS pins. Did you know you can configure them to be addresses that feed a built-in MUX allowing you to manage up to 15 or 16 total SPI devices all on the same TX/RX pins? Crazy, crazy.
I also re-read the datasheet on my chip and it technically isn't SPI. it's really 3-wire or something like that. It has SCLK, DataIn (MOSI on SPI,) and CS. Then there is an error pin which could technically be the MISO but wasn't designed as such. Still it's desirable to use it so I'm not burning other pins I need for other things so, yes I've resigned myself to using a separate I/O pin for CS.
Given all the above, I'd like to find a way to use the CS lead that actually isn't connected to any of the Arduino pins because right now I'm burning a digital pin I actually kind of need (52) just because that's the default in the SPI library and IS NOT the one that actually controls chip select.
Also, I discovered that Timer 1 channel 0 must be used with SPI somehow because when I use that timer to manage another function it completely disables SPI. I've moved my timer interrupt over to Timer 1 channel 1 and now both seem to be working again.
I'm wondering how that will affect trying to use the hardware quadrature decoder with SPI as well. So many possibilities, so little time....
Did you know you can configure them to be addresses that feed a built-in MUX allowing you to manage up to 15 or 16 total SPI devices
Yes, either internally MUXd for 4 devices or externally MUXd for 15 devices.
I'd like to find a way to use the CS lead that actually isn't connected to any of the Arduino pins
Ummm, using telepathy?
If you only have a single device you shouldn't need the SC pin at all unless it's used internally for some reason. I don't know what chip it is so can't tell.
Timer 1 channel 0 must be used with SPI somehow because when I use that timer to manage another function it completely disables SPI.
There should be no relationship between the two, I suspect a bug in either your code or the libraries.
Rob
Yes, either internally MUXd for 4 devices or externally MUXd for 15 devices.
Thanks for the correction, I mean external not built-in.
I'd like to find a way to use the CS lead that actually isn't connected to any of the Arduino pins
Ummm, using telepathy?
Funny, but no. Come on man, give me more credit than that
As we've covered, the most convenient way of doing this managing the CS pin myself. Ok, done. I'm already there but using the SPI library configures by default to use CS pin connected to pin 52. I know there are four but as far as I can tell there are only 3 connected on the Due (4, 10, and 52.) All of which I'm using for other purposes (or was until this happened.) So I want to use the 4th CS pin with SPI precisely so that it is NOT being used and all of the others will be available for me to use with other things. As it is now, I've had to remove pin 52 from use...disappointing. Since I'm already using pin 10 to manage CS myself, I do not want my transfers using SPI library to mess with any of the other exposed pins on the Due so when I say I want to use it, I mean that I want it's use to be ignored since I can't seem to get away without using at least something based on the way the hardware and SPI library for the Due are implemented.
There should be no relationship between the two, I suspect a bug in either your code or the libraries.
My bet is on the libraries and no it isn't because I think my code is all Rosy just because it's my code. It's because I've spent enough time troubleshooting this and studying the data sheet that I have good supporting evidence.
this is probably a bug in the SPI library.
May you try to change the file:
hardware/arduino/sam/variants/arduino_due_x/variant.h
and replace the following (should be around line 87):
#define BOARD_SPI_DEFAULT_SS BOARD_SPI_SS2
with:
#define BOARD_SPI_DEFAULT_SS BOARD_SPI_SS3
and see if this solve your problem?
AWESOME! Yes, that solved the problem and worked GREAT! Thank you!!
Hi all,
How what this done?
I can't find it: Due-Pinout.pdf, Due-pinout.svg or Arduino Reference/SPI, but found reference to it here:
On the Due schematic, SS3 is pin 142, PB23, but is not connected to anything.
Atmel Datasheet shows one can use PA31, PB23 or PF2.
This didn't help me.
