Show Posts
Pages: 1 2 [3] 4 5 6
31  Forum 2005-2010 (read only) / Exhibition / Re: SD card read/write with Arduino on: February 09, 2009, 04:58:17 am
Hi

Reading from SD is a solved problem. The discussion happening here was to do with a specific problem sketch.

Charlie

32  Forum 2005-2010 (read only) / Exhibition / Re: SD card read/write with Arduino on: February 03, 2009, 05:08:26 pm
I've looked at the code and there are a couple of things that I'd like to go over with you - as they're application specific maybe you should PM me and we'll take it offline via email. We can post final findings but the interim comms might be a little noisy for this topic.

33  Forum 2005-2010 (read only) / Exhibition / Re: SD card read/write with Arduino on: February 03, 2009, 11:29:44 am
If I may I'd like to offer a couple of comments on the writer.

Having the write function which is used by the print() calls go through a general-purpose write function is less efficient than making things work the other way viz:

Code:
void SDWriter::write(uint8_t theByte)
{
  sector_buffer[buffer_pos]= theByte;
  ++buffer_pos;
  if(buffer_pos==512)
  {
    flush();
  }
}

void SDWriter::write(unsigned long val,int bytes)
{
  for(int b=bytes-1;b>=0;--b)
  {
    write((val>>(8*b)) & 0xff);
  }
}

This way the print calls all go through the minimal version.


34  Forum 2005-2010 (read only) / Exhibition / Re: SD card read/write with Arduino on: February 03, 2009, 07:59:33 am
It looks like SDWriter would just pop right on top there!

Great stuff. I'm thrilled that uFat is finding some use.

C
35  Forum 2005-2010 (read only) / Exhibition / Re: SD card read/write with Arduino on: February 03, 2009, 05:23:24 am
Here's a few general notes that I've been meaning to make for a while.

One thing to remember is that uFat simply overwrites data that is pre-allocated on the card. This needs to be a contiguous file else wierdness will ensue. One way to ensure this is to format the card before writing your proxy file to it. Deleting files from the card can leave holes in the FAT which your operating system will use next time a file is created on the card leading to a fragmented file.

Unfortunately resizing a file isn't a simple case of adjusting a value in the directory structure. It entails re-linking the FAT table chains, which means a lot more code in uFat, which is counter to its design criteria. I think it's a reasonable trade-off. Actually, thinking about it, if people were happy with yet another trade off then we might be able to come up with a small extension that can work with one or two files on a card and set their lengths in a one-off manner... But I digress.

The length of the file indicated in the directory is the raw size of the original proxy file, not the number of bytes you've written. Its size remains constant no matter how you write to the space it occupies.

If you write binary data to the file then you'll no doubt have a client application that understands it.

If you write ascii data then things are a little (but only a tiny bit) harder. When the file is written to and later removed to the computer and viewed in a text editor, there may well be a warning that the file is corrupt (at best) to a refusal to load it at all (at worst). This is to do with non-ascii ranged bytes in the file, as explained in a previous post. Warnings can be ignored on the whole. It's best practice to empty the buffer before writing data to it. You could fill it with character 0x20 (ascii for 'space') but that would mean a bloated file when editing. You could fill with 0x0d (carriage returns), which might be better. I'd go with 0 myself, unless it was making editing hard.

Thoughts encouraged.
C
36  Forum 2005-2010 (read only) / Exhibition / Re: SD card read/write with Arduino on: February 03, 2009, 04:53:21 am
I think the way to go is to use the code already present in the libraries. Check out .\hardware\cores\arduino\Print.cpp

This base class provides the 'printing' functionality. Since you're already wearing the cost of the code whenever you use the Serial library it can be used virtually free. All you need to do is provide a subclass which provides a write byte function which puts a byte to the MMC buffer and writes the sector when necessary.

What you get is the ability to write strings using the exact same functions as you'd use for Serial! How cool is that.

As a super bonus, you could interchangeably use the MMC output with the Serial output for testing..

Here's how. (Please forgive typos, I'm away from arduino right now so I can't test)

Code:
class MMCWriter : public Print
{
  public:
    void begin( .. )
    {
       // initialise the mmc byte-by-byte writer here
    }

    void flush(void)
    {
       // flush the buffer to the card here
    }

    virtual void write(uint8_t theByte)
    {
       // call the function that puts a byte in the buffer here
    }
};

MMCWriter MMCio;

void setup(void)
{
  MMCio.begin();
  MMCio.println("Hello! This string will go to the buffer!");
  MMCio.println(123, DEC);
  MMCio.flush();
}
That's it. I'll leave the serial/mmc swaperoo trick for another post (or you could work it out if you've got 5 mins).

There's a huge amount of power in the arduino core - take some time to have an explore and who knows what you might find smiley

C
37  Forum 2005-2010 (read only) / Exhibition / Re: SD card read/write with Arduino on: February 02, 2009, 03:41:37 pm
Howdy

Thanks for posting the code - it helps everyone in the end. I realise it can be a bit like exposing your very soul but we're all in this together.

I have a few questions. Do you only want to collect the last 50 or so readings or would you prefer to keep a rolling record?

When you dump the data do you just want to see the currently buffered entries or all of the data on the card or would you prefer to be able to say 'last 10 entries' or similar?

From reading the code I can't quite make out what your requirements are. Do you think you could write a few paragraphs about this? Try and be condescendingly pedantic smiley

One thing you could consider is trading code volume for end-result readability. Specifying that you require the data file to be human-readable might add an up-front code cost but could give you huge benefits...

C
38  Forum 2005-2010 (read only) / Exhibition / Re: SD card read/write with Arduino on: January 30, 2009, 05:05:27 am
Hi JB.

The line:

if (RES_OK == mmc::writeSectors(sector_buffer, sector, 1))

writes 1 sector's worth of data stored at sector_buffer in the arduino's SRAM to the specified sector on the card. Once this routine returns your data is stored. The line:

digitalWrite(13, (millis() / 1000) & 1)

has nothing to do with the workings of the program. It simply flashes the LED on port 13 to let you know all's done.

All reads and writes in uFat are 512 bytes. This is the size of a sector on the card. It would be possible to write a function that allows arbitrarily-sized writes but that would add to the size.

Do you only want to ever have 10 bytes stored? Or are you saving a stream? When you want to read it back would you be showing all the data stored thus far? What's the expected data rate? If it's a slow dribble of data to the card that would warrant a different approach than if you're going for realish-time.

If you can describe your program requirements I'll see wht I can do to help you out.

There's no obvious reason why uFat should interfere with your RTC. It sounds like you're using 2wire for the clock. I have a board that uses I2C components simultaneously with hardware SPI without a problem, I may need to look over your code.

Charlie
39  Forum 2005-2010 (read only) / Exhibition / Re: SD card read/write with Arduino on: June 26, 2008, 04:23:54 pm
You could also use my uFat library.

It's a kind of halfway-house solution between a full-fat and a fat-free solution. (Sorry couldn't resist it.) Basically you get to read and write sectors within files that you pre-allocate on a PC.

It's a really simple interface. 1. Get the base sector for a named file on the card. 2. Use it!

Naturally there's a couple of minor restrictions, but that's how trade-offs work, right smiley-wink

Read more about uFat here: http://arduinonut.blogspot.com/2008/04/ufat.html

I'll be happy to help with any queries. PM or mail me.

Charlie
40  Forum 2005-2010 (read only) / Exhibition / Re: SD/MMC From the ground up on: May 13, 2009, 04:29:42 am
I haven't used filelogger, I suspect it utilises FAT 'properly'. The trade-off is speed and sketch size. It requires far more grunt to navigate the file allocation tables and ensure a consistent file system.

Perhaps people could post of their experiences?

C
41  Forum 2005-2010 (read only) / Exhibition / Re: SD/MMC From the ground up on: May 11, 2009, 02:06:02 pm
Here you go:

http://micro-hacker.googlegroups.com/web/DevicePrintDemo.zip

It's not a great demo, but it shows everything you need.

I really should update it  smiley-grin
42  Forum 2005-2010 (read only) / Exhibition / Re: SD/MMC From the ground up on: May 11, 2009, 11:50:56 am
Hiya,

We only read from PROGMEM, your impressions are correct. The data is written to an intermediate buffer in SRAM and then to the card.

The advantages of storing your constant data in PROGMEM is that it leaves the RAM free for things that RAM does best.

C



43  Forum 2005-2010 (read only) / Exhibition / Re: SD/MMC From the ground up on: May 07, 2009, 04:06:31 am
Here's some code that will print a directory listing of files on the card.

Note: it relies on the PROGMEM print routine available in the device print demo sketch

Add this first clip to the code at some point after the mmc and uFat initialisation:

Code:
 int count = 0;
  print_P(PSTR("Directory of files on card:\n\n"));

  microfat2::walkDirectory(showDirectory_walkerfn, &count);

  print_P(PSTR("\n"));
  Serial.print(count, DEC);
  print_P(PSTR(" files found.\n\n"));

Then add this subroutine to the sketch somewhere above the setup() function:

Code:
bool showDirectory_walkerfn(directory_entry_t* directory_entry_data, unsigned index, void* user_data)
{
  int* count = (int*)user_data;

  Serial.print(index, DEC);
  Serial.print(' ');

  // Terminate the filename string.  
  // This is deliberately corrupting the buffer data, but that's ok.
  directory_entry_data->filespec[11] = 0;

  Serial.println(directory_entry_data->filespec);

  // Increase 'seen file' count
  *count = (*count)+1;

  // don't stop
  return false;
}

Your reward will be a list of the files which uFat is able to see. This should help in the cases where mmc & uFat initialisation succeeds, but nothing is found on the card. Note: the directory walker loop excludes deleted files, directories and files with long names.

Enjoy!
 smiley-grin

44  Forum 2005-2010 (read only) / Exhibition / Re: SD/MMC From the ground up on: May 06, 2009, 02:26:21 am
Hi all,

@Pakrat - You have just highlighted one more problem that had just clean slipped my mind! I've been struggling with this one. You are right - if you have windows set to hide known extensions, it goes ahead and adds them for you without asking.

Viz. If you save a file in notepad and add the .txt extension to the name, windows internally adds another meaning the file is called 'data.txt.txt'! The sketch won't be able to find this.

Thanks Pakrat  8-)

@J_T - You might want to check if 'Hide extensions for known filetypes' is checked in the folder options.

Open an explorer window and select the menu item Tools -> Folder Options. From there locate the option and check if it's checked.

Let us know!

I'll add code to print a directory of the card, this will add a new level of diagnostic.

45  Forum 2005-2010 (read only) / Exhibition / Re: SD/MMC From the ground up on: April 26, 2009, 01:23:36 am
I rarely use SD cards, and I wouldn't have thought twice about the /WP signal!

Thanks for posting this!

C
Pages: 1 2 [3] 4 5 6