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
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.
Thanks John and Tim,
All help to resolve these issues is very much appreciated!!
Regards,
Graham
+1 John
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.
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
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.