You need to patch the SD.h library.  Add root.close() to begin().

Here is a link to more info: http://arduino.cc/forum/index.php/topic,66415.0.html

I have posted a version of SdFat with changes for Arduino 1.0 beta 4 here:

http://code.google.com/p/beta-lib/downloads/list

The file is: SdFatBeta20110917.zip

Please try it with Arduino 1.0 beta 4 and report any bugs.

I did edits to make Fat16 compile with both 0022 and Arduino 1.0 beta 4.

I did some tests but Arduino 1.0 can break many things so report bugs.

The library is here http://code.google.com/p/beta-lib/downloads/list

The file is fat16libBeta20110917.zip.

I don't use the SPI library.  I setup the bus before every access.

Most devices don't have problems since many New SD cards release the bus.  Most SPI devices don't use the first MISO bit on the leading edge of clock.

You are wrong about 8 clocks for SD cards.  MMC cards require 8.  SD cards release on the edge of the first clock. That's why many devices share o.k.

You are the first to notice the problem.  What device are you using?

markT,

The SD Physical Layer Spec does not say the initial clock must be 380 to 420kHz.  It suggests  a clock rate of 100 - 400 kHz.  Modern SD cards can be initialized at much higher SPI speeds.

The reason is that this allows you to identify MMC cards.  I have experimented with about 20 old cards and use F_CPU/64 which is 250 kHz.  The clock divisor for card initialization is an option that can be set in the SdFatConfig.h file from F_CPU/128 to F_CPU/2.

I now understand what you mean by the state of MISO.  In past versions of SdFat I tried to do the right thing for each operation to insure I read enough data so MISO would be released.  This is not very reliable since there are still cases where at least one more clock is required.  MMC cards can require eight clocks but I don't support them, only identify them and give an error code.

I now have a chipSelectHigh() routine and will write a byte after setting CS high.  This version of SdFat will be released after Arduino 1.0 is released.

Your error:

SD errorCode: 0X1
SD errorData: 0XFF

Means that your card did not accept the first command, CMD0, and timed out after two seconds.  This means SdFat does not see the card on the SPI bus.

I don't think the SPI pins are connected to shield pins 11, 12, and 13.  They are connected to the ICSP header so the Ethernet shield will work on either a 328 or Mega.

http://arduino.cc/en/uploads/Main/arduino-ethernet-shield-05-schematic.pdf

I don't know what MarkT means by

Code:

driving the SPI bus too slow and not releasing MISO

SD cards are initialized at a slow SPI speed and after initialization the spec allows a wide range of speeds.  

On the Arduino, the state of MISO is controlled by the SPI hardware and the devices/shields connected to MISO.  There are no software options to control MISO.  MISO is an input.

It's not clear exactly how it will be used, but it's at least potentially far from "useless"...

I rest my case.  So far only speculation that it might have some unknown use.

serialEvent() is not an asynchronous event, It happens right after you exit loop(), not when a character is received.  This means it is equivalent to adding a call at the beginning of loop().  A function call in loop() could be cleaner since it could return status.

Show me an example where serialEvent() is a big improvement over adding a single line at the beginning of loop() that calls the user's function for processing Serial input.

My speculation is that serialEvent() was invented to add two usec between loop calls on a 328 and six usec between loop() calls on a Mega.  This seems fairly harmless.

Looks like is started as a call from the Serial RX ISR at interrupt level but has evolved to a call from main() between calls to loop(). 

It is now a more or less useless addition.  At least it is small and won't burn too many CPU cycles.

What is the reason for serialEvent() in Arduino 1.0 beta 4?

It doesn't run at interrupt level so it seems equivalent to adding the following to loop() by a user.

Code:

  if (Serial.available()) serialEvent();

It's not a big deal but I am curious why this was done.

Independent of SD libraries, I am interested in a replacement for HardwareSerial with the same API. 

I have done enough code to know that I can produce a smaller library with all the functionality of HardwareSerial in 1.0 beta 4 and independently specify the size of every buffer at compile time.  This is a transparent replacement.

I think I can make a version that is smaller than 1.0 beta 4 with run time sizes if the buffers are user defined static arrays.

I am working on a version that uses malloc/free and it look like it will be 200-500 flash bytes larger than 1.0 beta 4 if you are not using malloc/free for other purposes in your sketch.

I have made this library start in unbuffered mode.  It starts with 0022 style output.  It has just the three characters of hardware input buffering, the two level receive data register and the receive shift register.  Overflow happens when the start bit for the fourth character is detected.

In this mode it is very small and works with most simple sketches that do limited input.

You can call a buffer allocation function to allocate rx and tx buffers and use interrupts.  Calling this function causes malloc/free to be loaded.  It looks like the total flash size will then be 200-500 bytes larger than 1.0 beta 4.

My SdFat library does not use malloc/free. 

I really don't like using the heap in embedded systems except at system start-up.

I worked with critical systems where programming standards forbid using the heap after system start-up.

The Joint Strike Fighter standard is typical http://www2.research.att.com/~bs/JSF-AV-rules.pdf.

Fragmentation of the heap can cause a stack overflow crash with lots of free memory in small chunks in the heap.

I suggest you read the SD protocol spec.  Your ideas are not even close to possible.

Good luck detecting the difference between data, commands, and status.

How do you handle command status?   Both cards send status after a command.  Which status do you send on the SPI bus to the Arduino?

SD cards rarely fail.  Most lost data is due to software bugs, unexpected reboots, or power down during a write.

Parallel cards won't help much.

You could write your precious data to two cards.  SdFat supports multiple cards on the SPI bus.  You could have a file open on each card and write your data to both files.  It is likely one card will survive a reboot or power down.

You would need to use a Mega since each card requires a 512 byte cache.  Only very small apps can support two cards on a 328.

I agree that it should be easier to override core functions like Serial.

No you can't allocate 2,500 bytes on a 328.  But you can make the input buffer twice as large in 0022 as you will be able to in 1.0.

Here is a user who is logging serial data to an SD at 3088 bytes per second on a 328 by setting the receive buffer size to 600.  This won't be possible with 1.0.

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

Sometimes you want no output buffering and very small input buffers, just enough for debug of a sketch that won't use Serial but uses a lot of RAM.  Other time you want large buffers.  You don't want to edit core files for each app.

In 1.0 you lose more control.

I am close to finishing a reimplementation of HardwareSerial with run-time buffer sizes.  It will be interesting to see how much larger it will be.

This will never work! 

Two identical cards will not have the same timing because no two cards are identical.  Flash has bad spots that are remapped.

The delays happen due to the flash controller in the cards doing wear leveling, flash erase of large blocks, remap of bad spots, and other operations. 

The timing of two cards will never allow parallel operations because no two cards behave the same.

I agree, you should be able to use malloc().

I have been working on a personal replacement for HardwareSerial.  If you only call begin(), it uses no buffers and no interrupts.  Even sketches with some input work since they tend to read in a tight loop and the serial hardware has a two level input buffer register and an input shift register.

I have two calls to connect interrupts with buffers, one call that uses malloc and sets a status bit to remember to call free and one call to use static arrays in the sketch.

Code:

 bool connectInterrupt(size_t rxSize, size_t txSize); // uses malloc
  bool connectInterrupt(uint8_t* rxBuf, size_t rxSize, uint8_t* txBuf, size_t txSize);

If a buffer is zero length, the corresponding RX or TX will not use interrupts.

There is no non-blocking API for SD cards.  The SD spec allows a SD card to go busy for up to 250 ms after you send the data.  You can't determine if the write was successful until after the busy period.  You must wait if busy happens when you are writing a file structure because you have not written data from  the callers buffer.

Even if you could do something else you need the buffering for incoming serial data.

I know that all serial buffers are the same size for a Mega in 0022.  0022 was bad but 1.0 is worse, there are twice as many buffers.

The SD is only one example.  Large serial buffers are useful for other apps.  What is this bell curve that defines proper use of serial?  When is a serial buffer too large?

There is no technical excuse for not having run-time buffer sizes for serial ports.  Commercial embedded kernels have supported run-time serial buffer sizes for thirty years.

Forty years ago I wrote a serial handler for a PDP-8e with run-time buffer sizes.  This machine had 8K words where a word was 12-bits.