Any uDrive feedback?

M

MFB

Senior Member
Some weeks ago Jmumby and murrayj both posted links to a micro SD card interface module that could be used with a choice of serial interfaces. The uDrive is now available from Sparkfun Electronics
( www.sparkfun.com/commerce/advanced_search_result.php?keywords=udrive ) for about £19 plus P&P. Although FAT 16/32 is not currently supported, the manufacturer expects to offer this option ‘real soon’.

Has anyone tried interfacing the uDrive to a PICAXE yet?
 
B

BCJKiwi

Senior Member
Why not use the uALFAT system.

Proven application on PICAXE, has i2c, spi, serial interfaces, comes in models for USB, SD and MicroSD.

Supports Fat 16/32, long filenames etc.

Have one of these running successfully with i2c.

See discussion, code etc here;
http://www.picaxeforum.co.uk/showthread.php?t=8513

There are a number of these devices coming onto the market but the critical areas are a bulletproof implementation of the FAT file system, and, a reliable interface.
After abortive attempts to use VDrive2 on spi, found uALFAT to be a breeze and completely reliable with i2c.

I would not be comfortable with an unfinished product promising part of the FAT file system 'real soon'.
 
Last edited:
J

jmumby

Senior Member
Well, I have been a bit slack. I've been getting the Rs232-> wifi and GPS working on my project and uDrive was next. I do have one but hanging out for FAT support.

The support forum said that FAT would be available in the next several weeks - that sounds like a long time.

However, the wifi and gps are working so this weekend I will have crack at the uDrive and report back.
 
M

MFB

Senior Member
BCJKiwi, thanks for reminding me about your uALFAT posting and very informative code example. Although this is a relatively mature product, it is also about 50% larger than the uDrive, and my application is very demanding on both size and weight. Also, not being able to read the card directly in a PC (serial I/O access only) is not a showstopper.

It seems that a couple of members are near to trying the uDrive and I am sure many of us look forward to hearing their comments, as the PICAXE could really benefit from having a definitive low cost mass-storage interface.
 
B

BCJKiwi

Senior Member
I am a little puzzeld here.

I'm not sure what is meant by "not being able to read the card directly in a PC". The uALFAT-TF, while not as small as the uDrive is not exactly large! The TF, or microSD is directly readable in a PC as it is for the uDrive, or am I missing something?
 
Last edited:
B

BCJKiwi

Senior Member
I got the point that the uDrive was not fat compatible from Post #1 and assumed that post #5 referred to the uALFAT.
uALFAT has the best FAT file system of any of this category of product as far as I can tell with full FAt16/32 support.

The uDrive certainly has a cunning layout halving the size by placing the TF socket on the back of the board.

It just seems that an awful lot of function is being sacrificed for that space gain but I guess it all depends on the application.
 
Last edited:
M

MFB

Senior Member
BCJKiwi,
I was referring to the uDrive not being PC compatible, having read only good reviews about the uALFAT. Which it may indeed have the best FAT implementation around. However, weight and size are very important parameters (the application is a micro air vehicle logger) and I really would like to use the uDrive with the PICAXE if possible.

In this application the uSD card would only be used as a kind of simple ‘cassette tape’ replacement, with data always being recorded and replayed sequentially. No need for a random access filing system. As I am sure many PICAXE users also have modest (non-FAT)mass-storage requirements, it would be good to get some feedback about the small and cheapy uDrive.
 
B

BCJKiwi

Senior Member
MFB, thanks for the clarification. As noted - it all depends on the application.

I guess I probably come across as a uALFAT evangelist, nothing could be further from the truth, it's just that one sees the same questions come up time and again on the forum and often the answers end up being the same each time.

Of course if you are really keen, the uALFAT core chip is available separately so if you have to build a board anyway and are comfortable with smd you could build the SD support right onto your own board ;-)
 
M

MFB

Senior Member
BCJKiwi, I did consider using the uALFAT core chip to save space but decided that the pcb layout effort was not worth it for a few-off and the uDrive also ‘seems’ much simpler to interface.

Even the lack of direct PC compatibility is less of a problem than I had first thought. Because a serial card reader can be easily and cheaply implemented using a second uDrive. uSD cards could then be removed from the logger and plugged into this PC compatible reader, to directly import data to Excel using a macro like SelmaDAQ.

I have already convinced myself to buy a uDrive to play with but would of course still welcome comments from other users.
 
B

BCJKiwi

Senior Member
I'm confused.
The primary reason I use the uALFAT-TF instead of an eeprom on the project is so that I can pull the card and plug it straight into the PC - what's with the serial reader?
I have one of those NZ$12 usb to 23-in-1 card readers permanently connected to the desktop PC. If you have a modern notebook these are already built in. This is the same thing I use for photos from the digital camera etc.

Sounds like you need to get that uDrive to check it out. I'm sure we'd all like to know how it goes!
 
Last edited:
M

MFB

Senior Member
BCJKiwi,

Sorry, but I do have a habit of causing confusion.

Good point about the EEPROM option. I have used I2C FRAM in the past but they only go up to 64K x 8. It might be possible to get the required write times (2Kbytes/sec) using EEPROM. For example, the 1MHz Microchip 24FC1025 is a 1024K x 8 memory. It is possible to use four of these 8-pin devices to give 512K bytes total storage on the same I2C bus!

The only reason that I have not taken this route is that addressing more than 64Kbytes from the PICAXE I2C port looks (to me anyway) rather complicated.
 
J

jmumby

Senior Member
Hello,

Very belated reply I'm afraid if you have been reading my other posts you may know why. Anyhue my first uDrive experience.

Code: 
#terminal 19200

setfreq em16
SYMBOL RESET_PIN = 6
SYMBOL uDrive_TX = 7
SYMBOL uDrive_RX = 0

serout uDrive_TX,t9600_16,("") ' send out anything to "initialize" serial 
START:
LOW RESET_PIN
WAIT 20
HIGH RESET_PIN
WAIT 20

sertxd ("sending init",CR,LF)						'echo send init
serout uDrive_TX,T9600_16,("U")					'send U
b1="1"									'Set error point
SERIN [3000,failed],uDrive_RX,T9600_16,(0x06)			'wait for ACK

sertxd ("set address",cr,lf)						'echo Set Addres
serout uDrive_TX,T9600_16,(0x40,0x41,0x00,0x00,0x00,0x00)	'send address
b1="2"									'set error point
SERIN [3000,failed],uDrive_RX,T9600_16,b0				'Wait for ACK

sertxd ("write byte",cr,lf)						'echo Write Byte
serout uDrive_TX,T9600_16,(0x40,0x77,"b")				'send command and byte
b1="3"									'set error point
SERIN [3000,failed],uDrive_RX,T9600_16,(0x06)			'wait for ack

sertxd ("read byte",cr,lf)						'echo Read Byte
serout uDrive_TX,T9600_16,(0x40,0x72)				'send read
b1="4"									'set error point
serin 0,T9600_16,b3							'receive byte
sertxd ("b3=",b3)								'echo byte

end

failed:
sertxd("failed step",b1,cr,lf)					'echo fail and error point
end
For 28x1 I have to hold the uDrive in reset until the 28x1 sends it's first byte otherwise it gets confused when initializing because the 28x1 sends a 0x00 0x0D first rather than a 0x55. This code writes a "b" to location 0x00 0x00x 0x00 0x00 and reads it back. You can write byte wise or in chucks of 512. Datagrams smaller than 512 bytes must be padded to make up the 512bytes. I am running 5v with 150ohm resister on the uDrive RX and a 10k pull up. I have run this at 3.3v and get the same result.

There is a bug in the first version of firmware where you cannot write byte wise past 512b but you can check the 4D site about that.

Raining tomorrow so may have more info as the day goes on.
 
Last edited:
M

MFB

Senior Member
jmumby, Your contribution is just the kind of useful hands-on information that sets this forum apart from many others that mostly swap opinions and homely anecdotes about micros. Many thanks.
 
J

jmumby

Senior Member
No problem MFB I try to treat the forum as well as I would like the forum to treat me.....does that make sense.

Using AiTerm the drive keeps sending out 0x00 constantly after reset and power up. When I send a byte the ACK is being partially corrupted by this 0x00 that keeps coming out. If I send another U (to initialize) I get the correct ACK. Bit OT but does anyone know why this would be sending out 0x00 all the time? Noise perhaps? Poor power supply? I have it running of a 5volt reg and a pull up on the rx put one on the tx out of desperation but that stopped things completely.
 
M

MFB

Senior Member
Unfortunately I can't start playing with the uDrive, because SparkFun are out of stock until early April. Might be able to look into some of the issue you mention after that date.
 
J

jmumby

Senior Member
The problem seems to be the speed of the uDrive to respond with the ACK. At 2400 Baud the drive works flawlessly (except for the 512b problem). At 9600 baud I get 0xF0 and at 19k2 I get nothing what so ever. I think this is because switching from serout to serin takes too long on the picaxe and by the time serin has started the ACK is halfway sent for 9600 and sent well before for 19k2.

I have asked them to see if they can change the ACK response for slower processors. Using hardware serin would probably fix this but I have already allocated this to another resource.
 
M

MFB

Senior Member
jmumby,
Does the PICAXE really have to receive an ACK from the uDrive before transmitting the next block? In the case of a simple data logger, it might be possible just to include a sufficient delay between blocks and assume that an ACK was received (some applications could tolerate the odd missing block). Much would depend on how often a write error might accrue and, whether the uDrive hangs under this condition or continues and waits for the next incoming block. The best solution would of course be for 4D Systems to find a way to accommodate slow microcontrollers, as you suggest. After all, they mention using it with the Basic Stamp quite a bit in their literature.
 
J

jmumby

Senior Member
OK uDrive round up.

I have only played with byte wise writes as 512bytes is a lot of data at 2400 baud.

Code: 
SYMBOL RESET_PIN = 6
SYMBOL uDrive_TX = 7
SYMBOL uDrive_RX = 0
SYMBOL uDrive_Baud = T2400_16

'SET ADDRESS
SEROUT uDrive_TX,uDrive_Baud,(0x40,0x41,0x00,0x00,0x00,0x00)
' WAIT FOR ACK (remove for speeds above 2400)
SERIN [3000,ERROR],uDrive_RX,uDRIVE_BAUD,(0x06)  

'WRITE BYTE B1
SEROUT uDrive_TX,uDRIVE_BAUD,(0x40,0x77,B1)
' WAIT FOR ACK
SERIN [3000,ERROR],uDrive_RX,uDRIVE_BAUD,(0x06)

'READ BYTE IN B3 (no ACK)
SEROUT uDrive_TX,uDrive_Baud,(0x40,0x72)
SERIN uDrive_RX,uDrive_Baud,b3
For me at least I will always being writing from byte zero till the card is full so technically I wouldn't need to put in an address as the default location is 0x00 0x00 0x00 0x00. I will not have to put an address in again once it starts as the pointer auto increments for each byte.

The address ACK is the only command that I have used that is too fast for the picaxe so I just ignore the ACK and if the write fails that pretty much tells me that there is a problem.

My whitehat logging takes about 60 bytes a hit and probably 60mb is available on a 64mb uSD card so I will be able to log about 1,000,000 (16 million with the 1 gig card I thought I needed) access points albeit some will be duplicates I probably need to work out a method of the picaxe retaining the 8 byte address so it will start where it left off.

Oh and to save you 30 bucks the PMMC loader software does not need the the proprietary FTDI adapter as a MAX232 hooked up to a computer serial port does the same job.

Aside from the address ACK this is a pretty cool little device.
 
You must log in or register to reply here.
Top