Go Down

Topic: SPI woes - Ethernet shield vs. everything else (Read 5108 times) previous topic - next topic

ghlawrence2000

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
UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!

pjrc


ghlawrence2000

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
UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!

johnlinford

#18
Jun 01, 2016, 09:52 am Last Edit: Jun 01, 2016, 11:20 am by johnlinford
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.

pjrc

#19
Jun 02, 2016, 12:05 am Last Edit: Jun 02, 2016, 12:07 am by Paul Stoffregen
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?

johnlinford

OK Paul. I am sorry to have troubled you.

John.

ghlawrence2000

#21
Jun 02, 2016, 12:30 am Last Edit: Jun 02, 2016, 12:45 am by ghlawrence2000
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
UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!

johnlinford

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.

ghlawrence2000

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

Regards,

Graham
UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!

SurferTim

#24
Jun 02, 2016, 01:24 am Last Edit: Jun 02, 2016, 01:27 am by SurferTim
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.

ghlawrence2000

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
UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!

SurferTim

#26
Jun 02, 2016, 01:36 am Last Edit: Jun 02, 2016, 01:57 am by SurferTim
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. ??

ghlawrence2000

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
UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!

SurferTim

#28
Jun 02, 2016, 02:10 pm Last Edit: Jun 02, 2016, 02:24 pm by SurferTim
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

pjrc

#29
Jun 03, 2016, 02:45 am Last Edit: Jun 03, 2016, 02:47 am by Paul Stoffregen
-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.

Go Up