Go Down

Topic: sdfat + ethernet + spi issue (ethernet dropping connection) (Read 2 times) previous topic - next topic

fat16lib

Any chance of a power problem?  How are the relays powered?

The SD draws a large surge for a few milliseconds during write.  SdFat users have had problems when writing SD cards and using other devices that use lots of power or cause spikes.  I don't know how sensitive the Ethernet is to noise.

SurferTim,

SdFat does not use interrupts.  The SPI transfer happens during the write call.

SurferTim

@fat16lib: If that is the case, then the SD and w5100 should not interfere with each other. I use them together without problems, and so does zoomkat. He is the master at SD file handling in conjunction with the w5100 library code. He has never mentioned a problem, nor has anyone who has used his code.

This FTP passive client code always works good for me. It uses the SD and w5100 together.
http://playground.arduino.cc/Code/FTP

fat16lib

#17
Sep 11, 2013, 09:16 pm Last Edit: Sep 11, 2013, 09:21 pm by fat16lib Reason: 1
Quote
SD and w5100 should not interfere with each other


That's why I asked about a power problem.  Using SdFat and W5100 is common and when I get mail about a problem it is usually something other than SPI.

A comment on SPI setup.  Writing the two SPI control registers only takes a fraction of a microsecond while the digitalWrite to pull chip select low takes 3-5 microseconds as does the digitalWrite to set chip select high.  So the extra overhead is minimal for any SPI transfer.

doughboy

yes, I did suggest it may be a software/hardware issue.

the relays are powered by 12v, arduino is isolated from the relay. relay control input use opto isolator.
I don't think it is an issue of under powered power supply (though I'm not ruling that out yet), but may be a spike or surge as you suggested. I can try delaying the sd write, say 2 seconds after the relay switches.

Tim, I like your logic, just because you do not see a problem, you conclude there is no problem. lol. 
As fat16lib said, the overhead is minimal to add the SPI initialization code. It will take 2-3 clock cycles to do it (refer to AVR datasheet, SBR and CBR instructions take 1 clock cycle each).  Don't get too hung up on code performance where it does not matter. :)

As to my source code, it is a very large project so I do not want to waste anyone's time perusing it.  I will eventually put it in github as an open source project.

SurferTim

#19
Sep 12, 2013, 04:30 am Last Edit: Sep 12, 2013, 05:02 am by SurferTim Reason: 1
Quote
Tim, I like your logic, just because you do not see a problem, you conclude there is no problem. lol.  

Mine works, yours doesn't. How about that logic?  lol :D

BTW, I saw no problem because I saw no code. You failed to post your code when I suggested it. Why?
Quote
As to my source code, it is a very large project so I do not want to waste anyone's time perusing it.

By not posting it, you were wasting my time. I think there is another reason you don't want to post it.

edit: You probably won't listen to my suggestion, but you should cut your long sketch down to just the part that is your problem. That is a internet transaction and an SD write. If there is a problem, post the short sketch with the fail.

doughboy

This turned out to be an EMI problem caused by the relays switching. The ethernet does not drop out of the network anymore after I added an MOV across each outlet. This is just a hardware issue and what I initially thought was a software issue was purely coincidental on the code that was executing after a relay switch.

mods can close this thread.
thanks.

Go Up