Popular Threads From Developers:
List Statistics
- Total Threads: 675
- Total Posts: 2049
Phrases Used to Find This Thread
|
# 1

20-01-2011 08:30 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
|
# 2

11-02-2011 05:11 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
|
# 3

18-02-2011 12:14 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
|
# 4

18-02-2011 03:24 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
|
# 5

18-02-2011 03:26 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
|
# 6

18-02-2011 03:27 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
|
# 7

18-02-2011 08:51 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
|
# 8

23-02-2011 02:07 AM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
# 9

23-02-2011 02:47 AM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
# 10

23-02-2011 04:25 AM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
2011/2/22 Tom Igoe <>:
> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
What do you mean by turning it off and on? Is acceptable to have a
way to open the file in buffered or unbuffered mode, with an explicit
sync option for buffered mode? Or do you think we need to be able to
dynamically switch between buffered and unbuffered modes? If the
latter, why? Or maybe we can get away with simply using buffered mode
all the time, and having people sync when needed?
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
I did this at one point during development, but it seemed unnecessary
given that you can delete the file before opening it. Would you want
to go back to having FILE_APPEND or FILE_REPLACE instead of
FILE_WRITE? Or distinguish the two some other way?
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
>> >> Developers mailing list
>> >>
>> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>> >>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
# 11

23-02-2011 04:27 AM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
2011/2/22 Tom Igoe <>:
> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
What do you mean by turning it off and on? Is acceptable to have a
way to open the file in buffered or unbuffered mode, with an explicit
sync option for buffered mode? Or do you think we need to be able to
dynamically switch between buffered and unbuffered modes? If the
latter, why? Or maybe we can get away with simply using buffered mode
all the time, and having people sync when needed?
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
I did this at one point during development, but it seemed unnecessary
given that you can delete the file before opening it. Would you want
to go back to having FILE_APPEND or FILE_REPLACE instead of
FILE_WRITE? Or distinguish the two some other way?
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
>> >> Developers mailing list
>> >>
>> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>> >>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
That could be very useful. What do you have in mind for the API?
2011/2/22 Limor <>:
> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
> Â i have some code on github but its very much in progress
>
>
> On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
>
>> Â Â Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. Â But working on both, we ran across two important needs:
>>
>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. Â This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
# 12

23-02-2011 11:21 AM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
2011/2/22 Tom Igoe <>:
> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
What do you mean by turning it off and on? Is acceptable to have a
way to open the file in buffered or unbuffered mode, with an explicit
sync option for buffered mode? Or do you think we need to be able to
dynamically switch between buffered and unbuffered modes? If the
latter, why? Or maybe we can get away with simply using buffered mode
all the time, and having people sync when needed?
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
I did this at one point during development, but it seemed unnecessary
given that you can delete the file before opening it. Would you want
to go back to having FILE_APPEND or FILE_REPLACE instead of
FILE_WRITE? Or distinguish the two some other way?
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
>> >> Developers mailing list
>> >>
>> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>> >>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
That could be very useful. What do you have in mind for the API?
2011/2/22 Limor <>:
> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
> Â i have some code on github but its very much in progress
>
>
> On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
>
>> Â Â Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. Â But working on both, we ran across two important needs:
>>
>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. Â This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
t.
On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
> 2011/2/22 Tom Igoe <>:
>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> What do you mean by turning it off and on? Is acceptable to have a
> way to open the file in buffered or unbuffered mode, with an explicit
> sync option for buffered mode? Or do you think we need to be able to
> dynamically switch between buffered and unbuffered modes? If the
> latter, why? Or maybe we can get away with simply using buffered mode
> all the time, and having people sync when needed?
>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> I did this at one point during development, but it seemed unnecessary
> given that you can delete the file before opening it. Would you want
> to go back to having FILE_APPEND or FILE_REPLACE instead of
> FILE_WRITE? Or distinguish the two some other way?
>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
# 13

23-02-2011 01:43 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
2011/2/22 Tom Igoe <>:
> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
What do you mean by turning it off and on? Is acceptable to have a
way to open the file in buffered or unbuffered mode, with an explicit
sync option for buffered mode? Or do you think we need to be able to
dynamically switch between buffered and unbuffered modes? If the
latter, why? Or maybe we can get away with simply using buffered mode
all the time, and having people sync when needed?
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
I did this at one point during development, but it seemed unnecessary
given that you can delete the file before opening it. Would you want
to go back to having FILE_APPEND or FILE_REPLACE instead of
FILE_WRITE? Or distinguish the two some other way?
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
>> >> Developers mailing list
>> >>
>> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>> >>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
That could be very useful. What do you have in mind for the API?
2011/2/22 Limor <>:
> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
> Â i have some code on github but its very much in progress
>
>
> On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
>
>> Â Â Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. Â But working on both, we ran across two important needs:
>>
>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. Â This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
t.
On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
> 2011/2/22 Tom Igoe <>:
>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> What do you mean by turning it off and on? Is acceptable to have a
> way to open the file in buffered or unbuffered mode, with an explicit
> sync option for buffered mode? Or do you think we need to be able to
> dynamically switch between buffered and unbuffered modes? If the
> latter, why? Or maybe we can get away with simply using buffered mode
> all the time, and having people sync when needed?
>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> I did this at one point during development, but it seemed unnecessary
> given that you can delete the file before opening it. Would you want
> to go back to having FILE_APPEND or FILE_REPLACE instead of
> FILE_WRITE? Or distinguish the two some other way?
>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
By buffered, I mean with O_SYNC off, when writes are buffered in the
memory of the microcontroller before being written to the SD card.
The flush() command will force a sync.
2011/2/23 Tom Igoe <>:
> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>
> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>
> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>
> t.
>
> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>
>> 2011/2/22 Tom Igoe <>:
>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> What do you mean by turning it off and on? Â Is acceptable to have a
>> way to open the file in buffered or unbuffered mode, with an explicit
>> sync option for buffered mode? Â Or do you think we need to be able to
>> dynamically switch between buffered and unbuffered modes? Â If the
>> latter, why? Â Or maybe we can get away with simply using buffered mode
>> all the time, and having people sync when needed?
>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> I did this at one point during development, but it seemed unnecessary
>> given that you can delete the file before opening it. Â Would you want
>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>> FILE_WRITE? Â Or distinguish the two some other way?
>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe <>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis" <>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe <>
>>>>> Cc: Arduino Developers <>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. Â This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
# 14

23-02-2011 02:12 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
2011/2/22 Tom Igoe <>:
> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
What do you mean by turning it off and on? Is acceptable to have a
way to open the file in buffered or unbuffered mode, with an explicit
sync option for buffered mode? Or do you think we need to be able to
dynamically switch between buffered and unbuffered modes? If the
latter, why? Or maybe we can get away with simply using buffered mode
all the time, and having people sync when needed?
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
I did this at one point during development, but it seemed unnecessary
given that you can delete the file before opening it. Would you want
to go back to having FILE_APPEND or FILE_REPLACE instead of
FILE_WRITE? Or distinguish the two some other way?
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
>> >> Developers mailing list
>> >>
>> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>> >>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
That could be very useful. What do you have in mind for the API?
2011/2/22 Limor <>:
> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
> Â i have some code on github but its very much in progress
>
>
> On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
>
>> Â Â Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. Â But working on both, we ran across two important needs:
>>
>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. Â This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
t.
On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
> 2011/2/22 Tom Igoe <>:
>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> What do you mean by turning it off and on? Is acceptable to have a
> way to open the file in buffered or unbuffered mode, with an explicit
> sync option for buffered mode? Or do you think we need to be able to
> dynamically switch between buffered and unbuffered modes? If the
> latter, why? Or maybe we can get away with simply using buffered mode
> all the time, and having people sync when needed?
>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> I did this at one point during development, but it seemed unnecessary
> given that you can delete the file before opening it. Would you want
> to go back to having FILE_APPEND or FILE_REPLACE instead of
> FILE_WRITE? Or distinguish the two some other way?
>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
By buffered, I mean with O_SYNC off, when writes are buffered in the
memory of the microcontroller before being written to the SD card.
The flush() command will force a sync.
2011/2/23 Tom Igoe <>:
> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>
> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>
> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>
> t.
>
> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>
>> 2011/2/22 Tom Igoe <>:
>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> What do you mean by turning it off and on? Â Is acceptable to have a
>> way to open the file in buffered or unbuffered mode, with an explicit
>> sync option for buffered mode? Â Or do you think we need to be able to
>> dynamically switch between buffered and unbuffered modes? Â If the
>> latter, why? Â Or maybe we can get away with simply using buffered mode
>> all the time, and having people sync when needed?
>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> I did this at one point during development, but it seemed unnecessary
>> given that you can delete the file before opening it. Â Would you want
>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>> FILE_WRITE? Â Or distinguish the two some other way?
>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe <>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis" <>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe <>
>>>>> Cc: Arduino Developers <>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. Â This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Oh, perfect, then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. OK if i just make that change to the repo?
t.
On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
> By buffered, I mean with O_SYNC off, when writes are buffered in the
> memory of the microcontroller before being written to the SD card.
> The flush() command will force a sync.
>
> 2011/2/23 Tom Igoe <>:
>> Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>
>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>
>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>
>> t.
>>
>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>
>>> 2011/2/22 Tom Igoe <>:
>>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> What do you mean by turning it off and on? Is acceptable to have a
>>> way to open the file in buffered or unbuffered mode, with an explicit
>>> sync option for buffered mode? Or do you think we need to be able to
>>> dynamically switch between buffered and unbuffered modes? If the
>>> latter, why? Or maybe we can get away with simply using buffered mode
>>> all the time, and having people sync when needed?
>>>
>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> I did this at one point during development, but it seemed unnecessary
>>> given that you can delete the file before opening it. Would you want
>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>> FILE_WRITE? Or distinguish the two some other way?
>>>
>>>> t.
>>>>
>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>
>>>>> done!
>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>
>>>>> m
>>>>>
>>>>>
>>>>>
>>>>> 2011/2/11 Tom Igoe <>
>>>>> A possible solution to the slow response from the SD library:
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> From: "David A. Mellis" <>
>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>> To: Tom Igoe <>
>>>>>> Cc: Arduino Developers <>
>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>
>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>> which means all changes are immediately physically written to the SD
>>>>>> card. This slows things done, but is more robust, because there
>>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>
>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>>
>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>>
>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>
>>>>>>> t.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Developers mailing list
>>>>>>>
>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
# 15

23-02-2011 02:50 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
2011/2/22 Tom Igoe <>:
> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
What do you mean by turning it off and on? Is acceptable to have a
way to open the file in buffered or unbuffered mode, with an explicit
sync option for buffered mode? Or do you think we need to be able to
dynamically switch between buffered and unbuffered modes? If the
latter, why? Or maybe we can get away with simply using buffered mode
all the time, and having people sync when needed?
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
I did this at one point during development, but it seemed unnecessary
given that you can delete the file before opening it. Would you want
to go back to having FILE_APPEND or FILE_REPLACE instead of
FILE_WRITE? Or distinguish the two some other way?
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
>> >> Developers mailing list
>> >>
>> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>> >>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
That could be very useful. What do you have in mind for the API?
2011/2/22 Limor <>:
> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
> Â i have some code on github but its very much in progress
>
>
> On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
>
>> Â Â Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. Â But working on both, we ran across two important needs:
>>
>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. Â This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
t.
On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
> 2011/2/22 Tom Igoe <>:
>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> What do you mean by turning it off and on? Is acceptable to have a
> way to open the file in buffered or unbuffered mode, with an explicit
> sync option for buffered mode? Or do you think we need to be able to
> dynamically switch between buffered and unbuffered modes? If the
> latter, why? Or maybe we can get away with simply using buffered mode
> all the time, and having people sync when needed?
>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> I did this at one point during development, but it seemed unnecessary
> given that you can delete the file before opening it. Would you want
> to go back to having FILE_APPEND or FILE_REPLACE instead of
> FILE_WRITE? Or distinguish the two some other way?
>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
By buffered, I mean with O_SYNC off, when writes are buffered in the
memory of the microcontroller before being written to the SD card.
The flush() command will force a sync.
2011/2/23 Tom Igoe <>:
> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>
> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>
> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>
> t.
>
> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>
>> 2011/2/22 Tom Igoe <>:
>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> What do you mean by turning it off and on? Â Is acceptable to have a
>> way to open the file in buffered or unbuffered mode, with an explicit
>> sync option for buffered mode? Â Or do you think we need to be able to
>> dynamically switch between buffered and unbuffered modes? Â If the
>> latter, why? Â Or maybe we can get away with simply using buffered mode
>> all the time, and having people sync when needed?
>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> I did this at one point during development, but it seemed unnecessary
>> given that you can delete the file before opening it. Â Would you want
>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>> FILE_WRITE? Â Or distinguish the two some other way?
>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe <>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis" <>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe <>
>>>>> Cc: Arduino Developers <>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. Â This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Oh, perfect, then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. OK if i just make that change to the repo?
t.
On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
> By buffered, I mean with O_SYNC off, when writes are buffered in the
> memory of the microcontroller before being written to the SD card.
> The flush() command will force a sync.
>
> 2011/2/23 Tom Igoe <>:
>> Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>
>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>
>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>
>> t.
>>
>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>
>>> 2011/2/22 Tom Igoe <>:
>>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> What do you mean by turning it off and on? Is acceptable to have a
>>> way to open the file in buffered or unbuffered mode, with an explicit
>>> sync option for buffered mode? Or do you think we need to be able to
>>> dynamically switch between buffered and unbuffered modes? If the
>>> latter, why? Or maybe we can get away with simply using buffered mode
>>> all the time, and having people sync when needed?
>>>
>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> I did this at one point during development, but it seemed unnecessary
>>> given that you can delete the file before opening it. Would you want
>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>> FILE_WRITE? Or distinguish the two some other way?
>>>
>>>> t.
>>>>
>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>
>>>>> done!
>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>
>>>>> m
>>>>>
>>>>>
>>>>>
>>>>> 2011/2/11 Tom Igoe <>
>>>>> A possible solution to the slow response from the SD library:
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> From: "David A. Mellis" <>
>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>> To: Tom Igoe <>
>>>>>> Cc: Arduino Developers <>
>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>
>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>> which means all changes are immediately physically written to the SD
>>>>>> card. This slows things done, but is more robust, because there
>>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>
>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>>
>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>>
>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>
>>>>>>> t.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Developers mailing list
>>>>>>>
>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
I'll do it.
I think I may just change the default from O_SYNC (non buffered) mode
to non-O_SYNC (buffered) mode. It's not as though we had any
complaints about the buffered mode, it just seemed like a good idea
when the performance implications weren't clear. If your board
randomly crashes or loses power, you'll have problems either way. And
there's still explicit syncing with flush(). I'm not convinced that
the distinction between buffered and unbuffered mode is important
enough in practice to expose in the API.
David
2011/2/23 Tom Igoe <>:
> Oh, perfect, Â then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. Â OK if i just make that change to the repo?
>
> t.
>
> On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
>
>> By buffered, I mean with O_SYNC off, when writes are buffered in the
>> memory of the microcontroller before being written to the SD card.
>> The flush() command will force a sync.
>>
>> 2011/2/23 Tom Igoe <>:
>>> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>>
>>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>>
>>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>>
>>> t.
>>>
>>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>>
>>>> 2011/2/22 Tom Igoe <>:
>>>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>>
>>>> What do you mean by turning it off and on? Â Is acceptable to have a
>>>> way to open the file in buffered or unbuffered mode, with an explicit
>>>> sync option for buffered mode? Â Or do you think we need to be able to
>>>> dynamically switch between buffered and unbuffered modes? Â If the
>>>> latter, why? Â Or maybe we can get away with simply using buffered mode
>>>> all the time, and having people sync when needed?
>>>>
>>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>>
>>>> I did this at one point during development, but it seemed unnecessary
>>>> given that you can delete the file before opening it. Â Would you want
>>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>>> FILE_WRITE? Â Or distinguish the two some other way?
>>>>
>>>>> t.
>>>>>
>>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>>
>>>>>> done!
>>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>>
>>>>>> m
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2011/2/11 Tom Igoe <>
>>>>>> A possible solution to the slow response from the SD library:
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>>> From: "David A. Mellis" <>
>>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>>> To: Tom Igoe <>
>>>>>>> Cc: Arduino Developers <>
>>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>>
>>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>>> which means all changes are immediately physically written to the SD
>>>>>>> card. Â This slows things done, but is more robust, because there
>>>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>>
>>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>>>
>>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>>>
>>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>>
>>>>>>>> t.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Developers mailing list
>>>>>>>>
>>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
# 16

23-02-2011 03:49 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
2011/2/22 Tom Igoe <>:
> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
What do you mean by turning it off and on? Is acceptable to have a
way to open the file in buffered or unbuffered mode, with an explicit
sync option for buffered mode? Or do you think we need to be able to
dynamically switch between buffered and unbuffered modes? If the
latter, why? Or maybe we can get away with simply using buffered mode
all the time, and having people sync when needed?
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
I did this at one point during development, but it seemed unnecessary
given that you can delete the file before opening it. Would you want
to go back to having FILE_APPEND or FILE_REPLACE instead of
FILE_WRITE? Or distinguish the two some other way?
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
>> >> Developers mailing list
>> >>
>> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>> >>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
That could be very useful. What do you have in mind for the API?
2011/2/22 Limor <>:
> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
> Â i have some code on github but its very much in progress
>
>
> On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
>
>> Â Â Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. Â But working on both, we ran across two important needs:
>>
>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. Â This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
t.
On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
> 2011/2/22 Tom Igoe <>:
>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> What do you mean by turning it off and on? Is acceptable to have a
> way to open the file in buffered or unbuffered mode, with an explicit
> sync option for buffered mode? Or do you think we need to be able to
> dynamically switch between buffered and unbuffered modes? If the
> latter, why? Or maybe we can get away with simply using buffered mode
> all the time, and having people sync when needed?
>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> I did this at one point during development, but it seemed unnecessary
> given that you can delete the file before opening it. Would you want
> to go back to having FILE_APPEND or FILE_REPLACE instead of
> FILE_WRITE? Or distinguish the two some other way?
>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
By buffered, I mean with O_SYNC off, when writes are buffered in the
memory of the microcontroller before being written to the SD card.
The flush() command will force a sync.
2011/2/23 Tom Igoe <>:
> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>
> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>
> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>
> t.
>
> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>
>> 2011/2/22 Tom Igoe <>:
>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> What do you mean by turning it off and on? Â Is acceptable to have a
>> way to open the file in buffered or unbuffered mode, with an explicit
>> sync option for buffered mode? Â Or do you think we need to be able to
>> dynamically switch between buffered and unbuffered modes? Â If the
>> latter, why? Â Or maybe we can get away with simply using buffered mode
>> all the time, and having people sync when needed?
>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> I did this at one point during development, but it seemed unnecessary
>> given that you can delete the file before opening it. Â Would you want
>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>> FILE_WRITE? Â Or distinguish the two some other way?
>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe <>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis" <>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe <>
>>>>> Cc: Arduino Developers <>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. Â This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Oh, perfect, then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. OK if i just make that change to the repo?
t.
On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
> By buffered, I mean with O_SYNC off, when writes are buffered in the
> memory of the microcontroller before being written to the SD card.
> The flush() command will force a sync.
>
> 2011/2/23 Tom Igoe <>:
>> Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>
>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>
>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>
>> t.
>>
>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>
>>> 2011/2/22 Tom Igoe <>:
>>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> What do you mean by turning it off and on? Is acceptable to have a
>>> way to open the file in buffered or unbuffered mode, with an explicit
>>> sync option for buffered mode? Or do you think we need to be able to
>>> dynamically switch between buffered and unbuffered modes? If the
>>> latter, why? Or maybe we can get away with simply using buffered mode
>>> all the time, and having people sync when needed?
>>>
>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> I did this at one point during development, but it seemed unnecessary
>>> given that you can delete the file before opening it. Would you want
>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>> FILE_WRITE? Or distinguish the two some other way?
>>>
>>>> t.
>>>>
>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>
>>>>> done!
>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>
>>>>> m
>>>>>
>>>>>
>>>>>
>>>>> 2011/2/11 Tom Igoe <>
>>>>> A possible solution to the slow response from the SD library:
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> From: "David A. Mellis" <>
>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>> To: Tom Igoe <>
>>>>>> Cc: Arduino Developers <>
>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>
>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>> which means all changes are immediately physically written to the SD
>>>>>> card. This slows things done, but is more robust, because there
>>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>
>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>>
>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>>
>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>
>>>>>>> t.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Developers mailing list
>>>>>>>
>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
I'll do it.
I think I may just change the default from O_SYNC (non buffered) mode
to non-O_SYNC (buffered) mode. It's not as though we had any
complaints about the buffered mode, it just seemed like a good idea
when the performance implications weren't clear. If your board
randomly crashes or loses power, you'll have problems either way. And
there's still explicit syncing with flush(). I'm not convinced that
the distinction between buffered and unbuffered mode is important
enough in practice to expose in the API.
David
2011/2/23 Tom Igoe <>:
> Oh, perfect, Â then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. Â OK if i just make that change to the repo?
>
> t.
>
> On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
>
>> By buffered, I mean with O_SYNC off, when writes are buffered in the
>> memory of the microcontroller before being written to the SD card.
>> The flush() command will force a sync.
>>
>> 2011/2/23 Tom Igoe <>:
>>> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>>
>>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>>
>>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>>
>>> t.
>>>
>>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>>
>>>> 2011/2/22 Tom Igoe <>:
>>>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>>
>>>> What do you mean by turning it off and on? Â Is acceptable to have a
>>>> way to open the file in buffered or unbuffered mode, with an explicit
>>>> sync option for buffered mode? Â Or do you think we need to be able to
>>>> dynamically switch between buffered and unbuffered modes? Â If the
>>>> latter, why? Â Or maybe we can get away with simply using buffered mode
>>>> all the time, and having people sync when needed?
>>>>
>>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>>
>>>> I did this at one point during development, but it seemed unnecessary
>>>> given that you can delete the file before opening it. Â Would you want
>>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>>> FILE_WRITE? Â Or distinguish the two some other way?
>>>>
>>>>> t.
>>>>>
>>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>>
>>>>>> done!
>>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>>
>>>>>> m
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2011/2/11 Tom Igoe <>
>>>>>> A possible solution to the slow response from the SD library:
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>>> From: "David A. Mellis" <>
>>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>>> To: Tom Igoe <>
>>>>>>> Cc: Arduino Developers <>
>>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>>
>>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>>> which means all changes are immediately physically written to the SD
>>>>>>> card. Â This slows things done, but is more robust, because there
>>>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>>
>>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>>>
>>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>>>
>>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>>
>>>>>>>> t.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Developers mailing list
>>>>>>>>
>>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
oh boy well its like totally totally a mess right now because i started
on it and then needed to take a break but this is my 'ls'
somewhere in this i realized we needed to be able to have multiple File
objects, not one. thats when it got complex (to rework the code while
maintaining backwards compatibility) :/
https://github.com/adafruit/SD
also a lot of people on mac's end up formatting their cards wrong so i
exposed the low level card detail procedures - these have been handy for
us since the cards are good but they need to be formatted with a
different partition name, etc.etc.
limor
---
File myFile;
void setup()
{
Serial.begin(9600);
Serial.print("\nInitializing SD card...");
// On the Ethernet Shield, CS is pin 4. It's set as an output by default.
// Note that even if it's not used as the CS pin, the hardware SS pin
// (10 on most Arduino boards, 53 on the Mega) must be left as an output
// or the SD library functions will not work.
pinMode(10, OUTPUT);
// we'll use the low level initialization code since we're just
testing if the card is working!
// change the second pin to whatever CS is connected to
if (!SD.card.init(SPI_HALF_SPEED, 4)) {
Serial.println("initialization failed!\nCheck your wiring and that
a card is inserted");
return;
}
// print the type of card
Serial.print("\nCard type: ");
switch(SD.card.type()) {
case SD_CARD_TYPE_SD1:
Serial.println("SD1");
break;
case SD_CARD_TYPE_SD2:
Serial.println("SD2");
break;
case SD_CARD_TYPE_SDHC:
Serial.println("SDHC");
break;
default:
Serial.println("Unknown");
}
// Now we will try to open the 'volume'/'partition' - it should be
FAT16 or FAT32
if (!SD.volume.init(SD.card)) {
Serial.println("Could not find FAT16/FAT32 partition.\nMake sure
you've formatted the card");
return;
}
// print the type and size of the first FAT-type volume
uint32_t volumesize;
Serial.print("\nVolume type is FAT");
Serial.println(SD.volume.fatType(), DEC);
volumesize = SD.volume.blocksPerCluster(); // clusters are
collections of blocks
volumesize *= SD.volume.clusterCount(); // we'll have a lot of
clusters
volumesize *= 512; // SD card blocks are
always 512 bytes
Serial.print("Volume size (bytes): ");
Serial.println(volumesize);
Serial.print("Volume size (Kbytes): ");
volumesize /= 1024;
Serial.println(volumesize);
Serial.print("Volume size (Mbytes): ");
volumesize /= 1024;
Serial.println(volumesize);
SD.root.openRoot(SD.volume);
// add directory listing next
myFile = SD.open("/");
if (myFile) {
Serial.print("opened ");
} else {
Serial.print("failed to open ");
}
Serial.println(myFile.name());
// list all files in directory
printDirectory(myFile, 0);
}
void printDirectory(File dir, int numTabs) {
while(true) {
for (uint8_t i=0; i
Serial.print('\t');
DirectoryEntry entry = myFile.readNextDirectoryEntry();
if (! entry) {
// no more files
break;
}
Serial.print(entry.name());
if (entry.isDirectory()) {
Serial.println("/");
File subdir;
myFile = SD.open("/");
//printDirectory(
} else {
// files have sizes, directories do not
Serial.print("\t\t");
Serial.println(entry.size(), DEC);
}
}
}
On 2/22/2011 11:27 PM, David A. Mellis wrote:
> That could be very useful. What do you have in mind for the API?
>
> 2011/2/22 Limor<>:
>> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
>> i have some code on github but its very much in progress
>>
>>
>> On Feb 22, 2011, at 9:07 PM, Tom Igoe<> wrote:
>>
>>> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>>>
>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe<>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis"<>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe<>
>>>>> Cc: Arduino Developers<>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
# 17

23-02-2011 06:15 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
2011/2/22 Tom Igoe <>:
> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
What do you mean by turning it off and on? Is acceptable to have a
way to open the file in buffered or unbuffered mode, with an explicit
sync option for buffered mode? Or do you think we need to be able to
dynamically switch between buffered and unbuffered modes? If the
latter, why? Or maybe we can get away with simply using buffered mode
all the time, and having people sync when needed?
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
I did this at one point during development, but it seemed unnecessary
given that you can delete the file before opening it. Would you want
to go back to having FILE_APPEND or FILE_REPLACE instead of
FILE_WRITE? Or distinguish the two some other way?
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
>> >> Developers mailing list
>> >>
>> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>> >>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
That could be very useful. What do you have in mind for the API?
2011/2/22 Limor <>:
> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
> Â i have some code on github but its very much in progress
>
>
> On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
>
>> Â Â Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. Â But working on both, we ran across two important needs:
>>
>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. Â This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
t.
On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
> 2011/2/22 Tom Igoe <>:
>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> What do you mean by turning it off and on? Is acceptable to have a
> way to open the file in buffered or unbuffered mode, with an explicit
> sync option for buffered mode? Or do you think we need to be able to
> dynamically switch between buffered and unbuffered modes? If the
> latter, why? Or maybe we can get away with simply using buffered mode
> all the time, and having people sync when needed?
>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> I did this at one point during development, but it seemed unnecessary
> given that you can delete the file before opening it. Would you want
> to go back to having FILE_APPEND or FILE_REPLACE instead of
> FILE_WRITE? Or distinguish the two some other way?
>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
By buffered, I mean with O_SYNC off, when writes are buffered in the
memory of the microcontroller before being written to the SD card.
The flush() command will force a sync.
2011/2/23 Tom Igoe <>:
> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>
> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>
> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>
> t.
>
> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>
>> 2011/2/22 Tom Igoe <>:
>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> What do you mean by turning it off and on? Â Is acceptable to have a
>> way to open the file in buffered or unbuffered mode, with an explicit
>> sync option for buffered mode? Â Or do you think we need to be able to
>> dynamically switch between buffered and unbuffered modes? Â If the
>> latter, why? Â Or maybe we can get away with simply using buffered mode
>> all the time, and having people sync when needed?
>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> I did this at one point during development, but it seemed unnecessary
>> given that you can delete the file before opening it. Â Would you want
>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>> FILE_WRITE? Â Or distinguish the two some other way?
>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe <>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis" <>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe <>
>>>>> Cc: Arduino Developers <>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. Â This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Oh, perfect, then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. OK if i just make that change to the repo?
t.
On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
> By buffered, I mean with O_SYNC off, when writes are buffered in the
> memory of the microcontroller before being written to the SD card.
> The flush() command will force a sync.
>
> 2011/2/23 Tom Igoe <>:
>> Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>
>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>
>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>
>> t.
>>
>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>
>>> 2011/2/22 Tom Igoe <>:
>>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> What do you mean by turning it off and on? Is acceptable to have a
>>> way to open the file in buffered or unbuffered mode, with an explicit
>>> sync option for buffered mode? Or do you think we need to be able to
>>> dynamically switch between buffered and unbuffered modes? If the
>>> latter, why? Or maybe we can get away with simply using buffered mode
>>> all the time, and having people sync when needed?
>>>
>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> I did this at one point during development, but it seemed unnecessary
>>> given that you can delete the file before opening it. Would you want
>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>> FILE_WRITE? Or distinguish the two some other way?
>>>
>>>> t.
>>>>
>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>
>>>>> done!
>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>
>>>>> m
>>>>>
>>>>>
>>>>>
>>>>> 2011/2/11 Tom Igoe <>
>>>>> A possible solution to the slow response from the SD library:
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> From: "David A. Mellis" <>
>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>> To: Tom Igoe <>
>>>>>> Cc: Arduino Developers <>
>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>
>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>> which means all changes are immediately physically written to the SD
>>>>>> card. This slows things done, but is more robust, because there
>>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>
>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>>
>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>>
>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>
>>>>>>> t.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Developers mailing list
>>>>>>>
>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
I'll do it.
I think I may just change the default from O_SYNC (non buffered) mode
to non-O_SYNC (buffered) mode. It's not as though we had any
complaints about the buffered mode, it just seemed like a good idea
when the performance implications weren't clear. If your board
randomly crashes or loses power, you'll have problems either way. And
there's still explicit syncing with flush(). I'm not convinced that
the distinction between buffered and unbuffered mode is important
enough in practice to expose in the API.
David
2011/2/23 Tom Igoe <>:
> Oh, perfect, Â then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. Â OK if i just make that change to the repo?
>
> t.
>
> On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
>
>> By buffered, I mean with O_SYNC off, when writes are buffered in the
>> memory of the microcontroller before being written to the SD card.
>> The flush() command will force a sync.
>>
>> 2011/2/23 Tom Igoe <>:
>>> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>>
>>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>>
>>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>>
>>> t.
>>>
>>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>>
>>>> 2011/2/22 Tom Igoe <>:
>>>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>>
>>>> What do you mean by turning it off and on? Â Is acceptable to have a
>>>> way to open the file in buffered or unbuffered mode, with an explicit
>>>> sync option for buffered mode? Â Or do you think we need to be able to
>>>> dynamically switch between buffered and unbuffered modes? Â If the
>>>> latter, why? Â Or maybe we can get away with simply using buffered mode
>>>> all the time, and having people sync when needed?
>>>>
>>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>>
>>>> I did this at one point during development, but it seemed unnecessary
>>>> given that you can delete the file before opening it. Â Would you want
>>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>>> FILE_WRITE? Â Or distinguish the two some other way?
>>>>
>>>>> t.
>>>>>
>>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>>
>>>>>> done!
>>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>>
>>>>>> m
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2011/2/11 Tom Igoe <>
>>>>>> A possible solution to the slow response from the SD library:
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>>> From: "David A. Mellis" <>
>>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>>> To: Tom Igoe <>
>>>>>>> Cc: Arduino Developers <>
>>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>>
>>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>>> which means all changes are immediately physically written to the SD
>>>>>>> card. Â This slows things done, but is more robust, because there
>>>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>>
>>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>>>
>>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>>>
>>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>>
>>>>>>>> t.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Developers mailing list
>>>>>>>>
>>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
oh boy well its like totally totally a mess right now because i started
on it and then needed to take a break but this is my 'ls'
somewhere in this i realized we needed to be able to have multiple File
objects, not one. thats when it got complex (to rework the code while
maintaining backwards compatibility) :/
https://github.com/adafruit/SD
also a lot of people on mac's end up formatting their cards wrong so i
exposed the low level card detail procedures - these have been handy for
us since the cards are good but they need to be formatted with a
different partition name, etc.etc.
limor
---
File myFile;
void setup()
{
Serial.begin(9600);
Serial.print("\nInitializing SD card...");
// On the Ethernet Shield, CS is pin 4. It's set as an output by default.
// Note that even if it's not used as the CS pin, the hardware SS pin
// (10 on most Arduino boards, 53 on the Mega) must be left as an output
// or the SD library functions will not work.
pinMode(10, OUTPUT);
// we'll use the low level initialization code since we're just
testing if the card is working!
// change the second pin to whatever CS is connected to
if (!SD.card.init(SPI_HALF_SPEED, 4)) {
Serial.println("initialization failed!\nCheck your wiring and that
a card is inserted");
return;
}
// print the type of card
Serial.print("\nCard type: ");
switch(SD.card.type()) {
case SD_CARD_TYPE_SD1:
Serial.println("SD1");
break;
case SD_CARD_TYPE_SD2:
Serial.println("SD2");
break;
case SD_CARD_TYPE_SDHC:
Serial.println("SDHC");
break;
default:
Serial.println("Unknown");
}
// Now we will try to open the 'volume'/'partition' - it should be
FAT16 or FAT32
if (!SD.volume.init(SD.card)) {
Serial.println("Could not find FAT16/FAT32 partition.\nMake sure
you've formatted the card");
return;
}
// print the type and size of the first FAT-type volume
uint32_t volumesize;
Serial.print("\nVolume type is FAT");
Serial.println(SD.volume.fatType(), DEC);
volumesize = SD.volume.blocksPerCluster(); // clusters are
collections of blocks
volumesize *= SD.volume.clusterCount(); // we'll have a lot of
clusters
volumesize *= 512; // SD card blocks are
always 512 bytes
Serial.print("Volume size (bytes): ");
Serial.println(volumesize);
Serial.print("Volume size (Kbytes): ");
volumesize /= 1024;
Serial.println(volumesize);
Serial.print("Volume size (Mbytes): ");
volumesize /= 1024;
Serial.println(volumesize);
SD.root.openRoot(SD.volume);
// add directory listing next
myFile = SD.open("/");
if (myFile) {
Serial.print("opened ");
} else {
Serial.print("failed to open ");
}
Serial.println(myFile.name());
// list all files in directory
printDirectory(myFile, 0);
}
void printDirectory(File dir, int numTabs) {
while(true) {
for (uint8_t i=0; i
Serial.print('\t');
DirectoryEntry entry = myFile.readNextDirectoryEntry();
if (! entry) {
// no more files
break;
}
Serial.print(entry.name());
if (entry.isDirectory()) {
Serial.println("/");
File subdir;
myFile = SD.open("/");
//printDirectory(
} else {
// files have sizes, directories do not
Serial.print("\t\t");
Serial.println(entry.size(), DEC);
}
}
}
On 2/22/2011 11:27 PM, David A. Mellis wrote:
> That could be very useful. What do you have in mind for the API?
>
> 2011/2/22 Limor<>:
>> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
>> i have some code on github but its very much in progress
>>
>>
>> On Feb 22, 2011, at 9:07 PM, Tom Igoe<> wrote:
>>
>>> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>>>
>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe<>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis"<>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe<>
>>>>> Cc: Arduino Developers<>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Works for me.
t.
On Feb 23, 2011, at 9:50 AM, David A. Mellis wrote:
> I'll do it.
>
> I think I may just change the default from O_SYNC (non buffered) mode
> to non-O_SYNC (buffered) mode. It's not as though we had any
> complaints about the buffered mode, it just seemed like a good idea
> when the performance implications weren't clear. If your board
> randomly crashes or loses power, you'll have problems either way. And
> there's still explicit syncing with flush(). I'm not convinced that
> the distinction between buffered and unbuffered mode is important
> enough in practice to expose in the API.
>
> David
>
> 2011/2/23 Tom Igoe <>:
>> Oh, perfect, then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. OK if i just make that change to the repo?
>>
>> t.
>>
>> On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
>>
>>> By buffered, I mean with O_SYNC off, when writes are buffered in the
>>> memory of the microcontroller before being written to the SD card.
>>> The flush() command will force a sync.
>>>
>>> 2011/2/23 Tom Igoe <>:
>>>> Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>>>
>>>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>>>
>>>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>>>
>>>> t.
>>>>
>>>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>>>
>>>>> 2011/2/22 Tom Igoe <>:
>>>>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>>>
>>>>> What do you mean by turning it off and on? Is acceptable to have a
>>>>> way to open the file in buffered or unbuffered mode, with an explicit
>>>>> sync option for buffered mode? Or do you think we need to be able to
>>>>> dynamically switch between buffered and unbuffered modes? If the
>>>>> latter, why? Or maybe we can get away with simply using buffered mode
>>>>> all the time, and having people sync when needed?
>>>>>
>>>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>>>
>>>>> I did this at one point during development, but it seemed unnecessary
>>>>> given that you can delete the file before opening it. Would you want
>>>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>>>> FILE_WRITE? Or distinguish the two some other way?
>>>>>
>>>>>> t.
>>>>>>
>>>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>>>
>>>>>>> done!
>>>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>>>
>>>>>>> m
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2011/2/11 Tom Igoe <>
>>>>>>> A possible solution to the slow response from the SD library:
>>>>>>>
>>>>>>> t.
>>>>>>>
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: "David A. Mellis" <>
>>>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>>>> To: Tom Igoe <>
>>>>>>>> Cc: Arduino Developers <>
>>>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>>>
>>>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>>>> which means all changes are immediately physically written to the SD
>>>>>>>> card. This slows things done, but is more robust, because there
>>>>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>>>
>>>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>>>>
>>>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>>>>
>>>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>>>
>>>>>>>>> t.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Developers mailing list
>>>>>>>>>
>>>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>>
>>
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
# 18

23-02-2011 07:49 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
2011/2/22 Tom Igoe <>:
> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
What do you mean by turning it off and on? Is acceptable to have a
way to open the file in buffered or unbuffered mode, with an explicit
sync option for buffered mode? Or do you think we need to be able to
dynamically switch between buffered and unbuffered modes? If the
latter, why? Or maybe we can get away with simply using buffered mode
all the time, and having people sync when needed?
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
I did this at one point during development, but it seemed unnecessary
given that you can delete the file before opening it. Would you want
to go back to having FILE_APPEND or FILE_REPLACE instead of
FILE_WRITE? Or distinguish the two some other way?
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
>> >> Developers mailing list
>> >>
>> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>> >>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
That could be very useful. What do you have in mind for the API?
2011/2/22 Limor <>:
> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
> Â i have some code on github but its very much in progress
>
>
> On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
>
>> Â Â Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. Â But working on both, we ran across two important needs:
>>
>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. Â This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
t.
On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
> 2011/2/22 Tom Igoe <>:
>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> What do you mean by turning it off and on? Is acceptable to have a
> way to open the file in buffered or unbuffered mode, with an explicit
> sync option for buffered mode? Or do you think we need to be able to
> dynamically switch between buffered and unbuffered modes? If the
> latter, why? Or maybe we can get away with simply using buffered mode
> all the time, and having people sync when needed?
>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> I did this at one point during development, but it seemed unnecessary
> given that you can delete the file before opening it. Would you want
> to go back to having FILE_APPEND or FILE_REPLACE instead of
> FILE_WRITE? Or distinguish the two some other way?
>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
By buffered, I mean with O_SYNC off, when writes are buffered in the
memory of the microcontroller before being written to the SD card.
The flush() command will force a sync.
2011/2/23 Tom Igoe <>:
> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>
> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>
> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>
> t.
>
> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>
>> 2011/2/22 Tom Igoe <>:
>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> What do you mean by turning it off and on? Â Is acceptable to have a
>> way to open the file in buffered or unbuffered mode, with an explicit
>> sync option for buffered mode? Â Or do you think we need to be able to
>> dynamically switch between buffered and unbuffered modes? Â If the
>> latter, why? Â Or maybe we can get away with simply using buffered mode
>> all the time, and having people sync when needed?
>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> I did this at one point during development, but it seemed unnecessary
>> given that you can delete the file before opening it. Â Would you want
>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>> FILE_WRITE? Â Or distinguish the two some other way?
>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe <>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis" <>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe <>
>>>>> Cc: Arduino Developers <>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. Â This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Oh, perfect, then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. OK if i just make that change to the repo?
t.
On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
> By buffered, I mean with O_SYNC off, when writes are buffered in the
> memory of the microcontroller before being written to the SD card.
> The flush() command will force a sync.
>
> 2011/2/23 Tom Igoe <>:
>> Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>
>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>
>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>
>> t.
>>
>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>
>>> 2011/2/22 Tom Igoe <>:
>>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> What do you mean by turning it off and on? Is acceptable to have a
>>> way to open the file in buffered or unbuffered mode, with an explicit
>>> sync option for buffered mode? Or do you think we need to be able to
>>> dynamically switch between buffered and unbuffered modes? If the
>>> latter, why? Or maybe we can get away with simply using buffered mode
>>> all the time, and having people sync when needed?
>>>
>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> I did this at one point during development, but it seemed unnecessary
>>> given that you can delete the file before opening it. Would you want
>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>> FILE_WRITE? Or distinguish the two some other way?
>>>
>>>> t.
>>>>
>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>
>>>>> done!
>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>
>>>>> m
>>>>>
>>>>>
>>>>>
>>>>> 2011/2/11 Tom Igoe <>
>>>>> A possible solution to the slow response from the SD library:
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> From: "David A. Mellis" <>
>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>> To: Tom Igoe <>
>>>>>> Cc: Arduino Developers <>
>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>
>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>> which means all changes are immediately physically written to the SD
>>>>>> card. This slows things done, but is more robust, because there
>>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>
>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>>
>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>>
>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>
>>>>>>> t.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Developers mailing list
>>>>>>>
>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
I'll do it.
I think I may just change the default from O_SYNC (non buffered) mode
to non-O_SYNC (buffered) mode. It's not as though we had any
complaints about the buffered mode, it just seemed like a good idea
when the performance implications weren't clear. If your board
randomly crashes or loses power, you'll have problems either way. And
there's still explicit syncing with flush(). I'm not convinced that
the distinction between buffered and unbuffered mode is important
enough in practice to expose in the API.
David
2011/2/23 Tom Igoe <>:
> Oh, perfect, Â then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. Â OK if i just make that change to the repo?
>
> t.
>
> On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
>
>> By buffered, I mean with O_SYNC off, when writes are buffered in the
>> memory of the microcontroller before being written to the SD card.
>> The flush() command will force a sync.
>>
>> 2011/2/23 Tom Igoe <>:
>>> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>>
>>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>>
>>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>>
>>> t.
>>>
>>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>>
>>>> 2011/2/22 Tom Igoe <>:
>>>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>>
>>>> What do you mean by turning it off and on? Â Is acceptable to have a
>>>> way to open the file in buffered or unbuffered mode, with an explicit
>>>> sync option for buffered mode? Â Or do you think we need to be able to
>>>> dynamically switch between buffered and unbuffered modes? Â If the
>>>> latter, why? Â Or maybe we can get away with simply using buffered mode
>>>> all the time, and having people sync when needed?
>>>>
>>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>>
>>>> I did this at one point during development, but it seemed unnecessary
>>>> given that you can delete the file before opening it. Â Would you want
>>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>>> FILE_WRITE? Â Or distinguish the two some other way?
>>>>
>>>>> t.
>>>>>
>>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>>
>>>>>> done!
>>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>>
>>>>>> m
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2011/2/11 Tom Igoe <>
>>>>>> A possible solution to the slow response from the SD library:
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>>> From: "David A. Mellis" <>
>>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>>> To: Tom Igoe <>
>>>>>>> Cc: Arduino Developers <>
>>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>>
>>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>>> which means all changes are immediately physically written to the SD
>>>>>>> card. Â This slows things done, but is more robust, because there
>>>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>>
>>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>>>
>>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>>>
>>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>>
>>>>>>>> t.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Developers mailing list
>>>>>>>>
>>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
oh boy well its like totally totally a mess right now because i started
on it and then needed to take a break but this is my 'ls'
somewhere in this i realized we needed to be able to have multiple File
objects, not one. thats when it got complex (to rework the code while
maintaining backwards compatibility) :/
https://github.com/adafruit/SD
also a lot of people on mac's end up formatting their cards wrong so i
exposed the low level card detail procedures - these have been handy for
us since the cards are good but they need to be formatted with a
different partition name, etc.etc.
limor
---
File myFile;
void setup()
{
Serial.begin(9600);
Serial.print("\nInitializing SD card...");
// On the Ethernet Shield, CS is pin 4. It's set as an output by default.
// Note that even if it's not used as the CS pin, the hardware SS pin
// (10 on most Arduino boards, 53 on the Mega) must be left as an output
// or the SD library functions will not work.
pinMode(10, OUTPUT);
// we'll use the low level initialization code since we're just
testing if the card is working!
// change the second pin to whatever CS is connected to
if (!SD.card.init(SPI_HALF_SPEED, 4)) {
Serial.println("initialization failed!\nCheck your wiring and that
a card is inserted");
return;
}
// print the type of card
Serial.print("\nCard type: ");
switch(SD.card.type()) {
case SD_CARD_TYPE_SD1:
Serial.println("SD1");
break;
case SD_CARD_TYPE_SD2:
Serial.println("SD2");
break;
case SD_CARD_TYPE_SDHC:
Serial.println("SDHC");
break;
default:
Serial.println("Unknown");
}
// Now we will try to open the 'volume'/'partition' - it should be
FAT16 or FAT32
if (!SD.volume.init(SD.card)) {
Serial.println("Could not find FAT16/FAT32 partition.\nMake sure
you've formatted the card");
return;
}
// print the type and size of the first FAT-type volume
uint32_t volumesize;
Serial.print("\nVolume type is FAT");
Serial.println(SD.volume.fatType(), DEC);
volumesize = SD.volume.blocksPerCluster(); // clusters are
collections of blocks
volumesize *= SD.volume.clusterCount(); // we'll have a lot of
clusters
volumesize *= 512; // SD card blocks are
always 512 bytes
Serial.print("Volume size (bytes): ");
Serial.println(volumesize);
Serial.print("Volume size (Kbytes): ");
volumesize /= 1024;
Serial.println(volumesize);
Serial.print("Volume size (Mbytes): ");
volumesize /= 1024;
Serial.println(volumesize);
SD.root.openRoot(SD.volume);
// add directory listing next
myFile = SD.open("/");
if (myFile) {
Serial.print("opened ");
} else {
Serial.print("failed to open ");
}
Serial.println(myFile.name());
// list all files in directory
printDirectory(myFile, 0);
}
void printDirectory(File dir, int numTabs) {
while(true) {
for (uint8_t i=0; i
Serial.print('\t');
DirectoryEntry entry = myFile.readNextDirectoryEntry();
if (! entry) {
// no more files
break;
}
Serial.print(entry.name());
if (entry.isDirectory()) {
Serial.println("/");
File subdir;
myFile = SD.open("/");
//printDirectory(
} else {
// files have sizes, directories do not
Serial.print("\t\t");
Serial.println(entry.size(), DEC);
}
}
}
On 2/22/2011 11:27 PM, David A. Mellis wrote:
> That could be very useful. What do you have in mind for the API?
>
> 2011/2/22 Limor<>:
>> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
>> i have some code on github but its very much in progress
>>
>>
>> On Feb 22, 2011, at 9:07 PM, Tom Igoe<> wrote:
>>
>>> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>>>
>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe<>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis"<>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe<>
>>>>> Cc: Arduino Developers<>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Works for me.
t.
On Feb 23, 2011, at 9:50 AM, David A. Mellis wrote:
> I'll do it.
>
> I think I may just change the default from O_SYNC (non buffered) mode
> to non-O_SYNC (buffered) mode. It's not as though we had any
> complaints about the buffered mode, it just seemed like a good idea
> when the performance implications weren't clear. If your board
> randomly crashes or loses power, you'll have problems either way. And
> there's still explicit syncing with flush(). I'm not convinced that
> the distinction between buffered and unbuffered mode is important
> enough in practice to expose in the API.
>
> David
>
> 2011/2/23 Tom Igoe <>:
>> Oh, perfect, then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. OK if i just make that change to the repo?
>>
>> t.
>>
>> On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
>>
>>> By buffered, I mean with O_SYNC off, when writes are buffered in the
>>> memory of the microcontroller before being written to the SD card.
>>> The flush() command will force a sync.
>>>
>>> 2011/2/23 Tom Igoe <>:
>>>> Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>>>
>>>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>>>
>>>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>>>
>>>> t.
>>>>
>>>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>>>
>>>>> 2011/2/22 Tom Igoe <>:
>>>>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>>>
>>>>> What do you mean by turning it off and on? Is acceptable to have a
>>>>> way to open the file in buffered or unbuffered mode, with an explicit
>>>>> sync option for buffered mode? Or do you think we need to be able to
>>>>> dynamically switch between buffered and unbuffered modes? If the
>>>>> latter, why? Or maybe we can get away with simply using buffered mode
>>>>> all the time, and having people sync when needed?
>>>>>
>>>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>>>
>>>>> I did this at one point during development, but it seemed unnecessary
>>>>> given that you can delete the file before opening it. Would you want
>>>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>>>> FILE_WRITE? Or distinguish the two some other way?
>>>>>
>>>>>> t.
>>>>>>
>>>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>>>
>>>>>>> done!
>>>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>>>
>>>>>>> m
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2011/2/11 Tom Igoe <>
>>>>>>> A possible solution to the slow response from the SD library:
>>>>>>>
>>>>>>> t.
>>>>>>>
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: "David A. Mellis" <>
>>>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>>>> To: Tom Igoe <>
>>>>>>>> Cc: Arduino Developers <>
>>>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>>>
>>>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>>>> which means all changes are immediately physically written to the SD
>>>>>>>> card. This slows things done, but is more robust, because there
>>>>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>>>
>>>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>>>>
>>>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>>>>
>>>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>>>
>>>>>>>>> t.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Developers mailing list
>>>>>>>>>
>>>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>>
>>
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
In data mercoledì 23 febbraio 2011 15:50:12, David A. Mellis ha scritto:
> there's still explicit syncing with flush(). I'm not convinced that
> the distinction between buffered and unbuffered mode is important
> enough in practice to expose in the API.
I agree to use unbuffered mode by default, from a beginner point of view is
better.
I disagree, instead, to completely remove flush() method from the streaming
API.
I have at least two good reasons:
1) in buffered mode, when you write something, the data is kept into the
buffer until one of these conditions is met:
- the buffer is full
- a timeout occurs
- the file is closed
- flush method is called
Since we don't implement a timeout mechanism (correct me if i'm wrong),
without the flush() method you have no way to force the writing of a buffer
partially filled (unless you close and reopen the file, but could be some
other kind of "streams" where you can't do that).
2) every unbuffered write is a consuming resource monster.
SD-cards require that an entire sector should be written at a time (512-
bytes). In non buffered mode this means that "printing" a string of 70 bytes
causes the writing of that sector 70 times, because the print class calls the
write() method repeteadly for every byte of the string. Is this a problem?
yes, because the lifetime of the flash memory is decimated (you write the
sector 70 times instead of one).
another example? The ethernet library.
If you send a string, using Print methods, a packet is sent for every byte of
the string. Is this a problem? it depends:
- if you are on your LAN maybe not (if you are not concerned of the fact that
streaming the analog-in consume 100KB/sec)
- if you are using an external webservice, you are wasting about 15 times the
bandwidth normally needed. And this, yes, is a problem.
my 0.02
C
|
# 19

23-02-2011 09:52 PM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
2011/2/22 Tom Igoe <>:
> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
What do you mean by turning it off and on? Is acceptable to have a
way to open the file in buffered or unbuffered mode, with an explicit
sync option for buffered mode? Or do you think we need to be able to
dynamically switch between buffered and unbuffered modes? If the
latter, why? Or maybe we can get away with simply using buffered mode
all the time, and having people sync when needed?
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
I did this at one point during development, but it seemed unnecessary
given that you can delete the file before opening it. Would you want
to go back to having FILE_APPEND or FILE_REPLACE instead of
FILE_WRITE? Or distinguish the two some other way?
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
>> >> Developers mailing list
>> >>
>> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>> >>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
That could be very useful. What do you have in mind for the API?
2011/2/22 Limor <>:
> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
> Â i have some code on github but its very much in progress
>
>
> On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
>
>> Â Â Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. Â But working on both, we ran across two important needs:
>>
>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. Â This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
t.
On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
> 2011/2/22 Tom Igoe <>:
>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> What do you mean by turning it off and on? Is acceptable to have a
> way to open the file in buffered or unbuffered mode, with an explicit
> sync option for buffered mode? Or do you think we need to be able to
> dynamically switch between buffered and unbuffered modes? If the
> latter, why? Or maybe we can get away with simply using buffered mode
> all the time, and having people sync when needed?
>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> I did this at one point during development, but it seemed unnecessary
> given that you can delete the file before opening it. Would you want
> to go back to having FILE_APPEND or FILE_REPLACE instead of
> FILE_WRITE? Or distinguish the two some other way?
>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
By buffered, I mean with O_SYNC off, when writes are buffered in the
memory of the microcontroller before being written to the SD card.
The flush() command will force a sync.
2011/2/23 Tom Igoe <>:
> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>
> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>
> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>
> t.
>
> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>
>> 2011/2/22 Tom Igoe <>:
>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> What do you mean by turning it off and on? Â Is acceptable to have a
>> way to open the file in buffered or unbuffered mode, with an explicit
>> sync option for buffered mode? Â Or do you think we need to be able to
>> dynamically switch between buffered and unbuffered modes? Â If the
>> latter, why? Â Or maybe we can get away with simply using buffered mode
>> all the time, and having people sync when needed?
>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> I did this at one point during development, but it seemed unnecessary
>> given that you can delete the file before opening it. Â Would you want
>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>> FILE_WRITE? Â Or distinguish the two some other way?
>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe <>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis" <>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe <>
>>>>> Cc: Arduino Developers <>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. Â This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Oh, perfect, then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. OK if i just make that change to the repo?
t.
On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
> By buffered, I mean with O_SYNC off, when writes are buffered in the
> memory of the microcontroller before being written to the SD card.
> The flush() command will force a sync.
>
> 2011/2/23 Tom Igoe <>:
>> Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>
>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>
>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>
>> t.
>>
>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>
>>> 2011/2/22 Tom Igoe <>:
>>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> What do you mean by turning it off and on? Is acceptable to have a
>>> way to open the file in buffered or unbuffered mode, with an explicit
>>> sync option for buffered mode? Or do you think we need to be able to
>>> dynamically switch between buffered and unbuffered modes? If the
>>> latter, why? Or maybe we can get away with simply using buffered mode
>>> all the time, and having people sync when needed?
>>>
>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> I did this at one point during development, but it seemed unnecessary
>>> given that you can delete the file before opening it. Would you want
>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>> FILE_WRITE? Or distinguish the two some other way?
>>>
>>>> t.
>>>>
>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>
>>>>> done!
>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>
>>>>> m
>>>>>
>>>>>
>>>>>
>>>>> 2011/2/11 Tom Igoe <>
>>>>> A possible solution to the slow response from the SD library:
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> From: "David A. Mellis" <>
>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>> To: Tom Igoe <>
>>>>>> Cc: Arduino Developers <>
>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>
>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>> which means all changes are immediately physically written to the SD
>>>>>> card. This slows things done, but is more robust, because there
>>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>
>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>>
>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>>
>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>
>>>>>>> t.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Developers mailing list
>>>>>>>
>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
I'll do it.
I think I may just change the default from O_SYNC (non buffered) mode
to non-O_SYNC (buffered) mode. It's not as though we had any
complaints about the buffered mode, it just seemed like a good idea
when the performance implications weren't clear. If your board
randomly crashes or loses power, you'll have problems either way. And
there's still explicit syncing with flush(). I'm not convinced that
the distinction between buffered and unbuffered mode is important
enough in practice to expose in the API.
David
2011/2/23 Tom Igoe <>:
> Oh, perfect, Â then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. Â OK if i just make that change to the repo?
>
> t.
>
> On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
>
>> By buffered, I mean with O_SYNC off, when writes are buffered in the
>> memory of the microcontroller before being written to the SD card.
>> The flush() command will force a sync.
>>
>> 2011/2/23 Tom Igoe <>:
>>> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>>
>>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>>
>>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>>
>>> t.
>>>
>>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>>
>>>> 2011/2/22 Tom Igoe <>:
>>>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>>
>>>> What do you mean by turning it off and on? Â Is acceptable to have a
>>>> way to open the file in buffered or unbuffered mode, with an explicit
>>>> sync option for buffered mode? Â Or do you think we need to be able to
>>>> dynamically switch between buffered and unbuffered modes? Â If the
>>>> latter, why? Â Or maybe we can get away with simply using buffered mode
>>>> all the time, and having people sync when needed?
>>>>
>>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>>
>>>> I did this at one point during development, but it seemed unnecessary
>>>> given that you can delete the file before opening it. Â Would you want
>>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>>> FILE_WRITE? Â Or distinguish the two some other way?
>>>>
>>>>> t.
>>>>>
>>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>>
>>>>>> done!
>>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>>
>>>>>> m
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2011/2/11 Tom Igoe <>
>>>>>> A possible solution to the slow response from the SD library:
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>>> From: "David A. Mellis" <>
>>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>>> To: Tom Igoe <>
>>>>>>> Cc: Arduino Developers <>
>>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>>
>>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>>> which means all changes are immediately physically written to the SD
>>>>>>> card. Â This slows things done, but is more robust, because there
>>>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>>
>>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>>>
>>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>>>
>>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>>
>>>>>>>> t.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Developers mailing list
>>>>>>>>
>>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
oh boy well its like totally totally a mess right now because i started
on it and then needed to take a break but this is my 'ls'
somewhere in this i realized we needed to be able to have multiple File
objects, not one. thats when it got complex (to rework the code while
maintaining backwards compatibility) :/
https://github.com/adafruit/SD
also a lot of people on mac's end up formatting their cards wrong so i
exposed the low level card detail procedures - these have been handy for
us since the cards are good but they need to be formatted with a
different partition name, etc.etc.
limor
---
File myFile;
void setup()
{
Serial.begin(9600);
Serial.print("\nInitializing SD card...");
// On the Ethernet Shield, CS is pin 4. It's set as an output by default.
// Note that even if it's not used as the CS pin, the hardware SS pin
// (10 on most Arduino boards, 53 on the Mega) must be left as an output
// or the SD library functions will not work.
pinMode(10, OUTPUT);
// we'll use the low level initialization code since we're just
testing if the card is working!
// change the second pin to whatever CS is connected to
if (!SD.card.init(SPI_HALF_SPEED, 4)) {
Serial.println("initialization failed!\nCheck your wiring and that
a card is inserted");
return;
}
// print the type of card
Serial.print("\nCard type: ");
switch(SD.card.type()) {
case SD_CARD_TYPE_SD1:
Serial.println("SD1");
break;
case SD_CARD_TYPE_SD2:
Serial.println("SD2");
break;
case SD_CARD_TYPE_SDHC:
Serial.println("SDHC");
break;
default:
Serial.println("Unknown");
}
// Now we will try to open the 'volume'/'partition' - it should be
FAT16 or FAT32
if (!SD.volume.init(SD.card)) {
Serial.println("Could not find FAT16/FAT32 partition.\nMake sure
you've formatted the card");
return;
}
// print the type and size of the first FAT-type volume
uint32_t volumesize;
Serial.print("\nVolume type is FAT");
Serial.println(SD.volume.fatType(), DEC);
volumesize = SD.volume.blocksPerCluster(); // clusters are
collections of blocks
volumesize *= SD.volume.clusterCount(); // we'll have a lot of
clusters
volumesize *= 512; // SD card blocks are
always 512 bytes
Serial.print("Volume size (bytes): ");
Serial.println(volumesize);
Serial.print("Volume size (Kbytes): ");
volumesize /= 1024;
Serial.println(volumesize);
Serial.print("Volume size (Mbytes): ");
volumesize /= 1024;
Serial.println(volumesize);
SD.root.openRoot(SD.volume);
// add directory listing next
myFile = SD.open("/");
if (myFile) {
Serial.print("opened ");
} else {
Serial.print("failed to open ");
}
Serial.println(myFile.name());
// list all files in directory
printDirectory(myFile, 0);
}
void printDirectory(File dir, int numTabs) {
while(true) {
for (uint8_t i=0; i
Serial.print('\t');
DirectoryEntry entry = myFile.readNextDirectoryEntry();
if (! entry) {
// no more files
break;
}
Serial.print(entry.name());
if (entry.isDirectory()) {
Serial.println("/");
File subdir;
myFile = SD.open("/");
//printDirectory(
} else {
// files have sizes, directories do not
Serial.print("\t\t");
Serial.println(entry.size(), DEC);
}
}
}
On 2/22/2011 11:27 PM, David A. Mellis wrote:
> That could be very useful. What do you have in mind for the API?
>
> 2011/2/22 Limor<>:
>> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
>> i have some code on github but its very much in progress
>>
>>
>> On Feb 22, 2011, at 9:07 PM, Tom Igoe<> wrote:
>>
>>> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>>>
>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe<>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis"<>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe<>
>>>>> Cc: Arduino Developers<>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Works for me.
t.
On Feb 23, 2011, at 9:50 AM, David A. Mellis wrote:
> I'll do it.
>
> I think I may just change the default from O_SYNC (non buffered) mode
> to non-O_SYNC (buffered) mode. It's not as though we had any
> complaints about the buffered mode, it just seemed like a good idea
> when the performance implications weren't clear. If your board
> randomly crashes or loses power, you'll have problems either way. And
> there's still explicit syncing with flush(). I'm not convinced that
> the distinction between buffered and unbuffered mode is important
> enough in practice to expose in the API.
>
> David
>
> 2011/2/23 Tom Igoe <>:
>> Oh, perfect, then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. OK if i just make that change to the repo?
>>
>> t.
>>
>> On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
>>
>>> By buffered, I mean with O_SYNC off, when writes are buffered in the
>>> memory of the microcontroller before being written to the SD card.
>>> The flush() command will force a sync.
>>>
>>> 2011/2/23 Tom Igoe <>:
>>>> Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>>>
>>>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>>>
>>>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>>>
>>>> t.
>>>>
>>>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>>>
>>>>> 2011/2/22 Tom Igoe <>:
>>>>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>>>
>>>>> What do you mean by turning it off and on? Is acceptable to have a
>>>>> way to open the file in buffered or unbuffered mode, with an explicit
>>>>> sync option for buffered mode? Or do you think we need to be able to
>>>>> dynamically switch between buffered and unbuffered modes? If the
>>>>> latter, why? Or maybe we can get away with simply using buffered mode
>>>>> all the time, and having people sync when needed?
>>>>>
>>>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>>>
>>>>> I did this at one point during development, but it seemed unnecessary
>>>>> given that you can delete the file before opening it. Would you want
>>>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>>>> FILE_WRITE? Or distinguish the two some other way?
>>>>>
>>>>>> t.
>>>>>>
>>>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>>>
>>>>>>> done!
>>>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>>>
>>>>>>> m
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2011/2/11 Tom Igoe <>
>>>>>>> A possible solution to the slow response from the SD library:
>>>>>>>
>>>>>>> t.
>>>>>>>
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: "David A. Mellis" <>
>>>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>>>> To: Tom Igoe <>
>>>>>>>> Cc: Arduino Developers <>
>>>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>>>
>>>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>>>> which means all changes are immediately physically written to the SD
>>>>>>>> card. This slows things done, but is more robust, because there
>>>>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>>>
>>>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>>>>
>>>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>>>>
>>>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>>>
>>>>>>>>> t.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Developers mailing list
>>>>>>>>>
>>>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>>
>>
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
In data mercoledì 23 febbraio 2011 15:50:12, David A. Mellis ha scritto:
> there's still explicit syncing with flush(). I'm not convinced that
> the distinction between buffered and unbuffered mode is important
> enough in practice to expose in the API.
I agree to use unbuffered mode by default, from a beginner point of view is
better.
I disagree, instead, to completely remove flush() method from the streaming
API.
I have at least two good reasons:
1) in buffered mode, when you write something, the data is kept into the
buffer until one of these conditions is met:
- the buffer is full
- a timeout occurs
- the file is closed
- flush method is called
Since we don't implement a timeout mechanism (correct me if i'm wrong),
without the flush() method you have no way to force the writing of a buffer
partially filled (unless you close and reopen the file, but could be some
other kind of "streams" where you can't do that).
2) every unbuffered write is a consuming resource monster.
SD-cards require that an entire sector should be written at a time (512-
bytes). In non buffered mode this means that "printing" a string of 70 bytes
causes the writing of that sector 70 times, because the print class calls the
write() method repeteadly for every byte of the string. Is this a problem?
yes, because the lifetime of the flash memory is decimated (you write the
sector 70 times instead of one).
another example? The ethernet library.
If you send a string, using Print methods, a packet is sent for every byte of
the string. Is this a problem? it depends:
- if you are on your LAN maybe not (if you are not concerned of the fact that
streaming the analog-in consume 100KB/sec)
- if you are using an external webservice, you are wasting about 15 times the
bandwidth normally needed. And this, yes, is a problem.
my 0.02
C
The one-character-at-a-time approach can really be a huge performance
hit, even with buffering.
One easy improvement is for the Print class to use block writes. About
a year ago I re-wrote the Print class this way. I'll attach that code.
It's limited to only tiny buffered chucks, but still better than
1-char-at-a-time. This involves no API changes.
Of course, making block reads and writes the easiest path, by
integrating the String class with the Stream class, would be much
better. If the API is good, efficient block writes would be the easiest
path for Arduino users.
I realize there's a lot of contraversy regarding the String class, and
currently it's in a sort of decision-making limbo (plus lingering doubt
it really works well, though so far there are no confirmed bugs in my
improved version). But if Stream integrated nicely with String, that'd
pave the way to both better usability and higher performance.
-Paul
On 02/23/2011 11:49 AM, Cristian Maglie wrote:
>
> In data mercoledì 23 febbraio 2011 15:50:12, David A. Mellis ha scritto:
>
> > there's still explicit syncing with flush(). I'm not convinced that
>
> > the distinction between buffered and unbuffered mode is important
>
> > enough in practice to expose in the API.
>
> I agree to use unbuffered mode by default, from a beginner point of
> view is better.
>
> I disagree, instead, to completely remove flush() method from the
> streaming API.
>
> I have at least two good reasons:
>
> 1) in buffered mode, when you write something, the data is kept into
> the buffer until one of these conditions is met:
>
> - the buffer is full
>
> - a timeout occurs
>
> - the file is closed
>
> - flush method is called
>
> Since we don't implement a timeout mechanism (correct me if i'm
> wrong), without the flush() method you have no way to force the
> writing of a buffer partially filled (unless you close and reopen the
> file, but could be some other kind of "streams" where you can't do that).
>
> 2) every unbuffered write is a consuming resource monster.
>
> SD-cards require that an entire sector should be written at a time
> (512-bytes). In non buffered mode this means that "printing" a string
> of 70 bytes causes the writing of that sector 70 times, because the
> print class calls the write() method repeteadly for every byte of the
> string. Is this a problem? yes, because the lifetime of the flash
> memory is decimated (you write the sector 70 times instead of one).
>
> another example? The ethernet library.
>
> If you send a string, using Print methods, a packet is sent for every
> byte of the string. Is this a problem? it depends:
>
> - if you are on your LAN maybe not (if you are not concerned of the
> fact that streaming the analog-in consume 100KB/sec)
>
> - if you are using an external webservice, you are wasting about 15
> times the bandwidth normally needed. And this, yes, is a problem.
>
> my 0.02
>
> C
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
# 20

24-02-2011 03:44 AM
|
|
|
We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
With the SD library: took 260 seconds to write the same image to the same SD card.
Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
t.
_______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
One thing it could be is the fact that we open files in sync mode,
which means all changes are immediately physically written to the SD
card. This slows things done, but is more robust, because there
aren't any buffered changes to lose if power dies, for example. You
could try removing O_SYNC from the FILE_WRITE definition in SD.h and
then retry the sketch to see if it changes the speed. If that's the
issue, we should be able to find a way to resolve it.
On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>
> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> With the SD library: took 260 seconds to write the same image to the same SD card.
>
> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>
> t.
>
>
> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
#define FILE_READ O_READ
#define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
#define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
Or we could add a function to turn the sync buffer on and off, like so:
SD.bufferWrite(ON);
or
SD.bufferWrite(OFF);
I'f imagine you'd call this right before calling SD.open()
Which seems better?
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
another option is to pass it as an extra argument in the write() command
so you could speed up some writes (like fast data streams) but not all
On 2/18/2011 7:14 AM, Tom Igoe wrote:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe<>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis"<>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe<>
>> > Cc: Arduino Developers<>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
keep the safer but slower mode as the one people get if they don't
explicitly request the other?
I'm assuming that we don't need a way to dynamically switch between
buffered and unbuffered modes. Right? Calling the flush() function
will explicitly save all changes to the SD card if you're in buffered
mode.
Added to the Google Code issue list:
http://code.google.com/p/arduino/issues/detail?id=483
David
2011/2/18 Tom Igoe <>:
> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. Â See discussion below for the magnitude of the change. Â Perhaps we could add an API option for turning it on or off? Â Easiest might be to add a definition like so:
>
> #define FILE_READ O_READ
> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>
> Or we could add a function to turn the sync buffer on and off, like so:
>
> SD.bufferWrite(ON);
> or
> SD.bufferWrite(OFF);
>
> I'f imagine you'd call this right before calling SD.open()
>
> Which seems better?
>
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Interesting, but I think I'd rather just do it in the file open mode.
2011/2/18 Limor <>:
> another option is to pass it as an extra argument in the write() command so
> you could speed up some writes (like fast data streams) but not all
>
> On 2/18/2011 7:14 AM, Tom Igoe wrote:
>>
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD
>> library and found that you get a significant speed increase with O_SYNC off.
>> Â See discussion below for the magnitude of the change. Â Perhaps we could add
>> an API option for turning it on or off? Â Easiest might be to add a
>> definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> Â done!
>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen shot
>>> fromt he serial and the picture as attached.
>>>
>>> Â m
>>>
>>>
>>>
>>> Â 2011/2/11 Tom Igoe<>
>>> Â A possible solution to the slow response from the SD library:
>>>
>>> Â t.
>>>
>>>
>>> Â Begin forwarded message:
>>>
>>> Â > Â From: "David A. Mellis"<>
>>> Â > Â Date: February 11, 2011 12:11:53 PM EST
>>> Â > Â To: Tom Igoe<>
>>> Â > Â Cc: Arduino Developers<>
>>> Â > Â Subject: Re: [Developers] SD or SPI problem?
>>> Â >
>>> Â > Â One thing it could be is the fact that we open files in sync mode,
>>> Â > Â which means all changes are immediately physically written to the SD
>>> Â > Â card. Â This slows things done, but is more robust, because there
>>> Â > Â aren't any buffered changes to lose if power dies, for example. Â You
>>> Â > Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> Â > Â then retry the sketch to see if it changes the speed. Â If that's the
>>> Â > Â issue, we should be able to find a way to resolve it.
>>> Â >
>>> Â > Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>> Â >> Â We've been playing around with a LinkSprite camera here at ITP, and
>>> as part of it one of our researchers ran SparkFun's example that writes to
>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>> Â >>
>>> Â >> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>> write to an SD card, a 12K file.
>>> Â >> Â With the SD library: Â took 260 seconds to write the same image to
>>> the same SD card.
>>> Â >>
>>> Â >> Â Not sure if the problem is with the SD library, or the SPI library,
>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>> can't recall what we defaulted to. Anyone got an idea?
>>> Â >>
>>> Â >> Â t.
>>> Â >>
>>> Â >>
>>> Â >> Â _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
I like Limor's idea too, but this seems like the easiest solution. I didn't realize that about the flush() command, that's good to know.
t.
On Feb 18, 2011, at 10:26 AM, David A. Mellis wrote:
> Maybe FILE_WRITE and FILE_WRITE_BUFFERED or something? That way, we
> keep the safer but slower mode as the one people get if they don't
> explicitly request the other?
>
> I'm assuming that we don't need a way to dynamically switch between
> buffered and unbuffered modes. Right? Calling the flush() function
> will explicitly save all changes to the SD card if you're in buffered
> mode.
>
> Added to the Google Code issue list:
> http://code.google.com/p/arduino/issues/detail?id=483
>
> David
>
> 2011/2/18 Tom Igoe <>:
>> So Mustafa Bagdatli did a test of the LinkSprite camera with the SD library and found that you get a significant speed increase with O_SYNC off. See discussion below for the magnitude of the change. Perhaps we could add an API option for turning it on or off? Easiest might be to add a definition like so:
>>
>> #define FILE_READ O_READ
>> #define FILE_WRITE_FAST (O_READ | O_WRITE | O_CREAT)
>> #define FILE_WRITE_SECURE (O_READ | O_WRITE | O_CREAT | O_SYNC)
>>
>> Or we could add a function to turn the sync buffer on and off, like so:
>>
>> SD.bufferWrite(ON);
>> or
>> SD.bufferWrite(OFF);
>>
>> I'f imagine you'd call this right before calling SD.open()
>>
>> Which seems better?
>>
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
___________________________________________________
Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.
Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
t.
On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
> done!
> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>
> m
>
>
>
> 2011/2/11 Tom Igoe <>
> A possible solution to the slow response from the SD library:
>
> t.
>
>
> Begin forwarded message:
>
> > From: "David A. Mellis" <>
> > Date: February 11, 2011 12:11:53 PM EST
> > To: Tom Igoe <>
> > Cc: Arduino Developers <>
> > Subject: Re: [Developers] SD or SPI problem?
> >
> > One thing it could be is the fact that we open files in sync mode,
> > which means all changes are immediately physically written to the SD
> > card. This slows things done, but is more robust, because there
> > aren't any buffered changes to lose if power dies, for example. You
> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
> > then retry the sketch to see if it changes the speed. If that's the
> > issue, we should be able to find a way to resolve it.
> >
> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
> >>
> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
> >> With the SD library: took 260 seconds to write the same image to the same SD card.
> >>
> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
> >>
> >> t.
> >>
> >>
> >> _______________________________________________
> >> Developers mailing list
> >>
> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
> >>
>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
i have some code on github but its very much in progress
On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>
> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>>> From: "David A. Mellis" <>
>>> Date: February 11, 2011 12:11:53 PM EST
>>> To: Tom Igoe <>
>>> Cc: Arduino Developers <>
>>> Subject: Re: [Developers] SD or SPI problem?
>>>
>>> One thing it could be is the fact that we open files in sync mode,
>>> which means all changes are immediately physically written to the SD
>>> card. This slows things done, but is more robust, because there
>>> aren't any buffered changes to lose if power dies, for example. You
>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>> then retry the sketch to see if it changes the speed. If that's the
>>> issue, we should be able to find a way to resolve it.
>>>
>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>
>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>
>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>
>>>> t.
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
2011/2/22 Tom Igoe <>:
> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
What do you mean by turning it off and on? Is acceptable to have a
way to open the file in buffered or unbuffered mode, with an explicit
sync option for buffered mode? Or do you think we need to be able to
dynamically switch between buffered and unbuffered modes? If the
latter, why? Or maybe we can get away with simply using buffered mode
all the time, and having people sync when needed?
> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
I did this at one point during development, but it seemed unnecessary
given that you can delete the file before opening it. Would you want
to go back to having FILE_APPEND or FILE_REPLACE instead of
FILE_WRITE? Or distinguish the two some other way?
> t.
>
> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>
>> done!
>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>
>> m
>>
>>
>>
>> 2011/2/11 Tom Igoe <>
>> A possible solution to the slow response from the SD library:
>>
>> t.
>>
>>
>> Begin forwarded message:
>>
>> > From: "David A. Mellis" <>
>> > Date: February 11, 2011 12:11:53 PM EST
>> > To: Tom Igoe <>
>> > Cc: Arduino Developers <>
>> > Subject: Re: [Developers] SD or SPI problem?
>> >
>> > One thing it could be is the fact that we open files in sync mode,
>> > which means all changes are immediately physically written to the SD
>> > card. Â This slows things done, but is more robust, because there
>> > aren't any buffered changes to lose if power dies, for example. Â You
>> > could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>> > then retry the sketch to see if it changes the speed. Â If that's the
>> > issue, we should be able to find a way to resolve it.
>> >
>> > On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>> >> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>> >>
>> >> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>> >> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>> >>
>> >> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>> >>
>> >> t.
>> >>
>> >>
>> >> _______________________________________________
>> >> Developers mailing list
>> >>
>> >> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>> >>
>>
>>
>>
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
That could be very useful. What do you have in mind for the API?
2011/2/22 Limor <>:
> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
> Â i have some code on github but its very much in progress
>
>
> On Feb 22, 2011, at 9:07 PM, Tom Igoe <> wrote:
>
>> Â Â Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. Â But working on both, we ran across two important needs:
>>
>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. Â This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
t.
On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
> 2011/2/22 Tom Igoe <>:
>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>
> What do you mean by turning it off and on? Is acceptable to have a
> way to open the file in buffered or unbuffered mode, with an explicit
> sync option for buffered mode? Or do you think we need to be able to
> dynamically switch between buffered and unbuffered modes? If the
> latter, why? Or maybe we can get away with simply using buffered mode
> all the time, and having people sync when needed?
>
>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>
> I did this at one point during development, but it seemed unnecessary
> given that you can delete the file before opening it. Would you want
> to go back to having FILE_APPEND or FILE_REPLACE instead of
> FILE_WRITE? Or distinguish the two some other way?
>
>> t.
>>
>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>
>>> done!
>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>
>>> m
>>>
>>>
>>>
>>> 2011/2/11 Tom Igoe <>
>>> A possible solution to the slow response from the SD library:
>>>
>>> t.
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: "David A. Mellis" <>
>>>> Date: February 11, 2011 12:11:53 PM EST
>>>> To: Tom Igoe <>
>>>> Cc: Arduino Developers <>
>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>
>>>> One thing it could be is the fact that we open files in sync mode,
>>>> which means all changes are immediately physically written to the SD
>>>> card. This slows things done, but is more robust, because there
>>>> aren't any buffered changes to lose if power dies, for example. You
>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>> then retry the sketch to see if it changes the speed. If that's the
>>>> issue, we should be able to find a way to resolve it.
>>>>
>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>
>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>
>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
By buffered, I mean with O_SYNC off, when writes are buffered in the
memory of the microcontroller before being written to the SD card.
The flush() command will force a sync.
2011/2/23 Tom Igoe <>:
> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>
> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>
> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>
> t.
>
> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>
>> 2011/2/22 Tom Igoe <>:
>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>
>> What do you mean by turning it off and on? Â Is acceptable to have a
>> way to open the file in buffered or unbuffered mode, with an explicit
>> sync option for buffered mode? Â Or do you think we need to be able to
>> dynamically switch between buffered and unbuffered modes? Â If the
>> latter, why? Â Or maybe we can get away with simply using buffered mode
>> all the time, and having people sync when needed?
>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>
>> I did this at one point during development, but it seemed unnecessary
>> given that you can delete the file before opening it. Â Would you want
>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>> FILE_WRITE? Â Or distinguish the two some other way?
>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe <>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis" <>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe <>
>>>>> Cc: Arduino Developers <>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. Â This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Oh, perfect, then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. OK if i just make that change to the repo?
t.
On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
> By buffered, I mean with O_SYNC off, when writes are buffered in the
> memory of the microcontroller before being written to the SD card.
> The flush() command will force a sync.
>
> 2011/2/23 Tom Igoe <>:
>> Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>
>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>
>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>
>> t.
>>
>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>
>>> 2011/2/22 Tom Igoe <>:
>>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> What do you mean by turning it off and on? Is acceptable to have a
>>> way to open the file in buffered or unbuffered mode, with an explicit
>>> sync option for buffered mode? Or do you think we need to be able to
>>> dynamically switch between buffered and unbuffered modes? If the
>>> latter, why? Or maybe we can get away with simply using buffered mode
>>> all the time, and having people sync when needed?
>>>
>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> I did this at one point during development, but it seemed unnecessary
>>> given that you can delete the file before opening it. Would you want
>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>> FILE_WRITE? Or distinguish the two some other way?
>>>
>>>> t.
>>>>
>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>
>>>>> done!
>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>
>>>>> m
>>>>>
>>>>>
>>>>>
>>>>> 2011/2/11 Tom Igoe <>
>>>>> A possible solution to the slow response from the SD library:
>>>>>
>>>>> t.
>>>>>
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> From: "David A. Mellis" <>
>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>> To: Tom Igoe <>
>>>>>> Cc: Arduino Developers <>
>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>
>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>> which means all changes are immediately physically written to the SD
>>>>>> card. This slows things done, but is more robust, because there
>>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>
>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>>
>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>>
>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>
>>>>>>> t.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Developers mailing list
>>>>>>>
>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
I'll do it.
I think I may just change the default from O_SYNC (non buffered) mode
to non-O_SYNC (buffered) mode. It's not as though we had any
complaints about the buffered mode, it just seemed like a good idea
when the performance implications weren't clear. If your board
randomly crashes or loses power, you'll have problems either way. And
there's still explicit syncing with flush(). I'm not convinced that
the distinction between buffered and unbuffered mode is important
enough in practice to expose in the API.
David
2011/2/23 Tom Igoe <>:
> Oh, perfect, Â then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. Â OK if i just make that change to the repo?
>
> t.
>
> On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
>
>> By buffered, I mean with O_SYNC off, when writes are buffered in the
>> memory of the microcontroller before being written to the SD card.
>> The flush() command will force a sync.
>>
>> 2011/2/23 Tom Igoe <>:
>>> Which is buffered mode? Â With O_SYNC on or off? Â It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>>
>>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>>
>>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>>
>>> t.
>>>
>>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>>
>>>> 2011/2/22 Tom Igoe <>:
>>>>> 1) the ability to turn on and off sync. Â It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>>
>>>> What do you mean by turning it off and on? Â Is acceptable to have a
>>>> way to open the file in buffered or unbuffered mode, with an explicit
>>>> sync option for buffered mode? Â Or do you think we need to be able to
>>>> dynamically switch between buffered and unbuffered modes? Â If the
>>>> latter, why? Â Or maybe we can get away with simply using buffered mode
>>>> all the time, and having people sync when needed?
>>>>
>>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>>
>>>> I did this at one point during development, but it seemed unnecessary
>>>> given that you can delete the file before opening it. Â Would you want
>>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>>> FILE_WRITE? Â Or distinguish the two some other way?
>>>>
>>>>> t.
>>>>>
>>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>>
>>>>>> done!
>>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>>
>>>>>> m
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2011/2/11 Tom Igoe <>
>>>>>> A possible solution to the slow response from the SD library:
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>>> From: "David A. Mellis" <>
>>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>>> To: Tom Igoe <>
>>>>>>> Cc: Arduino Developers <>
>>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>>
>>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>>> which means all changes are immediately physically written to the SD
>>>>>>> card. Â This slows things done, but is more robust, because there
>>>>>>> aren't any buffered changes to lose if power dies, for example. Â You
>>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>>> then retry the sketch to see if it changes the speed. Â If that's the
>>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>>
>>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. Â We took the same code, and changed it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>>>
>>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>>> With the SD library: Â took 260 seconds to write the same image to the same SD card.
>>>>>>>>
>>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. Â I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>>
>>>>>>>> t.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Developers mailing list
>>>>>>>>
>>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>
>>>>
>>>> _______________________________________________
>>>> Developers mailing list
>>>>
>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>>
>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
oh boy well its like totally totally a mess right now because i started
on it and then needed to take a break but this is my 'ls'
somewhere in this i realized we needed to be able to have multiple File
objects, not one. thats when it got complex (to rework the code while
maintaining backwards compatibility) :/
https://github.com/adafruit/SD
also a lot of people on mac's end up formatting their cards wrong so i
exposed the low level card detail procedures - these have been handy for
us since the cards are good but they need to be formatted with a
different partition name, etc.etc.
limor
---
File myFile;
void setup()
{
Serial.begin(9600);
Serial.print("\nInitializing SD card...");
// On the Ethernet Shield, CS is pin 4. It's set as an output by default.
// Note that even if it's not used as the CS pin, the hardware SS pin
// (10 on most Arduino boards, 53 on the Mega) must be left as an output
// or the SD library functions will not work.
pinMode(10, OUTPUT);
// we'll use the low level initialization code since we're just
testing if the card is working!
// change the second pin to whatever CS is connected to
if (!SD.card.init(SPI_HALF_SPEED, 4)) {
Serial.println("initialization failed!\nCheck your wiring and that
a card is inserted");
return;
}
// print the type of card
Serial.print("\nCard type: ");
switch(SD.card.type()) {
case SD_CARD_TYPE_SD1:
Serial.println("SD1");
break;
case SD_CARD_TYPE_SD2:
Serial.println("SD2");
break;
case SD_CARD_TYPE_SDHC:
Serial.println("SDHC");
break;
default:
Serial.println("Unknown");
}
// Now we will try to open the 'volume'/'partition' - it should be
FAT16 or FAT32
if (!SD.volume.init(SD.card)) {
Serial.println("Could not find FAT16/FAT32 partition.\nMake sure
you've formatted the card");
return;
}
// print the type and size of the first FAT-type volume
uint32_t volumesize;
Serial.print("\nVolume type is FAT");
Serial.println(SD.volume.fatType(), DEC);
volumesize = SD.volume.blocksPerCluster(); // clusters are
collections of blocks
volumesize *= SD.volume.clusterCount(); // we'll have a lot of
clusters
volumesize *= 512; // SD card blocks are
always 512 bytes
Serial.print("Volume size (bytes): ");
Serial.println(volumesize);
Serial.print("Volume size (Kbytes): ");
volumesize /= 1024;
Serial.println(volumesize);
Serial.print("Volume size (Mbytes): ");
volumesize /= 1024;
Serial.println(volumesize);
SD.root.openRoot(SD.volume);
// add directory listing next
myFile = SD.open("/");
if (myFile) {
Serial.print("opened ");
} else {
Serial.print("failed to open ");
}
Serial.println(myFile.name());
// list all files in directory
printDirectory(myFile, 0);
}
void printDirectory(File dir, int numTabs) {
while(true) {
for (uint8_t i=0; i
Serial.print('\t');
DirectoryEntry entry = myFile.readNextDirectoryEntry();
if (! entry) {
// no more files
break;
}
Serial.print(entry.name());
if (entry.isDirectory()) {
Serial.println("/");
File subdir;
myFile = SD.open("/");
//printDirectory(
} else {
// files have sizes, directories do not
Serial.print("\t\t");
Serial.println(entry.size(), DEC);
}
}
}
On 2/22/2011 11:27 PM, David A. Mellis wrote:
> That could be very useful. What do you have in mind for the API?
>
> 2011/2/22 Limor<>:
>> somewhat related, ive been hacking at the library as well to add directory listing and enumeration support. i.e. the problem of how does one "list every file in a dir". its very useful for many different and popular sketch frameworks.
>> i have some code on github but its very much in progress
>>
>>
>> On Feb 22, 2011, at 9:07 PM, Tom Igoe<> wrote:
>>
>>> Mustafa and I worked out some new SD card examples today, one that uploads a file to Arduino serially via Processing, and another that downloads a file from Arduino serially. We'll post when they are cleaned up. But working on both, we ran across two important needs:
>>>
>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>
>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>
>>> t.
>>>
>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>
>>>> done!
>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>
>>>> m
>>>>
>>>>
>>>>
>>>> 2011/2/11 Tom Igoe<>
>>>> A possible solution to the slow response from the SD library:
>>>>
>>>> t.
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "David A. Mellis"<>
>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>> To: Tom Igoe<>
>>>>> Cc: Arduino Developers<>
>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>
>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>> which means all changes are immediately physically written to the SD
>>>>> card. This slows things done, but is more robust, because there
>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>> issue, we should be able to find a way to resolve it.
>>>>>
>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> wrote:
>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>
>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>
>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>
>>>>>> t.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Developers mailing list
>>>
>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
>> _______________________________________________
>> Developers mailing list
>>
>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
Works for me.
t.
On Feb 23, 2011, at 9:50 AM, David A. Mellis wrote:
> I'll do it.
>
> I think I may just change the default from O_SYNC (non buffered) mode
> to non-O_SYNC (buffered) mode. It's not as though we had any
> complaints about the buffered mode, it just seemed like a good idea
> when the performance implications weren't clear. If your board
> randomly crashes or loses power, you'll have problems either way. And
> there's still explicit syncing with flush(). I'm not convinced that
> the distinction between buffered and unbuffered mode is important
> enough in practice to expose in the API.
>
> David
>
> 2011/2/23 Tom Igoe <>:
>> Oh, perfect, then I think just adding a #define for FILE_WRITE_BUFFERED vs FILE_WRITE will do the trick, and we can write up the differences. OK if i just make that change to the repo?
>>
>> t.
>>
>> On Feb 23, 2011, at 8:43 AM, David A. Mellis wrote:
>>
>>> By buffered, I mean with O_SYNC off, when writes are buffered in the
>>> memory of the microcontroller before being written to the SD card.
>>> The flush() command will force a sync.
>>>
>>> 2011/2/23 Tom Igoe <>:
>>>> Which is buffered mode? With O_SYNC on or off? It's much faster with it off, but it does mean you might lose some data if you lose power, right?
>>>>
>>>> I think if you can choose when you open the file, that would be fine. I think Limor's right that it would be nice to have a sync() command, so you could force a write to the card from time to time, but I don't think it's essential.
>>>>
>>>> Limor's changes sound interesting too, and we're working on some pages to document the examples here, so perhaps we should take a look at what she's got. LImor, where is it on gitHub, and how in progress is it?
>>>>
>>>> t.
>>>>
>>>> On Feb 22, 2011, at 11:25 PM, David A. Mellis wrote:
>>>>
>>>>> 2011/2/22 Tom Igoe <>:
>>>>>> 1) the ability to turn on and off sync. It seems like that's solved with the O_SYNC change Dave brought up the other day, but we should get that in for the next revision. Turning off sync made the code much more speedy, and reliable.
>>>>>
>>>>> What do you mean by turning it off and on? Is acceptable to have a
>>>>> way to open the file in buffered or unbuffered mode, with an explicit
>>>>> sync option for buffered mode? Or do you think we need to be able to
>>>>> dynamically switch between buffered and unbuffered modes? If the
>>>>> latter, why? Or maybe we can get away with simply using buffered mode
>>>>> all the time, and having people sync when needed?
>>>>>
>>>>>> 2) the ability to differentiate FILE_WRITE two ways: replacing the file, or appending to it.
>>>>>
>>>>> I did this at one point during development, but it seemed unnecessary
>>>>> given that you can delete the file before opening it. Would you want
>>>>> to go back to having FILE_APPEND or FILE_REPLACE instead of
>>>>> FILE_WRITE? Or distinguish the two some other way?
>>>>>
>>>>>> t.
>>>>>>
>>>>>> On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>>>
>>>>>>> done!
>>>>>>> It is even faster dan Sparkfun! Yay arduino! you can see the screen shot fromt he serial and the picture as attached.
>>>>>>>
>>>>>>> m
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2011/2/11 Tom Igoe <>
>>>>>>> A possible solution to the slow response from the SD library:
>>>>>>>
>>>>>>> t.
>>>>>>>
>>>>>>>
>>>>>>> Begin forwarded message:
>>>>>>>
>>>>>>>> From: "David A. Mellis" <>
>>>>>>>> Date: February 11, 2011 12:11:53 PM EST
>>>>>>>> To: Tom Igoe <>
>>>>>>>> Cc: Arduino Developers <>
>>>>>>>> Subject: Re: [Developers] SD or SPI problem?
>>>>>>>>
>>>>>>>> One thing it could be is the fact that we open files in sync mode,
>>>>>>>> which means all changes are immediately physically written to the SD
>>>>>>>> card. This slows things done, but is more robust, because there
>>>>>>>> aren't any buffered changes to lose if power dies, for example. You
>>>>>>>> could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>>>> then retry the sketch to see if it changes the speed. If that's the
>>>>>>>> issue, we should be able to find a way to resolve it.
>>>>>>>>
>>>>>>>> On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe <> wrote:
>>>>>>>>> We've been playing around with a LinkSprite camera here at ITP, and as part of it one of our researchers ran SparkFun's example that writes to an SD card via the MemoryCard library. We took the same code, and changed it to the current SD library. Both libraries use sdfatlib under the hood.
>>>>>>>>>
>>>>>>>>> With the MemoryCard library: Arduino Uno took approx. 6 seconds to write to an SD card, a 12K file.
>>>>>>>>> With the SD library: took 260 seconds to write the same image to the same SD card.
>>>>>>>>>
>>>>>>>>> Not sure if the problem is with the SD library, or the SPI library, but it bears some investigation. I recall we discsussed SPI modes, but can't recall what we defaulted to. Anyone got an idea?
>>>>>>>>>
>>>>>>>>> t.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Developers mailing list
>>>>>>>>>
>>>>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>>
>>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>>
>>>>> http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>
>>>>
>>
>>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
In data mercoledì 23 febbraio 2011 15:50:12, David A. Mellis ha scritto:
> there's still explicit syncing with flush(). I'm not convinced that
> the distinction between buffered and unbuffered mode is important
> enough in practice to expose in the API.
I agree to use unbuffered mode by default, from a beginner point of view is
better.
I disagree, instead, to completely remove flush() method from the streaming
API.
I have at least two good reasons:
1) in buffered mode, when you write something, the data is kept into the
buffer until one of these conditions is met:
- the buffer is full
- a timeout occurs
- the file is closed
- flush method is called
Since we don't implement a timeout mechanism (correct me if i'm wrong),
without the flush() method you have no way to force the writing of a buffer
partially filled (unless you close and reopen the file, but could be some
other kind of "streams" where you can't do that).
2) every unbuffered write is a consuming resource monster.
SD-cards require that an entire sector should be written at a time (512-
bytes). In non buffered mode this means that "printing" a string of 70 bytes
causes the writing of that sector 70 times, because the print class calls the
write() method repeteadly for every byte of the string. Is this a problem?
yes, because the lifetime of the flash memory is decimated (you write the
sector 70 times instead of one).
another example? The ethernet library.
If you send a string, using Print methods, a packet is sent for every byte of
the string. Is this a problem? it depends:
- if you are on your LAN maybe not (if you are not concerned of the fact that
streaming the analog-in consume 100KB/sec)
- if you are using an external webservice, you are wasting about 15 times the
bandwidth normally needed. And this, yes, is a problem.
my 0.02
C
The one-character-at-a-time approach can really be a huge performance
hit, even with buffering.
One easy improvement is for the Print class to use block writes. About
a year ago I re-wrote the Print class this way. I'll attach that code.
It's limited to only tiny buffered chucks, but still better than
1-char-at-a-time. This involves no API changes.
Of course, making block reads and writes the easiest path, by
integrating the String class with the Stream class, would be much
better. If the API is good, efficient block writes would be the easiest
path for Arduino users.
I realize there's a lot of contraversy regarding the String class, and
currently it's in a sort of decision-making limbo (plus lingering doubt
it really works well, though so far there are no confirmed bugs in my
improved version). But if Stream integrated nicely with String, that'd
pave the way to both better usability and higher performance.
-Paul
On 02/23/2011 11:49 AM, Cristian Maglie wrote:
>
> In data mercoledì 23 febbraio 2011 15:50:12, David A. Mellis ha scritto:
>
> > there's still explicit syncing with flush(). I'm not convinced that
>
> > the distinction between buffered and unbuffered mode is important
>
> > enough in practice to expose in the API.
>
> I agree to use unbuffered mode by default, from a beginner point of
> view is better.
>
> I disagree, instead, to completely remove flush() method from the
> streaming API.
>
> I have at least two good reasons:
>
> 1) in buffered mode, when you write something, the data is kept into
> the buffer until one of these conditions is met:
>
> - the buffer is full
>
> - a timeout occurs
>
> - the file is closed
>
> - flush method is called
>
> Since we don't implement a timeout mechanism (correct me if i'm
> wrong), without the flush() method you have no way to force the
> writing of a buffer partially filled (unless you close and reopen the
> file, but could be some other kind of "streams" where you can't do that).
>
> 2) every unbuffered write is a consuming resource monster.
>
> SD-cards require that an entire sector should be written at a time
> (512-bytes). In non buffered mode this means that "printing" a string
> of 70 bytes causes the writing of that sector 70 times, because the
> print class calls the write() method repeteadly for every byte of the
> string. Is this a problem? yes, because the lifetime of the flash
> memory is decimated (you write the sector 70 times instead of one).
>
> another example? The ethernet library.
>
> If you send a string, using Print methods, a packet is sent for every
> byte of the string. Is this a problem? it depends:
>
> - if you are on your LAN maybe not (if you are not concerned of the
> fact that streaming the analog-in consume 100KB/sec)
>
> - if you are using an external webservice, you are wasting about 15
> times the bandwidth normally needed. And this, yes, is a problem.
>
> my 0.02
>
> C
>
>
> _______________________________________________
> Developers mailing list
>
> http://arduino.cc/mailman/listinfo/developers_arduino.cc
If the reason for exposing those lower-level details is just to help
people figure out what's wrong with the formatting of their card, I'd
prefer to leave them out of the SD card library. That functionality
could always be provided by a separate program or sketch that does the
same tests using the SDfatlib library directly. Or we could do
something like return a more informative error code from SD.begin(),
without splitting it into separate functions.
As for the directory iteration, do you think we could get away without
the distinction between directory entries and files? That is, could
readNextDirectoryEntry() simply return a File object? And then we
could provide isDirectory() on the file object?
Multiple file support would be nice. How are you allocating the file
objects (and associated data)?
David
On Wed, Feb 23, 2011 at 10:49 AM, Limor <> wrote:
> oh boy well its like totally totally a mess right now because i started on
> it and then needed to take a break but this is my 'ls'
>
> somewhere in this i realized we needed to be able to have multiple File
> objects, not one. thats when it got complex (to rework the code while
> maintaining backwards compatibility) :/
>
> https://github.com/adafruit/SD
>
> also a lot of people on mac's end up formatting their cards wrong so i
> exposed the low level card detail procedures - these have been handy for us
> since the cards are good but they need to be formatted with a different
> partition name, etc.etc.
>
> Â limor
>
> ---
> File myFile;
>
> void setup()
> {
> Â Serial.begin(9600);
> Â Serial.print("\nInitializing SD card...");
> Â // On the Ethernet Shield, CS is pin 4. It's set as an output by default.
> Â // Note that even if it's not used as the CS pin, the hardware SS pin
> Â // (10 on most Arduino boards, 53 on the Mega) must be left as an output
> Â // or the SD library functions will not work.
> Â pinMode(10, OUTPUT);
>
>
> Â // we'll use the low level initialization code since we're just testing if
> the card is working!
> Â // change the second pin to whatever CS is connected to
> Â if (!SD.card.init(SPI_HALF_SPEED, 4)) {
> Â Â Serial.println("initialization failed!\nCheck your wiring and that a card
> is inserted");
> Â Â return;
> Â }
>
> Â // print the type of card
> Â Serial.print("\nCard type: ");
> Â switch(SD.card.type()) {
> Â Â case SD_CARD_TYPE_SD1:
> Â Â Â Serial.println("SD1");
> Â Â Â break;
> Â Â case SD_CARD_TYPE_SD2:
> Â Â Â Serial.println("SD2");
> Â Â Â break;
> Â Â case SD_CARD_TYPE_SDHC:
> Â Â Â Serial.println("SDHC");
> Â Â Â break;
> Â Â default:
> Â Â Â Serial.println("Unknown");
> Â }
>
> Â // Now we will try to open the 'volume'/'partition' - it should be FAT16 or
> FAT32
> Â if (!SD.volume.init(SD.card)) {
> Â Â Serial.println("Could not find FAT16/FAT32 partition.\nMake sure you've
> formatted the card");
> Â Â return;
> Â }
>
> Â // print the type and size of the first FAT-type volume
> Â uint32_t volumesize;
> Â Serial.print("\nVolume type is FAT");
> Â Serial.println(SD.volume.fatType(), DEC);
> Â volumesize = SD.volume.blocksPerCluster(); Â Â // clusters are collections
> of blocks
> Â volumesize *= SD.volume.clusterCount(); Â Â Â // we'll have a lot of
> clusters
> Â volumesize *= 512; Â Â Â Â Â Â Â Â Â Â Â Â Â Â // SD card blocks are always
> 512 bytes
> Â Serial.print("Volume size (bytes): ");
> Â Serial.println(volumesize);
> Â Serial.print("Volume size (Kbytes): ");
> Â volumesize /= 1024;
> Â Serial.println(volumesize);
> Â Serial.print("Volume size (Mbytes): ");
> Â volumesize /= 1024;
> Â Serial.println(volumesize);
>
> Â SD.root.openRoot(SD.volume);
>
> Â // add directory listing next
>
> Â myFile = SD.open("/");
> Â if (myFile) {
> Â Â Serial.print("opened ");
> Â } else {
> Â Â Serial.print("failed to open ");
> Â }
> Â Serial.println(myFile.name());
>
> Â // list all files in directory
> Â printDirectory(myFile, 0);
>
> }
>
> void printDirectory(File dir, int numTabs) {
> Â while(true) {
> Â Â for (uint8_t i=0; i
> Â Â Â Serial.print('\t');
>
> Â Â DirectoryEntry entry = myFile.readNextDirectoryEntry();
> Â Â if (! entry) {
> Â Â Â // no more files
> Â Â Â break;
> Â Â }
> Â Â Serial.print(entry.name());
> Â Â if (entry.isDirectory()) {
> Â Â Â Serial.println("/");
> Â Â Â File subdir;
> Â Â Â myFile = SD.open("/");
> Â Â Â //printDirectory(
> Â Â } else {
> Â Â Â // files have sizes, directories do not
> Â Â Â Serial.print("\t\t");
> Â Â Â Serial.println(entry.size(), DEC);
> Â Â }
> Â }
> }
>
>
> On 2/22/2011 11:27 PM, David A. Mellis wrote:
>>
>> That could be very useful. Â What do you have in mind for the API?
>>
>> 2011/2/22 Limor<>:
>>>
>>> Â somewhat related, ive been hacking at the library as well to add
>>> directory listing and enumeration support. i.e. the problem of how does one
>>> "list every file in a dir". its very useful for many different and popular
>>> sketch frameworks.
>>> Â i have some code on github but its very much in progress
>>>
>>>
>>> Â On Feb 22, 2011, at 9:07 PM, Tom Igoe<> Â wrote:
>>>
>>>> Â Â Mustafa and I worked out some new SD card examples today, one that
>>>> uploads a file to Arduino serially via Processing, and another that
>>>> downloads a file from Arduino serially. We'll post when they are cleaned up.
>>>> Â But working on both, we ran across two important needs:
>>>>
>>>> Â 1) the ability to turn on and off sync. Â It seems like that's solved
>>>> with the O_SYNC change Dave brought up the other day, but we should get that
>>>> in for the next revision. Turning off sync made the code much more speedy,
>>>> and reliable.
>>>>
>>>> Â 2) the ability to differentiate FILE_WRITE two ways: replacing the
>>>> file, or appending to it.
>>>>
>>>> Â t.
>>>>
>>>>  On Feb 17, 2011, at 6:23 PM, mustafa bağdatlı wrote:
>>>>
>>>>> Â done!
>>>>> Â It is even faster dan Sparkfun! Yay arduino! you can see the screen
>>>>> shot fromt he serial and the picture as attached.
>>>>>
>>>>> Â m
>>>>>
>>>>>
>>>>>
>>>>> Â 2011/2/11 Tom Igoe<>
>>>>> Â A possible solution to the slow response from the SD library:
>>>>>
>>>>> Â t.
>>>>>
>>>>>
>>>>> Â Begin forwarded message:
>>>>>
>>>>>> Â From: "David A. Mellis"<>
>>>>>> Â Date: February 11, 2011 12:11:53 PM EST
>>>>>> Â To: Tom Igoe<>
>>>>>> Â Cc: Arduino Developers<>
>>>>>> Â Subject: Re: [Developers] SD or SPI problem?
>>>>>>
>>>>>> Â One thing it could be is the fact that we open files in sync mode,
>>>>>> Â which means all changes are immediately physically written to the SD
>>>>>> Â card. Â This slows things done, but is more robust, because there
>>>>>> Â aren't any buffered changes to lose if power dies, for example. Â You
>>>>>> Â could try removing O_SYNC from the FILE_WRITE definition in SD.h and
>>>>>> Â then retry the sketch to see if it changes the speed. Â If that's the
>>>>>> Â issue, we should be able to find a way to resolve it.
>>>>>>
>>>>>> Â On Thu, Jan 20, 2011 at 3:30 PM, Tom Igoe<> Â wrote:
>>>>>>>
>>>>>>> Â We've been playing around with a LinkSprite camera here at ITP, and
>>>>>>> as part of it one of our researchers ran SparkFun's example that writes to
>>>>>>> an SD card via the MemoryCard library. Â We took the same code, and changed
>>>>>>> it to the current SD library. Â Both libraries use sdfatlib under the hood.
>>>>>>>
>>>>>>> Â With the MemoryCard library: Arduino Uno took approx. 6 seconds to
>>>>>>> write to an SD card, a 12K file.
>>>>>>> Â With the SD library: Â took 260 seconds to write the same image to
>>>>>>> the same SD card.
>>>>>>>
>>>>>>> Â Not sure if the problem is with the SD library, or the SPI library,
>>>>>>> but it bears some investigation. Â I recall we discsussed SPI modes, but
>>>>>>> can't recall what we defaulted to. Anyone got an idea?
>>>>>>>
>>>>>>> Â t.
>>>>>>>
>>>>>>>
>>>>>>> Â _______________________________________________
>>>>>>> Â Developers mailing list
>>>>>>> Â
>>>>>>> Â http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>>>>>
>>>>>
>>>>>
>>>>> Â
>>>>
>>>>
>>>> Â _______________________________________________
>>>> Â Developers mailing list
>>>> Â
>>>> Â http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>>> Â _______________________________________________
>>> Â Developers mailing list
>>> Â
>>> Â http://arduino.cc/mailman/listinfo/developers_arduino.cc
>>>
>
_______________________________________________
Developers mailing list
http://arduino.cc/mailman/listinfo/developers_arduino.cc
|
NewsArc Lists
| Culture Pages
| Computing Archive
| Media-Pages
Link to this page on your blog or website by copying the HTML code below and pasting it into your site:
|
|