External storage: USB or SD card?

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I need to design a board that will have to access external, removable storage of less than 5MB.  The CPU needs to be an AVR with a USART and a handful of GPIO.  The most CPU-intensive thing it will be doing is reading data from the external storage medium and outputting it on the USART at about 500 kbps.  A USB thumb drive or SD card would seem to be the obvious choices, but I've never interfaced to either.  I was wondering if one were obviously better or easier to implement than the other.  I realize there are AVRs that handle most of the h/w interface for USB, and SD cards are SPI-based, so that h/w is also covered by the AVR, so I assume it's mostly a s/w question.  Am I mistaken?  If not, is the s/w side easier for one than the other?  I'll be using C, so I assume it's mostly a question of finding and implementing the right library, but, again, I'm assuming.  Thanks for any tips.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

500kbps?  For how long?  Outputting a sound bite?

 

Do some back-of-the envelope calculations first.  What SPI bit rate do you think you will need to sustain that throughput?

 

What do you mean by "USB"?  Are you prepared to jump in and try to become a USB Host?

 

Start with ELMChan  http://elm-chan.org/ http://elm-chan.org/fsw/ff/00ind...

 

Of particular interest might be http://elm-chan.org/fsw/ff/res/r...

 

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> For how long? 

 

About 3 ms., then idle for about 60 ms., then repeat.  I'm only transferring about 1500 bits at that max. rate.

 

> Do some back-of-the envelope calculations first.  What SPI bit rate do you think you will need to sustain that throughput?

 

I haven't dug into the overhead for either SPI or USB yet as I was hoping to eliminate one or the other at this initial pass.  My impression was that USB was going to be a much bigger hassle than SD, but I wasn't sure.  Hence the post.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lautman wrote:
My impression was that USB was going to be a much bigger hassle than SD
theusch wrote:
What do you mean by "USB"?

Are you takling about a memory stick?  Or a USB connection to an outside host?

 

 

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lautman wrote:
I'll be using C, so I assume it's mostly a question of finding and implementing the right library, ...
Will the operator of the board be able to mate it to a USB host?  (Android, iOS, etc)

If yes there's USB MSC and LUFA for megaAVR and ASF for XMEGA AVR.

http://www.fourwalledcubicle.com/files/LUFA/Doc/170418/html/group___group___u_s_b_class_m_s.html

http://asf.atmel.com/docs/latest/xmegac/html/group__udi__msc__group.html

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only 8bit AVRs that can host a USB memory stick are AT90USB647 and 1287. No other AVR8 has the complex USB OTG peripheral so the question really becomes "do 648/1287 offer all the other peripheral features the system design requires?".
.
But, really, FAT on SD/MMC is about 10 times simplet so you probably need a pretty strong reason to choose USB-MSD

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Memory stick.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Will the operator of the board be able to mate it to a USB host?

No. The board will either receive a memory stick or SD card. Sounds like SD is the way to go.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using uSD cards on a data logger. Making a 40-odd byte write up to about once every 10ms, often slower. I am using the elmChan library. 

 

One posible major "issue" is that you really do not really want interrupts during the time it transfers the 256 byte buffer via SPI into the memory. For me, that is taking up to 900uS. It is capable of running faster but I chose not to push it. I have an 8MHz system and the SPI clock is Fcpu/4. 

 

USB is a major pain because you have to implement either a standard USB HOST or USB ON-THE-GO device. That is more complex than a standard USB client device.

 

Jim

 

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

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You may have spotted that almost every AVR design that involves mass storage has gone for the SD/MMC option (also probably your phone and your camera etc).
.
Of course if really want to get "down with the kids" these days you add a radio link (wifi, Bluetooth, etc) and request/send your data off either to be read/stored in a nearby phone or, more likely, "the cloud".

Last Edited: Fri. Jul 20, 2018 - 07:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
One posible major "issue" is that you really do not really want interrupts during the time it transfers the 256 byte buffer via SPI into the memory.

 

OK, I'll bite -- where is the issue?

 

I have a series of controllers that are now about 10 years old, with many thousands of units in the field.  Each has an SPI link with SD card and RTC; some configurations have an additional SPI peripheral.

 

The logging is done with a complete "sector" write of 512 bytes.  There are other manipulation as well; updating part of a record; read-back for display; and similar.

 

There are a number of other interrupt sources active, including up to four interrupt-driven USART links, timers, and ADC.

 

Given that, it is obvious that from time-to-time and not that rarely that an interrupt hits in the middle of an f_write().  If there was an "issue", I'd know about it.

 

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe I am incorrectly remembering from the docs. I think that, maybe, when I was having problems early on, it was sleeping in the middle of the transfer. Now, I hold off on the sleep if a transfer lasts longer than the awake time.

 

Jim

 

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

 

 

Last Edited: Fri. Jul 20, 2018 - 10:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lautman wrote:
The CPU needs (sic?)  to be an AVR

Why does the CPU need to be an AVR ?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...and define "AVR".  I'll make my speculation that OP is fairly new to the employing organization and has been put to a particular task, and the organization already has tools for some range of Atmel/AVR processors.  A number of other similar scenarios that "make sense" come to mind.  For example, an off-shore cut-rate design firm that got a low-ball priced contract and now has no idea how to proceed.

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Why does the CPU need to be an AVR ?


This is for a personal project. AVR (as in Mega or Tiny; I’ve done a couple of Xmega projects and never got comfortable with it) is what I’m familiar with and have the toolchain for. I’m pretty sure there are several chips in the family that can pull this off, and I’m only making a couple of boards, so I’m not price-sensitive. It’s not worth learning, and tooling up for, another family.

Last Edited: Sat. Jul 21, 2018 - 01:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lautman wrote:
SD cards are SPI-based

Not really.

 

SPI is provided as an "alternate" interface for constrained systems which can't manage the full SDIO interface.

 

There are frequent FUD stories about the SPI mode being discontinued, or not available on some cards ...

 

EDIT

 

As already mentioned, Elm-Chan has loads on this: http://elm-chan.org/docs/mmc/mmc_e.html

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Sat. Jul 21, 2018 - 01:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

True, I was being sloppy. I believe the high-speed SD interface is over four data wires plus clock and control, not SPI. In any event, it’s within the ability of basic AVRs at the h/w level, and, as you and others have pointed out, elm-chan greatly simplifies the s/w. Looks like it’s time to dig into all that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FatFS is pretty much the de-facto Open-Source library for accessing SD Cards from any small(-ish) microcontroller.

 

As a member since 2003, it's surprising if you haven't noticed it.

 

Apart from the Elm-Chan site itself, there is a Tutorial here - and a vast number of previous threads.

 

No doubt Atmel Microchip also have an App Note ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> As a member since 2003, it's surprising if you haven't noticed it.
Just never needed it till now.

> there is a Tutorial here

Can you point me to it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its in the tutorial forum ;-)
.
While search here isn't great you can filter results by forum so start by searching "fatfs" then filter for "forum = tutorial".
.
Be warned it's a very long thread but id recommend reading it all. Note that Chan keeps changing FatFs (for AVR) so some of the older stuff in the thread is way out of date at this stage.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
No doubt Atmel Microchip also have an App Note ...

Microchip Technology Inc

Microchip Technology

Application Notes

AN2543 AVR42780: Temperature Logger with ATtiny817 and SD Card-v2

http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en592095

...

... and the data is written to an SD card via an SPI interface using the ELM-Chan Petit FAT file system library.

...

via https://www.microchip.com/wwwproducts/en/ATMEGA4809

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
SPI is provided as an "alternate" interface for constrained systems which can't manage the full SDIO interface.

"Manage" is one thing, I guess.  Why do I seem to recall that using the native interface required a license?

 

From The Wikipedia article on SD cards:

Transfer modes

Cards may support various combinations of the following bus types and transfer modes. The SPI bus mode and one-bit SD bus mode are mandatory for all SD families, as explained in the next section. Once the host device and the SD card negotiate a bus interface mode, the usage of the numbered pins is the same for all card sizes.

  • SPI bus mode: Serial Peripheral Interface Bus is primarily used by embedded microcontrollers. This bus type supports only a 3.3-volt interface. This is the only bus type that does not require a host license.
  • One-bit SD bus mode: Separate command and data channels and a proprietary transfer format.
  • Four-bit SD bus mode: Uses extra pins plus some reassigned pins. This is the same protocol as the one-bit SD bus mode which uses one command and four data lines for faster data transfer. All SD cards support this mode. UHS-I and UHS-II require this bus type.
  • Two differential lines SD UHS-II mode: Uses two low-voltage differential interfaces to transfer commands and data. UHS-II cards include this interface in addition to the SD bus modes.

Note the "This is the only bus type that does not require a host license."

 

lautman wrote:
I believe the high-speed SD interface is over four data wires plus clock and control, not SPI. In any event, it’s within the ability of basic AVRs at the h/w level, and, as you and others have pointed out, elm-chan greatly simplifies the s/w. Looks like it’s time to dig into all that.

You are losing me.  I can't recall anyone here that is using the native interface.  Speak up, then -- AVR8 can "manage" it?  And I don't remember anything on ElmChan on other than SPI, HW or SW.

 

For plebians, it is SPI IMO/IME.  Chip select, clock, data in, data out.  Using the AVR's SPI peripheral.

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.

Last Edited: Sun. Jul 22, 2018 - 01:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Why do I seem to recall that using the native interface required a license?

I'm not sure if it's using the SDIO interface which requires the licence, or just the fact that the SDIO protocol documents are not available to non-members of the SD Association

 

 

Note the "This is the only bus type that does not require a host license."

Note also that only "Four-bit SD bus mode" is marked as "All SD cards support this mode".

 

And I don't remember anything on ElmChan on other than SPI, HW or SW.

FatFs is not specific to SD Cards, nor to their SPI mode; I believe that some  use it in 4-bit mode on chips which have an SDIO hardware peripheral.

That would not be any 8-bit AVRs, AFAIK.

 

 

AVR8 can "manage" it?  

With no hardware support, I guess you'd have to bit-bang it?

Which probably means that it would, then, have no advantage over SPI?

 

 

I can't recall anyone here that is using the native interface

No. But the OP made the assertion, "SD Cards are SPI";  which is not true - the cards themselves, as you have shown, are capable of several other modes.

 

But, yes - on an AVR8 (or any other microcontroller without dedicated SDIO), SPI is the way "everyone" does it.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
I'm not sure if it's using the SDIO interface which requires the licence, or just the fact that the SDIO protocol documents are not available to non-members of the SD Association

 

The SD Card Association wrote:

Any implementation of the Simplified Specifications or any portions thereof may require a license from the SD Card Association, SD Group, SD-3C, LLC or other third parties.

 

https://www.sdcard.org/downloads/pls/

 

More on licensing: https://www.sdcard.org/developers/licensing/index.html

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...