SPI woes - Ethernet shield vs. everything else

OK Paul. I am sorry to have troubled you.

John.

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

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.

You are very welcome John!! Thanks for the support and assistance you provided too!!

Regards,

Graham

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.

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.

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

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

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. ??

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

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 using the newest Wiznet library and SdFat

ghlawrence2000: -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.

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!!

@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?

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

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, 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.

void setup()
{
  Serial.begin(115200);

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

  // rest of your setup code

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

Can you post the library you are using for that TFT display? What interface does it use? Is it SPI?

It is the standard UTFT 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

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?

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

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.