How is the SD card connected to the 3v3 pro mini?

When it does work I suspect you will drop data points.  Often write takes much longer than 2 ms.

Does that matter?

Also the 3v3 pro mini is 8 MHz so writing the SD will take even longer.

Normally you only need to call SD.begin() once in setup().

If you change SD cards, SD.begin() must be called before the new card can be used.

The begin() function has a problem with multiple calls.  See this:

http://arduino.cc/forum/index.php/topic,66415.0.html

SD.h is a wrapper for an old version of the SdFat library.  This older version of SdFat does not coexist as well with other SPI devices as newer versions of SdFat.

You may want to use the newest version of SdFat without the SD.h wrapper.  SdFat is here:

http://code.google.com/p/sdfatlib/

The SD has a lot of overhead between blocks and can be busy at times.  I use two 512 byte buffers to record mono.

I think a Mega would be required for more buffering.

You can't do the four byte thing. 

Can't help with a repair program.  I don't trust them.

There is no easy way to know what Windows has found.  I have programs that help find problems with file systems but these programs are tools, not somthing others could use.

The only possibility I can think of is parallel read from the ADC.  On the 328 you would need to use pins 0 - 7. They are port D.

You just can't write to memory, read back, and write to an SD.  The max speed of SPI, 8 MHz, is a killer.

I2C is way too slow for ADCs, 400 kHz max.

A microSD module would be easy to use. Several companies have modules like this:

https://www.adafruit.com/products/254

I have used DataFlash on on a small Sparkfun Arduino Pro Mini.

This is a 4 MB part.

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=AT45DB321D-SU-ND

It is in a SOIC-8 package which is not to bad to solder to an DIP-8 adapter.

CMD26 is reserved.  If your card allows CMD26, it may not work properly.

CMD26 should not be supported in SPI mode.

From the SD association:

CMD26 PROGRAM_CID

Programming of the card
identification register. This
command shall be issued only
once. The card contains
hardware to prevent this
operation after the first
programming. Normally this
command is reserved for the
manufacturer.

I was talking about recording audio on the Arduino using a simple ADC.  I have recorded mono at 44.1 ksps on the Arduino.

You can't use the hardware SPI bus that the SD is on for the ADCs.  SD cards do not allow interruption of a 512 byte block transfer.  CS must be kept low for the whole transfer.

With higher powered processors like ARM with a 4-bit SDIO bus and a fast I2S bus, recording stereo is easy.  There are wonderful cheap codecs you can use with higher power processors

I don't think 16-bit stereo audio at 44.1 ksps is possible.  But I have been thinking about it for a while.

I can write a 512 byte block to SD in about 900 microseconds using a special multi-block write command.  So about 1/3 of the CPU is needed for SD write at 176.4 KB/sec.

I am going to do an experiment reading out two ADC in parallel using bit-bang.  I will connect a single pin to clock on both ADCs but have separate pins for data out.  For ADCs that need input I would use a common data in pin.

My guess is that it will take too long.

I just did a bit-bang library for a number of Microchip SAR ADCs.  For the MCP3201 I can get a reading in 9 microseconds.   This requires two bytes and is the maximum spec speed for this ADC.  I use a few nops to get a nice clock.

I did bit-bang SPI for SD cards as an option in the SdFat library, the base for Arduino SD.h.  I get about the equivalent of 2.5 MHz SPI clock.

My estimate is bit-bang SPI is about 1/3 as fast as full speed hardware SPI.

I like bit-bang for ADCs in ISRs.  That leaves hardware SPI free for non-interrupt use.

Coding Badly,

Thanks for finding this.

Jeremyvnc sent me a bug report on this for SdFat.  I did a quick test of the I2C stuff and it was OK.  I felt a bit guilty that I didn't spend more time looking at his code.

I just don't have the time any more to find user bugs.  I get so much mail about SdFat since it was used as the base for SD.h.

Over 90% of the time this type of bug is a corrupt stack that kills SdFat.

 

SD cards use SPI mode 0.

SD.h is a wrapper for an old version of my SdFat library that does not reinitialize the SPI registers.

You will need to restore the SPI mode if you use SD.h.

The new version of SdFat, http://code.google.com/p/sdfatlib/downloads/list, sets all SPI options each time it accesses the SPI bus.

I have am developing a new GPS library and need advice on which GPS modules to support.

I used an EM-406A on an Adafruit GPS shield for the first version http://code.google.com/p/beta-lib/downloads/list.

I am considering a Lassen IQ module next. The IQ is old but it is often used for high altitude logging since it works above 60,000 feet at lower speeds.

The GPS shield supports a connector for the IQ but it doesn't bring out Port 1, the TSIP/TAIP bi-directional port. This means I can't configure the module when it is mounted on the GPS shield. I already parse the default NMEA messages from the Lassen IQ.

Any advice or suggestions for other modules. The module doesn't need to be mounted on the GPS shield.

SdFat was not designed to be used in an interrupt routine.  Writing to an SD with file I/O takes too long to be reasonable in an ISR.

If you need to log data in a timer ISR see the fastLogger examples here http://code.google.com/p/beta-lib/downloads/list.