Ethernet and SD card on same SPI buss?

Nick McClick · 2010-05-19 19:21

I want to connect the Prop to an SD card and ENC28J60. Instead of using 8 I/O's, I'm thinking it would be better to share the Clk, Do, and Di - This should only take 5 I/O;

But I'm an SPI beginner and want to understand a few things before I prototype it - I bet someone out there can help;
1 - Should I put Pull-ups on Clk, Do, Di, Chip_Select_SD, and Chip_Select_ENC?
2 - When it comes to flow control, do need to stop PropTCP before starting fsrw & vice versa?

Or is it a better idea just to use 8 I/O?

Schematic is attached, if it helps.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!

Gadget Gangster - Share your Electronic Projects

Toby Seckshund · 2010-05-19 19:38

I think it should work with the separate chip selects.
I would put pullup on the /CSs for when the Prop goes "tri-state"

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

jazzed · 2010-05-19 19:42

I've used separate CS before and it worked. I Don't remember testing both drivers simultaneously.
Surely one can use a spin lock for mutual exclusive hardware access in the drivers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

smbaker · 2010-05-19 19:46

Nick McClick said...

Or is it a better idea just to use 8 I/O?

I tried to do this in one of my projects a while back. The idea was to be able to stream WAV files from an SD card while doing an occasional NTP (network time protocol) request. I think there's a previous topic that I started here in the forums that outlined my approach. My idea was to usual mutual exclusion (SD card code would hold a lock when fetching a block, ethernet code would hold a lock when talking to the ENC28J60; no two cogs would both try to use the same set of pins at the same time). Never could get it working, although I didn't put a whole lot of effort into it. I ended up abandoning the idea in favor of using an IO Expander to free up some other devices (mostly buttons and status LEDs) from the prop's IO pins, making room for the SD card and ethernet nic.

Here was the original thread:
http://forums.parallax.com/forums/default.aspx?f=25&m=326455

Rayman · 2010-05-19 20:16

I've heard something about having to give the SD card extra clocks in order to get it to stop outputting on DO... I think the regular SD card driver leaves the SD card asserting on DO, so you wouldn't want to try to share it...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm

MagIO2 · 2010-05-20 06:34

Nick McClick said...
Or is it a better idea just to use 8 I/O?

Well ... it depends. Is it for a new board you want to sell?
Then I'd do it flexible. Some jumpers for the DI/DO/CLK so you can connect it to the same or to different pins. Because using one SPI bus simply limits the transfer speed. And if this is fine very much depends on the project. In some it's OK in others you don't want to share bandwidth.

If it's for a concrete project you know (or should be able to estimate) what transfer speeds are needed for which device and of course can hardwire one version as the needs tell you.

hairymnstr · 2010-05-20 09:38

Re: SD card DO pin

SD cards aren't fully SPI compliant, they leave DO asserted even after CS has gone high as Rayman said. However if you send a few (16 or so I think) clocks to the card after the CS goes high the card will release DO. If you look at most of the recent SPI block code versions for SD card there is a comment in them about "Cluso99 wanted this mod to tristate the SD card", make sure that set of code is uncommented as that will do what you're after because the RamBlade/TriBlade use the SD pins to do parallel RAM access as well.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan

"Free as in freedom, beer gratefully accepted though."

Ariba · 2010-05-20 13:33

If a serial resistor is included at the DO pin then it should work also with not modified SD drivers (see first attached picture).

Eventually it's possible to share the 2 devices at the same 4 pins with the circuit of the second picture.
The idea is that the inactive device gets a lot of CS pulses, but no CLOCK puls and will therefore not receive or send anything.

Andy

KPR · 2010-05-20 14:55

Is this for a new module??

I hope so..

K.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I always have someone watching my back.

Kye · 2010-05-20 15:19

NO
NO
NO
NO
NO
NO!!!

... Need to make this clear but you would need to rewrite the drivers to make them support this kind of setup. If you feel like making the hardware like that then be prepared to rewrite the drivers for the FSRW and the ethernet adapter.

Additionally there will be a pretty significant speed drop. Probably over half. Depending how you have the locks setup.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

jazzed · 2010-05-20 15:59

Kye said...
NO
NO
NO
NO
NO
NO!!!

... Need to make this clear but you would need to rewrite the drivers to make them support this kind of setup. If you feel like making the hardware like that then be prepared to rewrite the drivers for the FSRW and the ethernet adapter.

Additionally there will be a pretty significant speed drop. Probably over half. Depending how you have the locks setup.

Finals week stress induced rant? And rewriting drivers is a problem because?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

Nick McClick · 2010-05-20 16:38

@MAG - it's 50/50. I'm designing it with a specific use in mind, but I'll probably make it available as a module.

@kye - tell me how you really feel

Writing new drivers is not the way I want to go, although jazzed is right - that would be an option.

It sounds like the best approach for me is to use 2 SPI busses. In exchange for 3 I/O, I get faster throughput and an easier interface. Done!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!

Gadget Gangster - Share your Electronic Projects

Kye · 2010-05-21 04:58

@Jazzed

Ha, finals have ended for me.

Rewriting the drivers are a problem because the propeller platform should be able to use the standard drvers available online in the obex. Having to mess with the code is not good.

I'm thinking about what's best for Nick's platform.

@ Nick

I received your package.

No RTC however with it =(.

Thanks!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

jazzed · 2010-05-21 14:00

Kye said...
I'm thinking about what's best for Nick's platform.

That's fine for the average user. However, today's Propeller does not have enough pins for many of us, so saving pins is very important. There is nothing wrong with modifying drivers for those of us who have the skill to and need to do it. I doubt your finals are finally over [noparse]:)[/noparse] Even when they are you'll still have more to learn.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

Nick McClick · 2010-05-21 17:38

@jazzed - I know what you're sayin'. Every design choice is a compromise & I'd rather compromise on ease-of-use, throughput, and compatibility with current drivers. And when the Prop II comes out, I/O will be less of an issue.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!

Gadget Gangster - Share your Electronic Projects

jazzed · 2010-05-21 17:56

Nick McClick said...
@jazzed - I know what you're sayin'. Every design choice is a compromise & I'd rather compromise on ease-of-use, throughput, and compatibility with current drivers. And when the Prop II comes out, I/O will be less of an issue.

Yep [noparse]:)[/noparse]
Like I said. It's fine for the average user. People will do what makes sense to them for their situation.
That's why I used your proposed design over two years ago. BTW: Keep up your good work.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

localroger · 2010-05-22 03:31

I think it's a bad idea because both the SD card and ENC28J60 are high bandwidth devices that transfer fairly large blocks, which ties up the driver completely as far as servicing the other device. I've done some tests sharing SPI RAM with a SD card but the RAM doesn't require block access. Basically both the SD and the ENC28J60 are fairly complex devices requiring blocks of time to complete an operation (don't forget waiting for the SD card to complete a write). Asking them to play together on the same bus, even if you've got the extra clocks in there to make the SD release DO, is going to cause problems.

jazzed · 2010-05-22 18:39

localroger said...
I think it's a bad idea because both the SD card and ENC28J60 are high bandwidth devices that transfer fairly large blocks, which ties up the driver completely as far as servicing the other device.

Since Propeller can't use interrupts, we have no way to tell if a device is finished without polling it. So this is a fair point in that respect. This probably can be handled differently and gracefully.

localroger said...
Basically both the SD and the ENC28J60 are fairly complex devices requiring blocks of time to complete an operation (don't forget waiting for the SD card to complete a write).

I suppose you have to wait for the write to complete to keep the user from pulling the card prematurely. It is most likely possible instead to provide an asynchronous notification that the write is done.

When PropII, TurboProp, or whatever it's called arrives, pin availability will be less of an issue. I wonder if we'll live long enough to see that.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

localroger · 2010-05-23 00:26

jazzed -- when you write to SD, it takes an unknown and possibly very long time to complete the operation depending on what the card has to do to wear-level. If you break the SD connection to the card you will at best not know when the write is complete and it's safe to do another operation, and at worst possibly corrupt the write you've just ordered. The only way to tell when the SD is finished writing is to periodically poll it about its status. It's not about the usual "safe to remove hardware" thing. It's about whether the sector you just wrote was saved on a micro level. The user won't have time to pull the card; you might be talking about 75 msec. But you might have time to miss an ethernet packet while you're waiting.

The SD is a very particular device. You can bus-share it with some things, but I've worked with it and the ENC28J60 and it's my opinion that getting the two things to play together on the same bus is going to be very hard and not work very well no matter what.

jazzed · 2010-05-23 01:35

localroger said...
jazzed -- when you write to SD, it takes an unknown and possibly very long time to complete the operation depending on what the card has to do to wear-level. If you break the SD connection to the card you will at best not know when the write is complete and it's safe to do another operation, and at worst possibly corrupt the write you've just ordered. The only way to tell when the SD is finished writing is to periodically poll it about its status.

It is truly beyond me why dis-engaging the SD device driver to do other things, then re-engaging it for a status poll would somehow cause a failure. Nevertheless, since you have put serious time in it and I have no reason to doubt that, you accumulate substantial credibility. So I'll accept that.

Cheers [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

Nick McClick · 2010-05-24 16:06

@jazzed - If you use it that way (flip on the SD, get data, then stop the cog. Then flip on the enet, do something, then stop the cog), I think it would work fine. I think it gets more complicated when you want to use both at the same time. I'm not sure how common that is, but it would be pretty handy (maybe serving a file from SD to ethernet).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!

Gadget Gangster - Share your Electronic Projects

jazzed · 2010-05-24 22:30

Nick McClick said...
@jazzed - If you use it that way (flip on the SD, get data, then stop the cog. Then flip on the enet, do something, then stop the cog), I think it would work fine. I think it gets more complicated when you want to use both at the same time. I'm not sure how common that is, but it would be pretty handy (maybe serving a file from SD to ethernet).

It would not be possible to leave CS asserted for both devices and expect anything to work with shared IO connections. Access to the devices must be mutually exclusive. There would be no reason to stop COGs. All transactions to/from devices should be with buffered data, so it is unlikely (though possible and unnecessarily complex) to share a buffer with both devices simultaneously even with separate connections. Separate buffering would likely be used even with separate connections.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

localroger · 2010-05-25 00:13

Jazzed is exactly right. Your only hope of making it work is to deassert CS for one side to use the other -- and on the SD side, I can guarantee that the guy who wrote the SD firmware doesn't expect you to do that. SD are famous for not following the SPI spec in plenty of other ways, so it's not clear at all what would happen if you deassert CS during an ongoing write. (It is clear what happens if you deassert CS in the middle of reading or writing a block -- you can't go back and finish the operation.) Going to do other stuff while a write is in process is the kind of thing that might work, might work only on some cards, or might not work at all. It's not clear that the trick of sending extra clocks to get the SD to release DO would work. It's not the kind of thing I'd design a board around.

It's a problem because the ethernet chip is timing critical; it only has memory to cache a few packets and packets can arrive pretty quickly on a local 10baseT ethernet and you don't have control of the timing of incoming packets. It's just a bad combination with another block-hoggy device of any sort, but particularly one that is as finicky as a SD card.

On the plus side though, it has to be admitted that you could probably share a single SPI engine and cog with both devices, since you can't use both at the same time at all. IF you could make it work...

Bill Henning · 2010-05-25 00:48

I agree 100% with localroger.

Mikronauts new uSD/Ethernet module has four pins for each device, precisely because you don't want to try to share an SPI bus between Ethernet and uSD. I expect the final prototype to be in my hands in about two weeks [noparse]:)[/noparse] (yep, another Sapieha work of art) - the initial version worked great with Harrison's stack and fsrw. I won't say more for now... and I don't want to hijack Nick's thread.

On PropCade I do share an SPI bus between SPI ram's, an MCP23S17 IO extender, and a uSD socket - however I expect to complete a uSD transaction, release /CS, and send extra clocks to make sure SO is released.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

Post Edited (Bill Henning) : 5/25/2010 12:54:47 AM GMT

Zap-o · 2010-05-25 02:31

Nick McClick

I was surfing Digikey today and I thought I seen a I2C to SPI converter IC. This may help. Ill see if I cant find that data sheet tomorrow.

* Edited - check out the data sheet It may be an answer

www.nxp.com/documents/data_sheet/SC18IS602_602B_603.pdf

This would mean that no extra pins would be needed and the I2C driver in the obex could be used.

Post Edited (Zap-o) : 5/25/2010 2:37:35 AM GMT

Nick McClick · 2010-05-25 15:04

@Zap-o - That chip is pretty cool - I'll keep it in mind for another design.

I think it's agreed that using both devices on the same buss at the same time is challenging. Something I might do if I had a single design in mind or if I needed the pins, but probably not otherwise.

@bill - Your board sounds really cool! I've been playing with a similiar proto & I've been thinking of doing a webserver (grabbing files from the sd card). Will you have something to show off @ UPEW?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!

Gadget Gangster - Share your Electronic Projects

Mike Green · 2010-05-25 15:18

The I2C/SPI bridge looks like a really nice part. The only problem is that I2C is very limited in speed and the bridge does add more overhead. The bridge looks like it could be used to interface to an SD card, but an Ethernet interface would be problematic because of the things localroger mentioned.

Bill Henning · 2010-05-25 16:43

Thanks Nick!

Yes, I will be bringing it to UPEW... the board is approx. 1.35"x2.50", fits standard 10 pin (+3.3,GND, Pn..Pn+7) connectors - with four pins for the ENC28J60, and four pins for a uSD socket. Harrison's driver works great on an earlier version, and so does fsrw on the uSD side [noparse]:)[/noparse]

As usual, Sapieha made a layout that looks like a work of art!

It should plug right into Jon's platform... SpinStudio... Parallax ProtoBoard's... bread board... my boards [noparse]:)[/noparse] ... any board can become an instant Propeller based webserver!

Once I have tested the final prototypes (I should have them in approx. 2 weeks) I will post pics and order a production run. Initial versions have been working for months.

Nick McClick said...
@bill - Your board sounds really cool! I've been playing with a similiar proto & I've been thinking of doing a webserver (grabbing files from the sd card). Will you have something to show off @ UPEW?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

sergiotux · 2014-07-11 06:53

Hi, my name is S

Ethernet and SD card on same SPI buss?

Comments