I working on a project comprising a Due, Ethernet shield (R3) and ColdTears 5" TFT display. I want to use the flash fonts on the display and I also need access to the SD card on the Ethernet shield. So I have three things trying to use the SPI: Ethernet, Flash and SD card. It doesn't work!
I can get the Ethernet card to work fine, with the SD card. I can get the display to work fine and access the Flash fonts just fine. I cannot seem to get all three to work together.
I'm using the standard SPI and SD libraries, with UTFT and UTFT_CTE. Ethernet is using SS=10, The SD card is on SS=4 and I've tried all sorts of different pins for the Flash SS, including the default, SS=53 to no avail.
As soon as I issue CTE_LCD.SPI_Flash_init(pin); the Ethernet connection dies, so I'm sure that this is an SPI problem. I've read suggestions that the Ethernet shield doesn't play well because it doesn't tri-state MISO when not selected. Perhaps that might be the problem? I also wonder about the fact that the shield is a 5V unit but the Due is 3.3V. That said, they work together just fine until the display Flash SS pin is initialised.
So I'm a bit stumped and would be grateful for any ideas from the experts.
Thanks in advance.
John.
Hello John,
I am a newbie too and I am working on an SPI project with my Due board. I have got the right infos at that place : Gammon Forum : Electronics : Microprocessors : SPI - Serial Peripheral Interface - for Arduino
BTW you should consider using an logic lever shifter to avoid a major issue with your Due board. 
Hi Ard,
Some useful information, thank you. I can see I'm going to end up getting the 'scope out on this one.
I should have added to the original post that I am not using a display shield but have instead constructed an interface prototyping shield that routes the Arduino pins to the appropriate display pins. This board also propagates the SPI pins through to the Ethernet shield on top. With this configuration either the Ethernet/SD -or- the display works fine. But not both together.
I think there is some interoperability issue specific to the hardware combination I'm trying to use.
Update:
I got working with the 'scope, with interesting results.
When I do not issue the SPI_Flash_init the Ethernet SS line happily bounces up and down between Low=0V and High=3.3V. When the device is idle it goes high as one would expect. As soon as I issue SPI_Flash_init, Ethernet SS goes high and stays high for evermore, which would certainly explain the problem. Meanwhile, the Flash SS line does as one would expect, going low for data transfers but mainly staying high.
I'm beginning to wonder if there is some issue with which end is master? I don't really understand the SPI master/slave behaviour very well but I do know that either the Due or the peripheral can be master. If one peripheral was asserting master while the other was slave I can imagine that there would be problems.
I'm finding the UTFT_CTE code a bit impenetrable at the moment, as C is not a programming language that I use very much (more of a Pascal/Delphi programmer really). I shall persevere but in the meantime if anyone has any ideas then I would love to hear them.
If you are using the SD library that comes with the Arduino IDE, dump it and get Sdfat, this has all sorts of options regarding SPI mode including software. The CTE Flash CS pin by default for the DUE is 52 not 53.
I don't have an ethernet shield, but I happily have CTE Font IC and SD card working together without problems.
Just an idea...... I no longer have the UTFT_CTE library as I rewrote it, so I cannot exactly tell you which lines to change......... But, all of these things seem to assume they are the only device which will use the SPI bus, I found it was helpful to allocate ALL of the CS pins as output BEFORE initialising any SPI devices, try that?
What I mean is,
pinMode(4,OUTPUT);
pinMode(10,OUTPUT);
pinMode(52,OUTPUT);
digitalWrite(4,HIGH);
digitalWrite(10,HIGH);
digitalWrite(52,HIGH);
CTE_Flash_init....
ethernet init...
sd init....
Also, try altering the sequence which you init the devices, does this make any difference?
Regards,
Graham
Hi Graham,
Thanks for your detailed reply. I'll certainly give Sdfat a try although there is no problem with the SD interface as far as I can tell, only with the Ethernet side. I have tried initialising the SS pins high as you suggest and it made no difference. I also tried changing the order of the various initialisations but ll that did was move the Ethernet<>display problem around in step - whatever I do,as soon as I start the display flash, the Ethernet stops. You're right about the default pin being 52 but I've tried it on umpteen other pins to no avail. So I remain stuck 
I think you are right when you say that these boards tend to assume that they are the only user of the SPI. I shall have to decide whether it is worth the effort to do as you have done and rewrite these interfaces. For the moment I've gone a different route and am using a simple homebrew 8-bit parallel interface protocol to send display data to a second Arduino with just the display attached. It seems to work well. I'd like to sort out the SPI issue but, at the end of the day, Arduinos are cheap. Another one won't do any harm!
Another question... what happened to UTFT_GHL? It sounds like it might have been rather useful!
Update...
Hmmm... scratch that. I found the "Seemingly UTFT_GHL is NOT dead, CTE are interested!!!" thread. I hope you get a deal. I am more than content to pay for code that I find useful.
johnlinford:
there is no problem with the SD interface as far as I can tell, only with the Ethernet side.
This seems to be a long running issue, SD as supplied with the IDE does not release when busy, sdfat handles these things better, I seriously recommend trying it! I cannot promise it will fix your problems but it certainly will not do any harm, also on the plus side, you will get long filenames and faster transfers ;).
Regards,
Graham
Thanks Graham. I will try SdFat and report back.
Regards,
John.