SparkFun Forums

[Cannibal]

Do you think better write speeds (hopefully meeting my requirements) could be obtained if data is sent in smaller chunks?

It's certainly worth trying!

You may also wish to cross your fingers that their next firmware release will be a miraculous improvement, but considering that the last one was in July 2006 and also claimed to 'improve write performance', I'm not sure how far this product can ever go.

P.S. Sorry it took so long for me to respond.

[rokicki]

I will mention here that the Parallax Propeller chip will directly drive an SD chip (well, you need to add pullup resistors) and there is a FAT16 driver (fairly minimal, though) that attains write speeds of 100K-200K
bytes/second (depending on the card) using a single cog (so plenty of
power left for your other parts of the app).

That said, you do once in a while get into an erase block delay that
can slow things down a lot (I've observed up to 1/5th of a second on
one card). Because of this, either flow control or large buffers are
indeed essential. (The propeller has 32K onboard, which is a fair amount
of buffering.)

This is not to take anything away from DOSonaChip of course, because
it supports more functions (hierarchical directories for one) and uses a
simpler interface. But the propeller is such a cool chip I figure it deserves
at least a mention.

[Cannibal]

This is not to take anything away from DOSonaChip of course, because
it supports more functions (hierarchical directories for one) and uses a
simpler interface. But the propeller is such a cool chip I figure it deserves
at least a mention.

Thank you for mentioning that. It's good to know there are multiple options for logging data for different trade offs of speed/simplicity.

[cengel_ou]

Has anyone successfully been able to make a directory using the DOSonCHIP card with an SPI line? I've been trying for a couple days now and still cant get it to work.

Also I'm still a little confused as to how the DIR & BUSY lines work. My thoughts are BUSY == 0, then the DOSonCHIP card is not busy and it is ready to accept data, but only if DIR == 1. So if DIR == 1 & BUSY == 0, then I can send a command. If DIR == 0 and BUSY == 0 then the DOSonCHIP wants to send something. I am able to get an initial prompt from the chip ('>') and I can get it to echo back what I send it data, but I dont see anything when I send it commands.

Any help, or sample code for how to get this thing to work would be appreciated.

[Cannibal]

Are you de-asserting the select line between each character in the command?

I believe it's necessary to get it to register.

[cengel_ou]

I wasnt de-asserting before. But when I added this the same results occured. Here's the code I'm using to attempt to create a directory 'A:\test'. I also use similar code to first 'cd A:\' as you had noted must be done in a previous post.

//****************************************************//

unsigned int i = 1;
unsigned char error;

unsigned int command[11];

command[0] = 0x6D; // "m"
command[1] = 0x64; // "d"
command[2] = 0xFF; // " "

command[3] = 0x41; // "A"
command[4] = 0x3A; // ":"
command[5] = 0x5C; // "\"
command[6] = 0x74; // "t"
command[7] = 0x65; // "e"
command[8] = 0x73; // "s"
command[9] = 0x74; // "t"
command[10] = 0x0D; // carriage return


i = 0;
while(i < 11)
{
SDCS = 0;
nanodelay();
nanodelay();
nanodelay();
nanodelay();
WriteSPI2(command);
nanodelay();
nanodelay();
SDCS = 1;
nanodelay();
nanodelay();
i = i + 1;
}

SDCS=0;
nanodelay();
WriteSPI2(0xFF); // Clock out the data from the DOSonCHIP
nanodelay();
SDCS=1; //Tell SD card that previous byte has finished
nanodelay();
error = ReadSPI2();
WriteUART1(error);

SDCS=0;
nanodelay();
WriteSPI2(0xFF); // Clock out the data from the DOSonCHIP
nanodelay();
SDCS=1; //Tell SD card that previous byte has finished
nanodelay();
error = ReadSPI2();
WriteUART1(error);
//**********************************************************//

I wasnt sure when I should be trying to read in the error messages that may be sent from the DOSonCHIP ... the WriteSPI(0xFF) at the end of the command transmission was attempting to do this. Generally all I get is the " " character represented by the 0xFF I send it.

Any noticable errors in this code??

Thanks again

[Cannibal]

The only thing I can think of is adding a while statement to wait for the data ready flag to go up, after the directory create command is sent.

something of the form of (can't remember if it's active high or low when it wants your attention)
while (!datareadypin){}

It's been about three months since I've had the DoC wired up, but I seem to remember having to give it some time to implement the command before proceeding to the next.


Edit: Looking back over my code, I believe the issue as I stated above. One should wait for the command response:

f (SDDir ==0 && SDBusy ==0){
microdelay();
if (SDDir==0 && SDBusy ==0){
SendSD(0xFF);
}
}

this snippet from the main loop of my code would take care of clocking out the responses.

[Polux rsv]

Hi,
Write speed on SD card is very dependant of the card you use. With EFSL driving SPI0 on LPC2148, I measured 20kbytes/s on a old 16MBytes SD wich came with my Canon camera. On a 256MBytes card, at exact same code and spi speed, I measured 150kbytes/s The difference is in the "wait_write_completion".

Angelo

[BrianS]

Terrible, I just purchased a DOSonCHIP board for data logging. Thought I'd look on this forum for help working with coding for it in SPI. Didn't know it had the slooooow..... problems it has. Now what do I do? Will Sparkfun take these back for refund because from what I've read they were suppose to be able to stream mp3/video files. I purchased a different product from parallex which was basically the same thing but was a device which would communicate by SPI to a USB memory stick. It too was a big waste of time and money because no one was able to ever comminicate successfully via SPI with it and get it working. It too had very poor documentation.

Maybe I'll just stick with directly using a mmc/sd card in SPI mode. That worked great if I remember using my Mikroe Pascal compiler and EasyPic 5 board. Was able to create files and write to them really fast with a PIC and then pop the card into my laptop and was able to open and read the files.

Reason I got the DOSonCHIP was because I thought it would be faster and easier to use.

I can stream my data to a 16meg serial eeprom with dual 256byte sram buffers pretty fast. I was thinking about bypassing the eeproms and just acquire data right to a SD card instead but now think I'll go back to using the EEProms again. They are great for streaming data especially with the use of the built in buffers.

Anyone need a DOSonCHIP board cheep?

Bryan

[FartingMonkey92]

In the future, can everyone use the code tag to make posts easier to read...

[evplasmaman]

So apparently they have a new firmware version 2.0 available at http://dosonchip.com/support/downloads.html

They claim up to 60X speed improvement... up to...

Has anyone attempted their update procedure yet? I would do the honor my self but my board is still in the post and wont get here till Thursday!


If this fixes the problem then we may have a usable chip

-jG

[Cannibal]

Hi There,

It seems this subject is still alive, so I'll throw my newest shiniest $0.02 in.

Even if there has been a 60x increase in speed over the previous version, that from my experience would be a little less than 30k/sec.

I was able to get the uALFAT to do that a while back without too much difficulty, and while the command set on the dosonchip is arguably nicer, there are less hidden gotchas in its data sheet. They may have even fixed up the data sheet since the last version, and from what I can see in the change notes they have finally done away with that inexplicably redundant data direction pin, but still, I would not jump.

If speed is what's needed, there's a version of the uALFAT called the GHI3232 which is esentially a one file at a time logging chip - I have been able to get that to stream roughly 120k/second sustained using a dspic30f6013A.

The dosonchip might have a power advantage over the ualfat, so do keep that in mind - my application isn't really limted by power use at this stage, and I have 30 units working happily

[TheDirty]

I ended up just adapting the open source FatFS library to my microcontroller. Took a little while, but it was well worth it.

[samcheetah]

has anyone measured the maximum data throughput with firmware 2.0?

i have 4800 bits coming every second from a GPS module that i want to log on a micro-SD card. i plan to also log data from the IMU onboard the Sparkfun UAV dev board v2.

if Cannibal's 30k/sec is right, i think it would be okay for what i want to do.

what do you guys say?

[Cannibal]

if Cannibal's 30k/sec is right, i think it would be okay for what i want to do.

what do you guys say?

Cannibal can't remember if Canabal used the '60x' improvement figure from a credible source, or pulled it out of the air.

Cannibal recommends caution.