Datalogging with uALFAT-TF and Hi2c
This Post is intended to demonstrate the application of uALFAT-TF for datalogging with PICAXE.
uALFAT information is available on the developers website;
http://www.ghielectronics.com/products.php
uALFAT supports serial, i2c and spi interfaces
GHI3232 supports serial and spi and is a specific optimised datalogging system
uALFAT and GHI3232 are alternative firmware that can be loaded on the same chip.
The advantage of GHI3232 is the software is simple with filename, write management including dataflush and closing, all automatic.
The disadvantage is that many pins are required for handshaking to allow the simplified software to work.
The main application of uALFAT appears to be supply of the core chip to OEMs and developers for including in products for sale.
GHI Electronics also supply OEM boards for USB and SD including their latest uALFAT-TF for microSD (or Transflash - TF).
Why uALFAT instead of VDrive2?
VDrive2 supports serial and spi only. Serial was not available in my application (being used for another device), and all my attempts to implement VDrive2 with HSPI failed.
The standard uALFAT firmware on the uALFAT-TF board is discussed here as there simply were not enough free I/O for GHI3232. The 'TF' board is the smallest (35mm x 26mm) and the cheapest US$39.95 for one and US$26.95 ea for 2, direct from the manufacturer.
uALFAT has a number of specific hardware and software requirements;
Hardware,
1. For USB, both 5V and 3,3v supplies are required.
2. For SD, 3.3v supply is required.
Software,
1. The card must be told each time it powers up which interface mode to set up in. There are no specific jumpers for this but some of the I/O lines can be tied high/low with pullup/down resistors to achieve this function, however the Reset line on the device must be toggled after it has powered up in order to set the interface mode.
2. All commands take the form of a single letter followed by a space then the parameter(s) then the CR/LF combo in the form of $0D.
3. All responses (and there is one for every command) take the form !xx where if xx is 00 then all is normal else the are a large number of different responses indicating the specific error.
If there is further informational data such as the number of bytes written to file, this is returned in the form $000000A1.
4. All commands and responses are in ASCII but this is not what you might expect.
for example to set the date/time in uALFAT (it has its own clock for date/time stamping the files) the date time has to be calculated in a specific format of a 32bit DWORD which is hex. e.g. the code for 07/12/25 23:59;00 (YY/MM/DD HH:MM:SS) is 3799BF60 but this must be sent as ASCII "3799BF60". Similarly the number of bytes to be written - say 19 which is hex13 must be sent as ASCII 13.
*5. SD devices do not detect datacard insertion/removal - must be handled via software response error checking.
*6. Does NOT handle i2c sequential reads - not really an issue for this application as only interested in error checking and have to test data as it arrives but could be an issue if large data reads required.
***but does support block read for data - The number of bytes to be read must be specified in the read command and it will read that many bytes, It always reports the actual number of bytes read so if there are insufficient bytes it reports the actual number read and pads the data returned to the number specified with 'Z" characters.
The error handler is separate you just pull all the data there is a byte at a time until there is no more (DATARDY line high if there is data to get)
Features of the following demonstration program;
Devices utilised are;
PICAXE 28X1 FW VA.0 (some issues with the ptr handling, resolved in FW A.2)
Maxim/Dallas DS1307 RTC
GHI Electronics' uALFAT-TF OEM board and AData 1Gb microSD card
1. Utilises an Input to handshake the DATARDY to control reading of all responses/datareads
2. Utilises an output to toggle the reset line to set up for i2c operation
3. Reads the RTC
4. Sets the uALFAT clock with the time from the DS1307. uALFAT has it's own clock which can have its own battery backup but as this application already has the DS1307 it seems preferable to have a single time base and set the uALFAT to match on power up.
5. Initialise file system, create files, write to files, flush data. Reads not required in this application but function is similar to write, and read functionality is demonstrated with error/response message handling.
6. File Names are created in the form YYMMDD_xxxx where xxxx is 0001 to 9999 and is sequentially increased each time a new file is opened on the same date and starts again from 0001 on each new date. Index number retained over power cycles.
7. Files are created in .CSV format.
8. Filename and column headers are written to each file when created.
9. Currently writes date and time as often as the demonstration program cycles, reading a new time from the DS1307 each cycle.
**9 writes per second with serTXD off and 28X1 at 8Mhz internal resonator with uALFAT error checking.
**18 writes per second with serTXD off and 28X1 at 16Mhz external resonator with uALFAT error checking.
10. Checking for errors and managing errors if they arise - response to errors to be developed.
11. Files are date/time stamped by uALFAT automatically in the standard FAT32 style (created, last modified etc)
Code in following post;
This Post is intended to demonstrate the application of uALFAT-TF for datalogging with PICAXE.
uALFAT information is available on the developers website;
http://www.ghielectronics.com/products.php
uALFAT supports serial, i2c and spi interfaces
GHI3232 supports serial and spi and is a specific optimised datalogging system
uALFAT and GHI3232 are alternative firmware that can be loaded on the same chip.
The advantage of GHI3232 is the software is simple with filename, write management including dataflush and closing, all automatic.
The disadvantage is that many pins are required for handshaking to allow the simplified software to work.
The main application of uALFAT appears to be supply of the core chip to OEMs and developers for including in products for sale.
GHI Electronics also supply OEM boards for USB and SD including their latest uALFAT-TF for microSD (or Transflash - TF).
Why uALFAT instead of VDrive2?
VDrive2 supports serial and spi only. Serial was not available in my application (being used for another device), and all my attempts to implement VDrive2 with HSPI failed.
The standard uALFAT firmware on the uALFAT-TF board is discussed here as there simply were not enough free I/O for GHI3232. The 'TF' board is the smallest (35mm x 26mm) and the cheapest US$39.95 for one and US$26.95 ea for 2, direct from the manufacturer.
uALFAT has a number of specific hardware and software requirements;
Hardware,
1. For USB, both 5V and 3,3v supplies are required.
2. For SD, 3.3v supply is required.
Software,
1. The card must be told each time it powers up which interface mode to set up in. There are no specific jumpers for this but some of the I/O lines can be tied high/low with pullup/down resistors to achieve this function, however the Reset line on the device must be toggled after it has powered up in order to set the interface mode.
2. All commands take the form of a single letter followed by a space then the parameter(s) then the CR/LF combo in the form of $0D.
3. All responses (and there is one for every command) take the form !xx where if xx is 00 then all is normal else the are a large number of different responses indicating the specific error.
If there is further informational data such as the number of bytes written to file, this is returned in the form $000000A1.
4. All commands and responses are in ASCII but this is not what you might expect.
for example to set the date/time in uALFAT (it has its own clock for date/time stamping the files) the date time has to be calculated in a specific format of a 32bit DWORD which is hex. e.g. the code for 07/12/25 23:59;00 (YY/MM/DD HH:MM:SS) is 3799BF60 but this must be sent as ASCII "3799BF60". Similarly the number of bytes to be written - say 19 which is hex13 must be sent as ASCII 13.
*5. SD devices do not detect datacard insertion/removal - must be handled via software response error checking.
*6. Does NOT handle i2c sequential reads - not really an issue for this application as only interested in error checking and have to test data as it arrives but could be an issue if large data reads required.
***but does support block read for data - The number of bytes to be read must be specified in the read command and it will read that many bytes, It always reports the actual number of bytes read so if there are insufficient bytes it reports the actual number read and pads the data returned to the number specified with 'Z" characters.
The error handler is separate you just pull all the data there is a byte at a time until there is no more (DATARDY line high if there is data to get)
Features of the following demonstration program;
Devices utilised are;
PICAXE 28X1 FW VA.0 (some issues with the ptr handling, resolved in FW A.2)
Maxim/Dallas DS1307 RTC
GHI Electronics' uALFAT-TF OEM board and AData 1Gb microSD card
1. Utilises an Input to handshake the DATARDY to control reading of all responses/datareads
2. Utilises an output to toggle the reset line to set up for i2c operation
3. Reads the RTC
4. Sets the uALFAT clock with the time from the DS1307. uALFAT has it's own clock which can have its own battery backup but as this application already has the DS1307 it seems preferable to have a single time base and set the uALFAT to match on power up.
5. Initialise file system, create files, write to files, flush data. Reads not required in this application but function is similar to write, and read functionality is demonstrated with error/response message handling.
6. File Names are created in the form YYMMDD_xxxx where xxxx is 0001 to 9999 and is sequentially increased each time a new file is opened on the same date and starts again from 0001 on each new date. Index number retained over power cycles.
7. Files are created in .CSV format.
8. Filename and column headers are written to each file when created.
9. Currently writes date and time as often as the demonstration program cycles, reading a new time from the DS1307 each cycle.
**9 writes per second with serTXD off and 28X1 at 8Mhz internal resonator with uALFAT error checking.
**18 writes per second with serTXD off and 28X1 at 16Mhz external resonator with uALFAT error checking.
10. Checking for errors and managing errors if they arise - response to errors to be developed.
11. Files are date/time stamped by uALFAT automatically in the standard FAT32 style (created, last modified etc)
Code in following post;
Last edited: