Permalink
Browse files

v2.3 Migrated to v10.10.10 of sdfatlib. Moved to inline RX interrupt …

…and buffer. Improved the ability to receive a constant stream at 57600bps.

27334 bytes out of 30720.

Remember - we had to completely butcher HardwareSerial.cpp so a normal Arduino installation will not work.
C:\arduino-xxxx\hardware\arduino\cores\arduino\HardwareSerial.cpp

I removed the receive interrupt handler from HardwareSerial.cpp so that we can deal directly with USART_RX_vect in the main code. This allows us to return to the way OpenLog used to operate - by having one buffer split in half. Once one half fills, it is recorded to SD while the other half fills up. This dramatically decreases the time spent in function calls and SD recording, which leads to many fewer characters dropped.

The change log at the top of the main code got so large I've moved it to a version controlled "Changes.txt" file.

By making all these changes, I have broken many things. Ringp - I could use your help here. I apologize for stomping on so much of your work. I was not good enough to figure out how to re-link from the old function calls to the new sdfatlib setup.

Backspace is broken - ringp, I saw this fix in one of your commits, but looking at the code, I don't see how it is supposed to work. Either way, we still get 0x08 when trying to backspace.

Search for "//Error" in main pde
ls is not working fully
remove is not working
fileInfo is not working

New sdfatlib doesn't have SdFat.cpp so fileInfo doesn't work. These function calls are marked with //Error

I have chosen to dis-allow deprecated functions:
#define ALLOW_DEPRECATED_FUNCTIONS 0
This forced some trivial changes to the SD write and new file creation function calls. I believe we've successfully migrated to the new version of sdfatlib.

In the command_shell / read_line function : It may be better to pull directly from the UART buffer and use the RX interrupt. For now, we brute force it.

Because of all these changes, I need to re-test power consumption. For now, I'm confident it's low enough.

Testing with 512 buffer array size
1GB @ 57600 - dropped very little out of 3 tests
1GB @ 115200 - dropped very little out of 2 tests
8GB @ 57600 - Formatted using the sd formater (32k byte allocation size). Dropped nothing.
8GB @ 115200 - dropped very little, dropped none
16GB w/ Lots of files @ 57600 - Drops the first part of the file because of start up delay?
16GB w/ Lots of files @ 115200

1024 array size (and 800) does not run

Testing with 700 buffer array size
1GB @ 57600 - 110300 out of 111000 bytes, 110300/111000,
1GB @ 115200 - 111000/111000!, 109600/111000
8GB @ 57600 - 109000/111000, 111000/111000!,
8GB @ 115200 - 111000/111000!, 111000/111000!,
16GB w/ Lots of files @ 57600 - 85120/111000, 85120/111000
16GB w/ Lots of files @ 115200 - 56420 (but once it got going, log looks good). 56420.

I am seeing long delays on cards with lots of files. In the above tests, the 16GB test card is a good example. It has 2GB worth of random files in a sub directory. After OpenLog boots, goes to '12<'. After I send ~500 characters OpenLog freezes for a couple seconds, then returns to normal, very fast, operation. During that down time, I believe sdfatlib is searching for an open cluster. The odd thing is that after the cluster is established (after the initial down time) OpenLog performs excellently. I am hoping to create a faux file or pre-write and save to the file or some how get this allocation done before we report the '12<' indicating we are ready. That way, if a card does fill up, as long as the host system is checking for '<', it doesn't matter how long it takes sdfatlib to find the next free cluster.

You can see that we drop 700 bytes at a time. That's a bit odd - I'd expect to drop half or 350 at a time. What happens if we shrink the array size to say 256? To be expected, this is bad - way more instances of dropped characters.

Added blink for each test to the OpenLog_Test sketch so we can see as the test progresses.

http://www.sdcard.org/consumers/formatter/ is the site for SD card formatting. It looks like this program takes a guess at the correct block size. This could help a lot in the future.
  • Loading branch information...
1 parent 56b6dd7 commit 57890b6b133c20bbd88cd231bce966e183ba64fc @nseidle nseidle committed Oct 27, 2010
@@ -50,7 +50,7 @@ void setup()
void loop()
{
- int testAmt = 4;
+ int testAmt = 10;
//At 9600, testAmt of 4 takes about 1 minute, 10 takes about 3 minutes
//At 57600, testAmt of 10 takes about 1 minute, 40 takes about 5 minutes
//testAmt of 10 will push 111,000 characters/bytes. With header and footer strings, total is 111,052
@@ -73,6 +73,12 @@ void loop()
Serial.println(":abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ-!#");
//delay(50);
}
+
+ if(digitalRead(ledPin) == 0)
+ digitalWrite(ledPin, HIGH);
+ else
+ digitalWrite(ledPin, LOW);
+
}
}
Oops, something went wrong.

0 comments on commit 57890b6

Please sign in to comment.