Arduino Forum

Products => Arduino Due => Topic started by: johnlinford on May 24, 2016, 04:42 pm

Title: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on May 24, 2016, 04:42 pm
I would be very grateful if the forum could help me to a better insight into how SPI works and, in particular, why I am failing to get my set up to behave. This is the hardware stack that I am trying to get to work:

5" TFT display with SPI-connected flash chip
Display shield
Ethernet shield (1 or 2)
SD card on the Ethernet board
Arduino Due

The library stack is
#include <SPI.h>
#include <SdFat.h>
#include <Ethernet.h> (or #include <Ethernet2.h>)
#include <ICMPPing.h>
#include <UTFT.h>
#include <UTFT_GHL.h>

The Ethernet connection receives asynchronous UDP data for the intended application. The application then processes the data, saves stuff to the SD card and writes information to the display using fonts obtained from the flash chip. I am using the Ethernet library (or the Ethernet2 library for the v2 card) and SdFat. The flash chip uses the UTFT_GHL library. There are, therefore, three users of the SPI: Ethernet, SD card and flash chip.

It doesn't work!

To try to narrow down the problem I wrote a simple app that pings Google via the Ethernet card, reads/writes/deletes files on the SD card and writes stuff to the display in a continuous loop. I'm happy to post this code if it will help.

What happens?

Each of the SPI interfaces works fine on its own. If I run the Ethernet and SD card together, as soon as I do anything with the SD card the Ethernet interface dies so conclusively that it hangs the entire machine when the next ping is sent. The same thing happens if I run Ethernet with Flash font screen printing. The only combination that does work is SdFat R/W/D and UTFT_GHL reading the flash to get its fonts.

Anecdotally the Ethernet card doesn't play nicely with other things on the SPI and my experience seems to be adding to that sorry tale. It seems to me that this is something that it ought to be possible to fix once and for all but I am no expert when it comes to the innards of these drivers/libraries and am a relatively recent convert to programming in C. So I am appealing to those with greater knowledge and experience than me to help out with this one.

Any insight gratefully received!

Thanks in advance.

John.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on May 24, 2016, 09:10 pm
I hope you get to the bottom of this, as no doubt in the future I am likely to get 'my ethernet shield doesn't work with UTFT_GHL' .....  :smiley-confuse:


Regards,


Graham
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on May 26, 2016, 04:19 pm
Update:

After a lot of Googling, I came to the perhaps mistaken conclusion that the SPI library for Due might be different to that for, e.g. Mega 2560. I decided to try my code on a 2560. Lo and behold, Ethernet and SdFat happily coexist.

Unfortunately I do not have a Mega-compatible shield for the display, so I can't easily test that interface. As the UTFT_GHL/SdFat combination works on the Due, I suspect it will on the Mega.

My application really needs the processing power of the Due, otherwise I'd be tempted to just go with the Mega and be done with it.

So, is there a different SPI library for the Due? And if so, where can I get it?

Thanks in advance

John.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on May 28, 2016, 02:22 pm
As the UTFT_GHL/SdFat combination works on the Due, I suspect it will on the Mega.
Yes John, it does.

Regards,

Graham
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on May 30, 2016, 12:10 pm
Thanks Graham.

It seems that none of the forum experts can find a barge pole long enough to convince them that it's safe to engage on this issue. That's a shame - it seems that SPI is both poorly understood and poorly implemented in many cases.

Someone out there will know the answer and it would be great if they would come forward. Meanwhile I shall continue to look at other options.

John.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on May 31, 2016, 01:33 pm
Final attempt to stir up some response :D  Here is the test code I am using...

Code: [Select]

#define SD_CS_PIN 4
#include <SPI.h>
#include <SdFat.h>
//#include <SD.h>
#include <Ethernet.h>
#include <ICMPPing.h>
#include <UTFT.h>
#include <UTFT_GHL.h>

bool SDInitialised=false;
SdFat SD;
File myFile;

bool EthernetInitialised=false;
IPAddress pingAddr(8,8,8,8); // ip address to ping
byte mac[] = {0x90, 0xA2, 0xDA, 0x0D, 0xB4, 0x9A}; // MAC address for ethernet shield
SOCKET pingSocket = 0;
char buffer [256];
ICMPPing ping(pingSocket, (uint16_t)random(0, 255));

bool TFTInitialised=false;
UTFT myGLCD(CPLD,25, 26, 27, 28);
UTFT_GHL CTE_LCD(&myGLCD);

int Count;

void setup() {
  Serial.begin(115200);
  delay(500);
  //pinMode(4, OUTPUT);   //Makes no difference
  //pinMode(10, OUTPUT);  //Ethernet doesn't initialise if this is enabled
  //pinMode(52, OUTPUT);  //Makes no difference
  //pinMode(53, OUTPUT);  //Makes no difference

  Serial.println("Initialising display...");
  myGLCD.InitLCD();
  myGLCD.setBackColor(VGA_BLACK);
  CTE_LCD.SPI_Flash_init(FLASH_CS_PIN);
  myGLCD.clrScr();
  TFTInitialised=true;

  Serial.println("Initialising SD card...");
  if (SD.begin(SD_CS_PIN)) {
    Serial.println("SD card initialised OK");
    SDInitialised=true;
    }
  else {
    Serial.println("SD card initialisation failed");
    }

  Serial.println("Initialising Ethernet...");
  if (Ethernet.begin(mac)) {
    Serial.println("Ethernet initialised OK");
    EthernetInitialised=true;
    }
  else {
    Serial.println("Ethernet initialisation failed");
    }

  Count=0;
  }

void loop() {
  Count++;

  //Send ping request
  //The ping is just a convenient way of testing whether the Ethernet interface is still working.
  Serial.println();
  Serial.println("Ping request");
  ICMPEchoReply echoReply = ping(pingAddr, 4);
  if (echoReply.status == SUCCESS) {
    sprintf(buffer,
            "Ping reply[%d] from: %d.%d.%d.%d: bytes=%d time=%ldms TTL=%d",
            echoReply.data.seq,
            echoReply.addr[0],
            echoReply.addr[1],
            echoReply.addr[2],
            echoReply.addr[3],
            REQ_DATASIZE,
            millis() - echoReply.data.time,
            echoReply.ttl);
    }
  else {
    sprintf(buffer, "Ping request failed; %d", echoReply.status);
    }
  Serial.println(buffer);
  delay(500);  
    
  //Write file
  Serial.println("Write to SD");
  myFile = SD.open("test.txt", FILE_WRITE);
  if (myFile) {
    myFile.print("Test data, loop count=");
    myFile.println(Count);
    myFile.close();
    }
  delay(500);

  //Display stuff
  Serial.println("Write to display");
  CTE_LCD.Put_Text("Test data, loop count=",10,200,BVS_34);
  CTE_LCD.Put_Text(String(Count)+"    ",400,200,BVS_34);
  delay(500);

  //Read the file
  Serial.println("Read file from SD");
  myFile = SD.open("test.txt", FILE_READ);
  if (myFile) {
    while (myFile.available()) {
      Serial.write(myFile.read());
      }
    myFile.close();
    }  
  delay(500);

  //Delete the file
  Serial.println("Delete file on SD");
  SD.remove("test.txt");
  delay(500);  
  }


And here is the serial port display

Code: [Select]

Initialising display...
Initialising SD card...
SD card initialised OK
Initialising Ethernet...
Ethernet initialised OK

Ping request
Ping reply[0] from: 8.8.8.8: bytes=64 time=14ms TTL=128
Write to SD
Write to display
Read file from SD
Test data, loop count=1
Delete file on SD

Ping request


...at which point it dies. Either SD card activity or writing to the display kills the Ethernet.

Still hoping someone might be able to help...

Thanks

John.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on May 31, 2016, 02:23 pm
Hi John,

mmm I am not sure if you have already tried and removed it, or if you only partially implemented my suggestion?

I see all of your pinMode definitions, now commented out, but I don't see your corresponding digitalWrite(pin, HIGH) commands?

eg :-

Code: [Select]
  pinMode(4, OUTPUT);   //Makes no difference
  digitalWrite(4, HIGH);
  pinMode(10, OUTPUT);  //Ethernet doesn't initialise if this is enabled
  digitalWrite(10, HIGH);
  pinMode(52, OUTPUT);  //Makes no difference
  digitalWrite(52, HIGH);
  pinMode(53, OUTPUT);  //Makes no difference
  digitalWrite(53, HIGH);


?

Regards,

Graham
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on May 31, 2016, 03:08 pm
Hi Graham,

Yes I did try setting all the pins high but the problem remains unchanged. The only pin that makes any difference is setting pin 10 to output. That just kills the Ethernet card immediately, at initialisation, regardless of whether I then set the pin to high...

Code: [Select]

Initialising display...
Initialising SD card...
SD card initialised OK
Initialising Ethernet...


...and it's dead.

John.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on May 31, 2016, 03:18 pm
Hi John,

Ok.

Specifically which Ethernet cards do you have, and which ethernet library are you using?

G
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on May 31, 2016, 03:44 pm
I have the standard "Ethernet R3" shield and I've also tried the "Ethernet Shield 2". Both behave in exactly the same way. The library is the one installed with the Arduino 1.6.8 IDE. Version 1.1.2 according to the library.properties file and that seems to be the current version on GitHub (https://github.com/arduino/Arduino/tree/master/libraries/Ethernet).

J.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on May 31, 2016, 03:47 pm
AHA.....

Maybe worth trying this one (https://github.com/Wiznet/WIZ_Ethernet_Library) then, since it mentions now works at SPI 42Mhz, which is also oddly enough what the Font IC runs at....

G
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on May 31, 2016, 04:41 pm
Disappointing! Exactly the same results with the WIZ library. I have checked that the new library is definitely being compiled in (via a Serial.print within the library) and I've configured it per the instructions to use the R3 Ethernet shield. I have yet to try it on the Ethernet 2 shield but it's not looking promising.

I must be doing something stupid but I cannot for the life of me work out what it is.

J.

** Update: exactly the same results with the Ethernet 2 card. :(
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on May 31, 2016, 04:46 pm
I am running out of ideas.....

Oh by the way, after my lengthy reply to your lengthy reply, STM32 stuff..... there will very soon be a DUE replacement with almost the exact hardware!! Now THAT will be nice.... do a search for Arduino Star OTTO.

G
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on May 31, 2016, 05:30 pm
Thanks for trying Graham. The Star OTTO (what an odd name) does indeed look interesting, as does the EtherDue (if I can ever get a reply from the supplier). No doubt each will bring all sorts of new things that don't quite work as expected...
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: pjrc on May 31, 2016, 11:55 pm
Is this 5 inch TFT using RA8875?

The RA8875 has a known problem where it can not tri-state its MISO pin.  A separate tri-state buffer is usually required if the RA8875 is used together with any other SPI chips.

Sometimes it can work, when another chip also drives MISO, but the result is an incorrect voltage for logic high and low, so whether it works depends on the MISO receiver circuitry in your Arduino.  I've heard reports of 2 RA8875 (but not 3) working on Mega, but failing on Teensy 3.2.  No idea about Due.

Star Otto looks like powerful hardware, but it's made by that "other" Arduino.  Maybe it'll turn out to be an awesome product, but given their dismal performance on the software side so far (mostly copying everything from Ardiuno.cc with only minor tweaks), might be best to take a wait-and-see approach.  The market is already filled with extremely powerful STM32-based boards that don't have good Arduino compatibility.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 01, 2016, 12:12 am
Hi Paul,

No, John is not using RA8875, it is 5" CPLD.

The problem I gather you are already aware of in passing, SdFat/Ethernet and SPI issues. John and I have been in communication with this issue, but I suggested he contact you directly as your understanding of the SPI library for DUE is clearly much better than mine.

The problem John is having is getting sdfat and ethernet to co-exist, since UTFT_GHL uses the same DMA code used by sdfat, it stands to reason my library will cause the same fatal error. But WHAT is the problem? Are you aware of any way (with transactions or otherwise) of getting Ethernet to not die during a SdFat file write?

We have already tried digitalPin(Ethernet_CS, HIGH); before an SD operation and digitalPin(SD_CS, HIGH) before any ethernet operations, but to no avail, that I am afraid is where my SPI knowledge ends...

Hope you can shed some light on this issue!?

Thanks!

Regards,

Graham
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: pjrc on Jun 01, 2016, 03:22 am
Maybe try using SD instead of SdFat?
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 01, 2016, 03:34 am
Ok Thank you.

That doesn't really get to the bottom of the problem, but since nobody appears to want to I guess I am not surprised.

Regards,

Graham
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on Jun 01, 2016, 09:52 am
Hi Paul,

Thank you for engaging with us on this. As Graham says, I have the CTE CPLD display and use UTFT_GHL to drive it. I have tried SD and it does indeed work OK with Ethernet. That's what I was originally using but it still leaves the issue of getting the display flash to work as well.

It's still not clear to me whether the issue is in the Ethernet library or in SdFat/UTFT_GHL. I suppose Graham could try using the SD SPI interface code instead.

Regards,

John.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: pjrc on Jun 02, 2016, 12:05 am
That doesn't really get to the bottom of the problem
What if the problem is a resource conflict between SdFat and one of these other libs?  If using SD makes things work, why can you accept that as a solution?

Or do you expect "get to the bottom of the problem" to involve someone actually digging into the low-level details of these libs and editing them to work together?

I regularly do that for Teensy boards, but I'm not going to do it for Arduino Due.  Maybe someone from Arduino who supports Due might be interested in such work?
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on Jun 02, 2016, 12:25 am
OK Paul. I am sorry to have troubled you.

John.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 02, 2016, 12:30 am
F****ng good job we got to the bottom of the problem then John, with that level of help?  I am inspired by Paul's reaction! Hope you are too? :P

Regards,

Graham

PS, Do you recall what I said about experts needing the same hardware and issues, then they 'might' help you? ..... :( To be honest, I am not surprised...

-1 to Paul
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on Jun 02, 2016, 12:38 am
Graham and I have been working on this problem off an on for most of today and we have some partial success to report. By changing a parameter in UTFT_GHL and another, related one in SdFat we have managed to get Ethernet, SdFat and UTFT_GHL to work together properly with IP traffic.

As is so often the case, what we hoped would be a complete fix turns out not to be and there is still a problem when handling UDP traffic. I cannot quite see why what we assume to be an SPI problem would be sensitive to different types of network traffic and it may be that this is merely an artefact of some other problem. The code looks pretty fiendish and as I mentioned in my first post, I am no C expert (most of my programming was done years ago in assembler). Nonetheless, we hope to make further progress in due course.

I would like to publicly thank Graham for his considerable effort on this problem today.

John.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 02, 2016, 12:41 am
You are very welcome John!! Thanks for the support and assistance you provided too!!

Regards,

Graham
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: SurferTim on Jun 02, 2016, 01:24 am
I use an ethernet shield and SD together on a Due. Both work fine.

The secret is D10. Do not set it to OUTPUT. It will lock up the w5100. Use the weak pullup on D10 to disable the w5100. Here is the setup I use that works.
Code: [Select]
void setup()
{
  Serial.begin(115200);

  pinMode(4,OUTPUT);
  digitalWrite(4,HIGH);

  // disable w5100 SPI while starting SD
  digitalWrite(10, HIGH);
 
  Serial.print(F("Starting Sd.."));

  if(!SD.begin(4)) {
    Serial.println(F("failed"));
  }
  else {
    Serial.println(F("ok"));
  }

  Ethernet.begin(mac, ip, gateway, gateway, subnet);
  Serial.println(Ethernet.localIP());

  delay(2000);
  server.begin();

  Serial.println(F("Ready"));
}


edit: Here is my Due/ethernet shield/SD web server in action. (http://68.99.58.117)
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 02, 2016, 01:32 am
Hi Tim,

Thank you.

Will be tomorrow or later now before can check notes with John.

We have got to the bottom of most of the problems, now something most peculiar is happening with UTFT after SD writes, whether using the SD or SdFat libraries. Most strange!

I will be the proud owner of a flashy new Ethernet 2 shield in the next few days, so then I can deal with this stuff myself, and not trouble anybody else... 

Regards,

Graham
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: SurferTim on Jun 02, 2016, 01:36 am
You shouldn't have any problem with the ethernet 2 shield (w5500) if you use the Wiznet library for it. I use it with the w5100 and it works fine on both the mega and Due.
https://github.com/Wiznet/WIZ_Ethernet_Library (https://github.com/Wiznet/WIZ_Ethernet_Library)

edit: I just tried the Due with SdFat rather than the standard SD library and it didn't do well. It initializes the SD, opens a file, but won't read from it. ??
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 02, 2016, 02:03 pm
Hi Tim,

Try setting 

#define SD_SPI_CONFIGURATION 1  line 81 of SdFatConfig.h

I think that should deal with the problem....

I assume you mean you are trying SdFat with Ethernet?

Regards,

Graham
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: SurferTim on Jun 02, 2016, 02:10 pm
SdFat works with my Mega 2560, but not with the Due. I'll try it.

edit: That seems to have corrected the read problem. Thanks!

My Due web server online (http://68.99.58.117) using the newest Wiznet library (https://github.com/Wiznet/WIZ_Ethernet_Library) and SdFat (https://github.com/greiman/SdFat-beta)
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: pjrc on Jun 03, 2016, 02:45 am
-1 to Paul
Really?!

I didn't write any of these libraries.  I have made numerous contributions to these libraries and others (and many other parts of Arduino), but I don't maintain the versions used by Arduino Due.  Most SPI things that not work on Due are a result of my work to contribute the SPI transaction API to the SPI library.  Before that, the SPI library API was tightly coupled to 8 bit AVR hardware and everything wanting to do SPI on Due needed #ifdef code for Due-specific clock dividers!

I don't make any boards based on Due or any Atmel ARM chips.  I've never yet used Due for any project.  The only reason have a Due is for checking software compatibility when I make Arduino contributions.

Attitudes like this really sour me on contributing.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 03, 2016, 02:57 am
Well I apologise if you feel that way!

John and I asked for your help as a leading contributor to the Arduino world to basically be told don't care, not interested. I am not a newbie asking a stupid question, I am moderately knowledgeable in most things Arduino now, and would not have asked for help if it were not required. I didn't like your attitude. I understand your driving passion to be teensy, but the reason I thought maybe you could help us, was because you clearly have a better understanding of the SPI library with all of your work on transactions.

Sorry we even bothered to think you might be interested in helping!!

Regards,

Graham

PS, regardless what you think of my reaction, I and many others are grateful for all of your efforts!!
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: SurferTim on Jun 03, 2016, 03:14 am
@ghlawrence2000: Are you still having problems with the w5100 and the SD interface? Mine is working great now, thanks to your input. Is there something else here I am missing?
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 03, 2016, 03:24 am
Tim,

I  need to sleep now, glad I helped with your SdFat issue! 

Will post the  outstanding problem tomorrow if John doesn't beat me to it.

Regards,

Graham

Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: SurferTim on Jun 03, 2016, 03:25 am
Ok. Talk to you later. Thanks again for the help. Hope I can return the favor.

edit: After a quick check of the pin mapping for the Due (https://www.arduino.cc/en/Hacking/PinMappingSAM3X), I noticed both D10 (PA28/SPI-CS0 and PC29/D10) and D4 (PA29/SPI-CS1 and PC26/D4) connect to two pins on the CPU. Do not set either of those pins as OUTPUT. Use digitalWrite to change them to HIGH only. That will disable the SPI on both devices without causing a conflict between the digital pins and the SPI pins on the ARM CPU.
Code: [Select]
void setup()
{
  Serial.begin(115200);

  // disable SPI on both devices
  digitalWrite(4,HIGH);
  digitalWrite(10, HIGH);

  // rest of your setup code
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 03, 2016, 11:36 pm
Hi Tim,

I cannot go into glorious detail since I cannot get my newly arrived E2 Sheild (THANKS! John) to work with my TFT shield. The display doesn't seem to like being on the end of wires :(. The situation as I understand from John, is that UDP reads, corrupt UTFT variables.... Since UTFT_GHL relies on those variable, both libraries are corrupted by UDP reads. 

It makes no sense I know, but I cannot explain better than it has been explained to me.

Regards,

Graham
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: SurferTim on Jun 03, 2016, 11:52 pm
Can you post the library you are using for that TFT display? What interface does it use? Is it SPI?
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 04, 2016, 12:05 am
It is the standard UTFT (http://"http://www.rinkydinkelectronics.com/library.php?id=51") library by Henning Karlsen. No, it is not SPI, it is 16 bit parallel.

It makes NO sense.... I know all of that...

There is not enough information I can give you at this point in time to help you try to figure this out, if John wants to elaborate, maybe he can give you more detail about this issue.

The problem I am having right now, as no doubt you are aware, is that the E2 shield is UNO format, and I want to plug in a MEGA/DUE format TFT shield into that, and wiring these two together , the display doesn't work.

Sorry this is only half a story, but I can't do any better right now :(.

Regards,

Graham

Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: SurferTim on Jun 04, 2016, 12:10 am
I see. The library download appears to be 2MB. I'm not sure I have the time to dig through that much library.

Is it working on the Due without the w5100/SD shield?
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 04, 2016, 12:21 am
Tim, I appreciate your offer and willingness to help, but I would prefer I could give you specifics to work on, which currently I am not able to do.

Yes it works flawlessly on the DUE, with SD card AND Flash SPI chip, the only thing that buggers it up is the Ethernet card which personally I cannot get working yet.

Probably this thread can be closed now, John will read this tomorrow no doubt, if he can give you more detail that would be great, otherwise wait until I have all hardware connected together and we can create another thread.

Thanks again for your help!

Regards,

Graham

+1 by the way
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on Jun 04, 2016, 12:42 am
Here is an interim update.

With the updates that Graham has already mentioned earlier in this thread I seem now to be able to run WizNet (UDP and TCP/IP) together with SdFat and UTFT_GHL and they all coexist on the SPI bus. I'm not completely sure what I've done to get to this happy state, nor am I fully convinced that it is definitely 100% working. I'm going to need to spend some more time on this over the next day or so but I will write up whatever conclusions I reach, as soon as possible, here.

Regards,

John.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 04, 2016, 12:44 am
Thanks John and Tim,

All help to resolve these issues is very much appreciated!!

Regards,

Graham

+1 John
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: SurferTim on Jun 04, 2016, 12:51 am
I've used my Due with the ethernet shield and a 10DOF board (I2C), a Adafruit Ultimate GPS (serial), and a 16 channel servo controller (I2C), and had no problems, even with UDP, which is my favorite protocol. Don't know what to tell you.
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: ghlawrence2000 on Jun 04, 2016, 02:41 pm
To summarise what we did to reach this happy state of affairs :-

SdFat with UTFT_GHL works fine as relased, the DMA code used in UTFT_GHL is the same as that used in SdFat, so there is no real surprise this combination works without issue.

UTFT_GHL and Ethernet, not happy, ethernet hangs after access to the Font IC.
SdFat and Ethernet, not happy, ethernet hangs after access to the SD card.

The solution here is to configure SdFat, in SdFatConfig.h change Line 81 to #define SD_SPI_CONFIGURATION 1.

This should fix your problems with Ethernet and SdFat.

To effect the same fix to UTFT_GHL,, in HW_ARM.h (currently line 39) change to #define USE_SAM3X_DMAC 0.


That's the end of the good news unfortunately, the result of these changes is significantly slower SPI performance.

I have an Ethernet R2 card now (THANKS, you know who you are), so this is not the end by any means, if we come up with another solution, it will be posted either in this thread or a new one.

Hope this will save people LOTS of time!!

Regards,

Graham
Title: Re: SPI woes - Ethernet shield vs. everything else
Post by: johnlinford on Jun 04, 2016, 06:15 pm
Just as a final follow-up to Graham's note, I'm happy to be able to confirm that all three libraries are playing nicely now. My app is running quite large volumes of UDP inbound, rather less outbound, together with regular reads & writes to the SD card and updates to the display. There doesn't seem to be any particular order that's best for initialisation but I am doing it thus:

UTFT_GHL
UTouch
Ethernet
SdFat

The Due is handling inbound UDP traffic at the rate of around 800kbit/s from my LAN without any problem at all, so even though the SPI is running more slowly than it might it seems to be coping well.

My thanks to Graham for his considerable assistance with this rather tricky problem.

John.