I2SDv3 - Arduino buckler with microSD

The Wyolum machine (these are the people who generously offered $3000 in innovation grants, with no strings attached) is forging ahead with a new and improved version of I2SD.
I just received their v3 prototype and it looks impressive. I must say it is the most feature-rich data logger / SD card backpack (here is the list of the competing products that I compared with).

Like its predecessor, I2SD v3 is a software-compatible Arduino (ATmega328/16MHz) with extras. It has on-board microSD card, DS3231 extremely accurate real-time-clock with backup battery, infrared receiver and 2 LED indicators for errors or status.

I2SDv3 comes assembled (all SMD), with the bootloader burnt in. Sketches can be uploaded through the FTDI connector.

The board can be plugged directly into Arduino, using one row of headers (A0-A4-GND-RST), hence the name "buckler" (like a "semi-shield", got it?)
I2SDv3 also offers header access to D4-D7 (v2 lacked that; my complaint was heard :), and it is compatible with the ChronoDot headers.

To test it, I decided to try the OpenLog library, by Nathan Seidle of Sparkfun. Surprisingly, it worked without a glitch from the first try. Well, kind of, I had to read the documentation :), and to change HardwareSerial.cpp, a "system file" (function SIGNAL(USART_RX_vect) is redefined in OpenLog.pde).

To emulate the OpenLog board closer, I changed the code to use D2 for the status LED, as shown:

from

#define STAT1  5 //On PORTD

int statled1 = 5;  //This is the normal status LED

to

#define STAT1  2 //On PORTD

int statled1 = 2;  // status LED on I2SDv3;

Note: The second LED of OpenLog board is connected to SCK (D13), so it blinks when the SD card is active (while reading or writing). The second LED on I2SDv3, being on D3, cannot be easily re-purposed.

Following OpenLog documentation, I connected to I2SDv3 using CoolTerm, typed in some text, pressed CtrlZ three times and voila!: file LOG0001.TXT got created and it contained the characters I typed in. Cool indeed.

Note: OpenLog won't compile with Arduino 1.0 IDE without some minor changes, as follows:
1. "WProgram.h" replaced everywhere with "Arduino.h"
2. function SdFile::write(uint8_t) must return size_t now (since it is virtual function defined in Stream.h); both SdFile.cpp and SdFat.h will need to be updated to reflect that.

Reminder: The OpenLog library should work with FAT32-formatted SD cards as well as FAT16. I will test it as soon as I get a 4GB microSD card.

WiseClock / BookClock with I2SD - part 2

As promised, I am returning with the sketch (download from here).



Justin and Wyolum Co. also promised (wink, wink) that the next revision of I2SD will have the needed digital pins accessible through headers.

This "mixed breed wise clock" is using the I2SD (with on-board RTC and SD card), the display (and idea) from Book Clock, and code borrowed and adapted from Wise Clock 2.

Missing are the user buttons and a tilt switch, which may be connected to the free A0/D15 - A3/D18 pins available on the header of the I2SD board. (Note: The buttons and the tilt switch should be also supported in software as well, code which can be copied from the existing Wise Clock 2 and Book Clock sketches.)

Duino644 software updates

I was close to giving up on SDuFAT library in favour of FAT16, but my one last attempt worked. I was trying to implement a feature suggested by fellow Arduino blogger BroHogan, to set up the clock using a file on the SD card. Since real time clock is set up quite rarely, this idea makes perfect sense.

Here is how it works:

• the user creates/copies the file "time.txt", which contains the time, formatted as HH:MM:SS, onto the SD card;
• after reset, if "time.txt" is found, the clock is set with the given (in the file) time;
• "time.txt" file is deleted, so the next reset won't find the file anymore;

It is always easier said than done.

Firstly, SDuFAT requires the file to have some characteristics, the most important being to contain a pseudo-EOF (0x03) character.

Secondly, the deletion of the file is not physical, the file does not disappear from the SD card, but it is rather modified so that its first character is the pseudo-EOF (0x03). The "deleted" file can be opened and its content read. The code decides that the file is "deleted" by checking the first character. How smart is that?

setRtcFromSDCard() shown below is the function that gets called in setup().

void setRtcFromSDcard()
{
numSectors = (int) SD.getSectors("time.txt");
if (numSectors == 0)
{
// try again;
delay(500);
numSectors = SD.getSectors("time.txt");
}

if (numSectors == 0)
{
#ifdef _DEBUG_
Serial.println("File time.txt not found.");
#endif

return;
}

// open file time.txt and read its content;
sectorContent = SD.readBytes("time.txt", 0);

// search for the time in the sector buffer;
boolean isTimeFound = false;
for (int i = 0; i<512; i++)
{
if (sectorContent[i] == 0x03)  // EOF
break;

for (int j=0; j<8; j++)
{
timeBuffer[j] = sectorContent[i+j];
}
if (timeBuffer[2] == ':' && timeBuffer[5] == ':')
{
// found the time;
isTimeFound = true;
break;
}
}

if (!isTimeFound)
{
#ifdef _DEBUG_
Serial.println("Could not find time (HH:MM:SS) in file time.txt");
#endif
return;
}

#ifdef _DEBUG_
Serial.print("Time from file is: ");
Serial.println(timeBuffer);
#endif

int hh = 10*(timeBuffer[0]-48) + (timeBuffer[1]-48);
int mm = 10*(timeBuffer[3]-48) + (timeBuffer[4]-48);
int ss = 10*(timeBuffer[6]-48) + (timeBuffer[7]-48);

#ifdef _DEBUG_
Serial.print("RTC time to be set to: ");
Serial.print(hh);
Serial.print(":");
Serial.print(mm);
Serial.print(":");
Serial.println(ss);
#endif

if (hh < 24 && mm < 60 && ss < 60)
{
setTime(hh, mm, ss);
SD.del("time.txt");
}
}

The other software change I made was also the contribution of BroHogan, who wrote (see reply #147) a few functions that perform "fast writes" to the LED display from Sure Electronics. Basically, the calls to digitalWrite() in ht1632_writebits() function have been replaced with calls to fWriteA(). This allows control over the speed of scrolling, ranging from fast to slow, rather than from slow to slower.

Brief comparison between SD card shields

Before I started the Wise4Sure project, which uses SD card, I did some research on a few SD card shields available commercially. This post is a summary of my findings.

I looked at three SD card shields: one from Libelium (US$28), one from Seeedstudio (US$15) and Wave shield from Adafruit (US$22, although this is more than an SD card shield).

The similarities are:

• all SD cards require 3.3V;
• all connect to the SPI port (pins 10-13);
• they all need a voltage divider (2 resistors x 3 signals) to adapt between the 5V level from Arduino and 3.3V level of the SD card;

These are the particularities:

• Libelium's small form factor shield comes assembled (SMD components) and tested, and includes a microSD card. It offers the nice feature of plugging the shield to either pins 8-13 (power is extracted from pin 8, set as high) or to the ICSP connector. It is not stackable (no more shields on top of it). It makes its own 3.3V from an onboard regulator.
• Seeedstudio's also small form factor comes assembled and tested. It accepts both SD and microSD, manually selectable through a switch. 3.3V comes from Arduino. It is also not stackable.
• Adafruit's Wave shield is a full size shield, designed to play wave files from the SD card. It comes as a kit, with through-hole components and clear assembling instructions. It has a powerful (100mA) 3.3V regulator on board and it is stackable. After interfacing with Wave shield, only pins 6 to 9 are left available for other use.

In my pre-prototype of Wise4Sure I used the Wave shield, since it was the only SD card shield I had. The integration went seemlessly, everything worked from the start.

When 2K is not enough

Good thing I started Wise4Sure as a "pre-prototype" (proof-of-concept). Imagine the frustration of things working weirdly with a prototype board, parts soldered maybe not perfectly, wires over wires, solder bridges and many other potential hardware issues. Then realize that the problems are really in the software, where 2KB of RAM is not enough, due to the SD card library (SHuFAT), which itself uses a half KB buffer to read a sector (see this post).

Based on the newly acquired facts, I decided that the prototype will use an ATmega644, the core of the sanguino. Here are a few technical specs:

• 4KB static RAM (that's the main reason I chose it);
• 64KB flash memory;
• 2KB EEPROM;
• completely through-hole.

Not many stores sell the sanguinos, nor the ATmega644, especially with the bootloader. I ordered mine from wulfden.org.

I already started building the board, and one of the first observations is that the distance between the two connectors (2x8-pin) on the back of the 0832 display module from Sure is not multiple of 0.1", as I expected. So my plan to use the connectors as plug-ins the "mother-board" is half ruined. I may need to use only one connector, which would confer less mechanical sturdiness, or have the "mother-board" un-attached mechanically, but connected through the short parallel cable that comes with the display. Both suck.

Related posts:

• Wise4Sure

Wise4Sure - Wise Clock with LED display from Sure Electronics

I was finally able to finish the "pre-prototype" of Wise4Sure, the version of Wise Clock that uses a 32x8 LED display from Sure Electronics. These LED matrices are single color (I have seen red, green and yellow so far), have a controller on board (Holtek1632) and can be bought for about US$10 (free shipping). Unbeatable. So, I could not resist the temptation of building Wise Clock around this display. Courtesy of Mr. Bill Westfield ("WestfW") who wrote the demo sketch (see here), displaying to the Sure LED matrix module becomes a trivial task. With a few small modifications (adaptations from the original 24x16 matrix to my 32x8), the sketch worked perfectly.

Another "improvement" is the introduction of the SD card. Previous versions of Wise Clock stored the text quotations in EEPROM, which had a few inconveniences:

- there was a limit of 32KB of storage;

- the process of loading the EEPROM was relatively complex and time consuming.

Replacing the EEPROM with an SD card solves these inconveniences and offers a few other advantages:

- quotations (or any message for that matter) can be changed/updated much easier, since it involves only the modification of a text file;

- quotations can be edited with a PC, directly on the SD card;

- there is no need to transfer the text, from a file on PC to Arduino, through serial port.

Integrating the SD card with Wise4Sure was the challenge. From h/w perspective, all SD solutions use the SPI (digital pins 10-13). As for the s/w, I opted for SDuFAT, from Arduino playground. It seems that this library is RAM hungry (I should mention that I did not look at the others, which may be as hungry). A big chunk of RAM, 512 bytes, is taken by the buffer that stores a sector after it is read from SD. (So, I assume that all other libraries should have this buffer as well).

After I eliminated some variables and functions which I did not use, everything (scrolling quotations) seemed to be working fine. Until I included the code for RTC (DS1307), when the returned time was consistently same bogus value. I narrowed the problem down to, again, memory (RAM) use. I adjusted my own text buffer a million times, until I got the RTC working. You may ask, as I did, what has the RTC got to do with the memory? Well, I can tell you, when the RAM is in "short supply", the time returned from RTC is just wrong (for example, "18:00" at all times). Keep in mind that RAM is consummed by the processor/program stack as well: the more functions are called, and the more parameters are passed, the more RAM is taken.

I said "pre-prototype" because, as SD card "shield", I used ladyada's Wave Shield. As for Arduino, I used my own Arduino clone, WiseDuino (just came up with the name, it used to be called Wise Clock, but this may lead to confusion). By the way, WiseDuino is now at revision 1.3 and the PCB is being manufactured by seeedstudio. I should be getting some boards soon and it seems that they will be also available for sale, under open source projects, from seeedstudio.com site.

In the end I got it working, so here it is in action (video).

The device is currently powered by 4 AA eneloop rechargeable batteries. The measured consumption is around 200 mA (as mentioned, using Wave Shield as SD card module). For practical purposes, this may require a wall wart power supply.

Next step is to build a real prototype, on perfboard, attached to the LED display board. Basically a whole Arduino, with an RTC and an SD card, with connectors for the LED display (pseudo) "shield".