SD-Card & EEPROM on SPI

Log in or register to post comments
Go To Last Post
11 posts / 0 new
Author
Message
Rooney
Rooney's picture
Level: Wannabe
Joined: Tue. Nov 27, 2018
Posts: 53 View posts
#1
Posted by Rooney: Mon. Aug 19, 2019 - 12:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a project that uses an SD Card on the SPI interface.  I also wanted to add a small amount of extra EEPROM.  The EEPROMs come in SPI and TWI interfaces.  I only have one free pin right now so TWI would mean sacrificing something else, shuffling things around to end up with two free TWI pins, and adding a pullup resistor on the SDA line.  It would seem that SPI would save me a pin and a resistor because I would use the same SPI bus and just need any single GPIO for CS of the EEPROM. 

 

I'm currently using Petit FatFS for SD-Card access.  If I share the SPI bus with the EEPROM I presume I'll need to un-mount the SD-Card (if it was previously used) before switching to the EEPROM?  I don't think Petit FatFS's pf_mount can un-mount, unlike full FatFS's f_mount which says it can 'Register/Unregister the work area of the volume.'  Does de-asserting the SD-Card's CS pin accomplish the same thing, more or less?  Does this even matter since I would re-initialize and mount the card if I need to access it again later?  Neither the SD-Card or EEPROM will be accessed regularly, and sometimes never.  Is there a reason I shouldn't rule out a TWI EEPROM?

 

Thank you.

 

 

 

 

  

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
DocJC
DocJC's picture
Level: 10k+ Postman
Joined: Tue. Dec 11, 2007
Posts: 13024 View posts
Location: Cleveland, OH
Posted by DocJC: Mon. Aug 19, 2019 - 01:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have a testbed / prototype that you can add the eeprom to and give it a try?

 

In theory, yes you can put multiple devices on the spi bus as long as they all have their own CS\ line.

 

Life is easier if the bus speed and configuration don't change between devices.

 

Make sure that you don't have an Interrupt, or other code, that will interrupt one data transaction on one device with bus activity intended for the other device.

 

JC

Top
Silver Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99956 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Aug 19, 2019 - 01:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was just reading:

 

http://elm-chan.org/docs/mmc/mmc_e.html

 

" In principle of the SPI mode, the CS signal must be kept asserted during a transaction. However there is an exception to this rule. When the card is busy, the host controller can deassert CS to release SPI bus for data transfer to other SPI devices on the bus. "

Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 21388 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Mon. Aug 19, 2019 - 02:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use a shared SPI bus that services a micro-SD card and an acceleration sensor. They co-exist quite adequately.

 

I am careful to write the code so that there is no physical conflict (e.g. neither is accessed inside an ISR). Yes, sensor data-available is served from an ISR, but that only sets a flag to trigger access in the main service loop. No conflict.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Top
Silver Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99956 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Aug 19, 2019 - 02:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim,

 

So if you de-assert the CS to the SD card after the card init has been done it does stay active and ready for the next command? it's not like the card init has to be done again each time you assert CS ?

 

(I worried that the card might "go to sleep" if left for a while without being selected but maybe not?)

Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 21388 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Mon. Aug 19, 2019 - 03:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have not seen that. 

 

What I have seen under some circumstances is that it takes forever to write a page of data. FatFs tries and retries and the card does not acknowledge. In some cases, 100's of milliseconds. This has long made me uneasy because of the seeming randomness of it all. There is some dependency on what the program tries to do and I have not been able to make much sense of it. As currently  configured, it seems to be working OK. 

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Top
Rooney
Rooney's picture
Level: Wannabe
Joined: Tue. Nov 27, 2018
Posts: 53 View posts
Posted by Rooney: Mon. Aug 19, 2019 - 04:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Do you have a testbed / prototype that you can add the eeprom to and give it a try?

 

Yes, I certainly will retrofit one to my prototype.  My questions here were a precursor to that, to discover if I might be barking up the wrong tree.  Thank you for you comment about ISR's.

 

clawson wrote:
I was just reading: http://elm-chan.org/docs/mmc/mmc_e.html

" In principle of the SPI mode, the CS signal must be kept asserted during a transaction. However there is an exception to this rule. When the card is busy, the host controller can deassert CS to release SPI bus for data transfer to other SPI devices on the bus. "

 

Thanks Clawson.   I've ready that page numerous times too, but at the time I guess the info wasn't relevant enough to stick.   This phrase kind bothers me though... "When the card is busy, the host controller can deassert CS to release SPI bus for data transfer to other SPI devices on the bus."  It sounds like it's saying to disable the SD-card while it's in the process of doing something?

 

ka7ehk wrote:

I use a shared SPI bus that services a micro-SD card and an acceleration sensor. They co-exist quite adequately.

I am careful to write the code so that there is no physical conflict (e.g. neither is accessed inside an ISR).

 

Thank you for your first hand experience.  I think it's time to do a mockup and try it out.

Top
Simonetta
Simonetta's picture
Level: Raving Lunatic
Joined: Wed. Mar 12, 2003
Posts: 2915 View posts
Location: Portland, Oregon USA
Posted by Simonetta: Mon. Aug 19, 2019 - 11:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you can't do SPI and (I2C) TWI at the same time and you are interfacing with an SD card, then you need a bigger CPU variant.   I recommend the ATmega328P found on the Arduino Nano and ProMini.

 

Leave the SD card's software access unchanged.  Let the "official" SPI routines found in Petit FAT operate unimpeded. They are too complex and intricate to risk breaking by manipulating the pre-written SPI routines.  Petit FAT is supposed to handle all this for you.

 

Use bit-banging [setting and clearing the CS, SCK, and SDA pins individually] to mimic an SPI interface if you can't implement a TWI interface.

Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 21388 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Tue. Aug 20, 2019 - 12:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am mixing a sensor and a microSD on the same SPI bus. No bit bang needed. The code is arranged so that the cannot collide (one does not proceed until the other is finished). No problems!  FatFs drives the memory card and normal bare-metal SPI drives the sensor.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39868 View posts
Location: Wisconsin USA
Posted by theusch: Tue. Aug 20, 2019 - 01:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
(I worried that the card might "go to sleep" if left for a while without being selected but maybe not?)

I have a line of production apps, over a decade in production, with SD card and RTC (DS1305) on the same SPI.  There is "on demand" stuff", but the RTC is hit twice a second, and the SPI card could be idle for a long time when the system is quiet/idle and there are no log records.  RE-init is done only when an operation fails.

 

The biggest caveat IME is to use a weak pulling resister to ensure that all the devices are de-selected when the AVR is in reset, so the attached devices won't get confused by e.g. ISP.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
alank2
alank2's picture
Level: Raving Lunatic
Joined: Thu. Jul 16, 2009
Posts: 2933 View posts
Posted by alank2: Tue. Aug 20, 2019 - 02:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


FATFS (and I presume PetitFS too) releases the SS when it is not actively doing something, so you should be able to share the SPI with another device.

 

 

Autoprogrammer:

https://www.avrfreaks.net/forum/wts-standalone-pdiisp-auto-programmers

Top