Simple test for uDrive

[MFB]

The following code (long-hand version with lots of comments) provides a quick way to test a uDrive and uSD card. The 5-pin uDrive module from 4D Systems provides a very compact and inexpensive way to exploit the huge amount of memory available on uSD cards. Only six serial commands are needed to communicate with the uDrive and it appears to be relatively easy to use.

However, my initial impression is that the uDrive is only suitable for a limited number of PICAXE based applications. For example, with only a PICAXE and uDrive connected to a 5 volt supply the current draw was in the order of 50mA whilst writing continuously and the data rate is quite slow using the single byte mode. It takes about six seconds to write 256 bytes at 9600 baud. The data rate could be significantly increased by using the uDrives 512-byte block mode. However, for my logging application, I can’t think of a simple way for the PICAXE to store and output 512 blocks of data to the uDrive, whilst sampling a number of ADC input channels at a constant rate?


'UDrive memory test for first 256 memory locations, using 40-X1 at 8MHz.


high 1 'Reset must start high
high 0 'Serial output must start high
pause 2000 'Allow drive to boot
serout 0, T9600_8,("U") 'Set drive baud rate
serin 7, T9600_8, b13 'Wait for ack or nak from drive

for b0 = 0 to 255
serout 0, T9600_8, ("@w",b0) 'Write test byte
serin 7, T9600_8, b13 'Wait for ack or nak from drive
next b0

low 1 'Start reset
pause 100 'Hold reset low
high 1 'End reset
pause 2000 'Reboots drive & resets address counter

b0 = 0 'Reset loop counter
serout 0, T4800_8,("U") 'Set drive baud rate
serin 7, T4800_8, b13 'Wait for ack or nak from drive


for b0 = 0 to 255
serout 0, T4800_8,("@r") 'Request data
serin 7, T4800_8, b1 'Read byte
if b1 <> b0 then Fail 'Check for error
next b0 'Next address location
sertxd ("Pass ",cr) 'Send pass message
end

Fail:
sertxd ("Fail at address ",#b0,": returned ",#b1,CR) 'Send error message

 

[MFB]

DataFlash anyone?

Having spent a bit more time on the uDrive I have reluctantly come to the conclusion that its relatively high current consumption and slow data rate (in single byte mode) would probably not make it a good choice for my logging application.

As I only need a few Mbytes (rather than the G bytes offered by SD cards) a product like the Atmel AT26DF321 DataFlash might be more suited. This low cost 8-pin device has an SPI bus and can store 4Mbytes. However, given that my favourite programming language is solder, it my take me some considerable time to develop the interface code!

 

[hippy]

This is always a problem; using what is tried and tested and people have experience with or using something which people have less or no experience with and requires more effort.

Someone somewhere has to put the effort, time and money into making something easily usable by others who don't have the time, experience of skills to do that themselves and people could argue all day about where responsibility or obligation to do that lies.

For those who want to do something but are held back from doing so there's no easy answer. It's either wait for someone else to make it possible, learn the skills needed to do it yourself, or accept compromise or less than best solutions, a situation we all face at many times during our lives.

 

[MFB]

Hippy. How very true.

 

[Dippy]

Blimey, I gave up my SD card controller when the uDrive became popular.
My PIC based design had a 512 byte buffer and would write that to SD in a blink or so.

I wish I hadn't dumped it now. Oh well.

hippy, you are abs right. Trying to please everyone is impossible even if you provide something that others couldn't do themselves.

 

[MFB]

I have been using four (maximum number possible) EEPROM chips to address 512k byte of I2C storage and they have been absolutely reliable at logging rates of hundreds of Hz, taking only a fraction of the power of the uDrive. If you only need 128K bytes, then the 24FC1025 chip is the way to go.

Unfortunately, the application now requires 1 Mbyte and I am considering using two banks of four EEPROM’s and switching them between a common I2C buses. Maxim application Note 1073 describes a method of connecting two devices, that share a common I2C address, by using a single MAX 325 analog multiplexer to switch the bus. However, this is a nine-chip compromise, compared with using a single DataFlash device. Needs must, and all that.

 

[hippy]

Simpler perhaps than analogue multiplexing multiple I2C buses is to use a 1-to-N decoder and connect each output to one of the A2/A1/A0 legs of the I2C Eeprom. For example 64 I2C Eeproms all wired, A2=0V, A1=0V, A0=active low output of a 1-to-64 decoder. Always address Eeprom at $A0 and only the one which is selected via the decoder will actually be at $A0, the rest will all be at $A2 and 'play dead'. If it's an active high 1-to-64, address $A2, all the rest will be at $A0.

What you are doing is moving the unused Eeproms out of the range being addressed rather than selecting through the Device Address. You can mix and match, so you can still have a bank of four contiguous Eeproms at $A0, $A2, $A4, $A6 and select which bank via decoder, and even drive A2/A1 or A1/A0 direct from PICAXE pins as well to save on size of decoder.

 

[MFB]

Hippy.
Your suggested approach does have the advantage of not having to fiddle with the I2C bus, which should reduce the possibility of introducing timing errors. Not a bad thing as I normally run the I2C clock at 1 MHz.
Thanks again.

 

[hippy]

I'll admit I haven't tried it but I'm convinced it should work. With A0/VDD to +V, A1/WP to 0V it should be pretty easy to route a number of Eeproms on strip-board.

 

[MFB]

Another possible way to address two banks of EEPROMs is by using a unique feature of the 24FC1025. The documentation about address pin A2 states “ This pin must be hard-wired to logical 1 state. Device will not operate with this pin left floating or held to logical 0”. If the function of A2 is much the same as standard address pin, it could be used to inhibit writes/read action.

It may therefore be possible to have two banks of four EPROM’s with identical addresses, with one bank of A2 pins driven directly from a ‘select’ control line and the A2 pins on the second bank driven via an inverter. It should be possible to address 1Mbyte with a single control line. I have not tried this yet but will get back with the results.

 

[MFB]

Not such a good idea

My attempt at using the A2 input to isolate one of two 24FC1025 EEPROM’s, that are operating at the same A0 and A1 addresses, was unsuccessful. When the Microchip documentation stated that the A2 pin must be held high for normal operation, they really meant it. It does not act like a standard address input but kills the bus completely when taken low (FF being returned from all memory chips).

Looks like I’ll be using the Microchip bus switching or Hippy’s address decoder approach after all.

 

[BCJKiwi]

I appreciate that I may seem like an evangelist on this topic but have you looked at the uAlfat-TF.

Good price compared to the UDrive, Serial, i2c, SPI interfaces, fast, uSD (TransFlash == TF) card, FAT File system etc etc.

It just works.

 

[MFB]

Yes, I remember quite a few good comments about the uAlfat-FT on past posts and will look at it as an option, but still wish I was smart enough to write interface code for a DataFlash chip.

 

[MFB]

Addressing 1Mbyte of EEPROM

I have tried switching the I2C bus between two banks of 24FC1025 EEPROMS using the method described in the following application note: www.maxim-ic.com/an1073

With both EEPROMS addressed at the same location it was possible to reliably write and read to them alternately, using i2cslow and an 8MHz PICAXE –28X1. Therefore, using eight memory chips and one MAX 325 multiplexer, it should be possible to address 1 Mbyte of EEPROM.

 

[jmumby]

Looks like 4d are inching closer to FAT support http://4d.websitetoolbox.com/post?id=3402498

 

[MFB]

They probably had the same type of calendar that Rev-Ed used when developing the X2!

 

[moxhamj]

Those udrive commands look fantastic. Clear and simple to use. I wonder when they will be released and/or whether you can reprogram an existing udrive to support the new commands?

 

[jmumby]

All the past updates have been free and upgraded via USB->RS232 converter. Considering the sell line was 'FAT support soon' one would hope it will be free also.

 

[moxhamj]

I tried logging into their support forum (applied as a new member) but it still says I can't post a reply. Maybe there is something wrong with their forum (no-one has posted a reply and the post by their admin was early April). Unless jmumby and myself are the only ones interested in the product! But I hope not, as it sounds nifty. I can see some simple software on a PC to handle the file read/write for instance. And maybe a little board to convert it to a standard D9 plug. Any clue as to when the new commands will be available?

 

[MFB]

Using scratch pad to write blocks?

The uDrive is potentially a good product but the two main limitations that I found are high power consumption and low speed when writing bytes. However, it may be possible to overcome both these issues by using the large X2 scratchpad to write 512 bytes at a time (uDrive block mode). Not sure how to implement it though, any suggestions?

 

[moxhamj]

I haven't used the x2 parts yet, but sure the scratchpad should work. For me, speedy is anything over 1200 baud. Power consumption - I wonder about disabling it when not in use, ie a switchable power supply using a transistor?

As an aside, has anyone ever got a SD card bit-banged with a picaxe using the 3 SPI lines plus /CS? SD cards (standard, mini and micro) are all very cheap nowdays. I've got source code in quite a number of languages (C, basic, assembly, propeller) but it seems very complicated and there seem to be lots of pitfalls. Probably too big to fit the code in an 08M but maybe in an 18x? I see there were some threads on SD cards back a couple of years ago, but maybe it ended up too complex. Or maybe there is some code out there (yay!).

But if not, udrive with FAT would be a very convenient way of using picaxe as a datalogger and then transferring the code onto a PC.

 

[SilentScreamer]

I wonder if SD cards will join the possible uses for a 20X2? I looked for code awhile back (I wouldn't know where to start with writing it myself) but found nothing unfortunately (except for the thread which deemed it too complex).

 

[moxhamj]

Maybe someone has some 3/4 written code for SD cards that they would be willing to share? Or at least point to where it got too hard and they gave up.

I'm reading through this product http://www.ghielectronics.com/product/102 and the documentation http://www.ghielectronics.com/downloads/uALFAT/uALFAT Manual.pdf which is a similar price to the udrive.

I guess one thing both these products highlight is how complicated SD cards are, and how a dedicated micro is needed to simplify the command set. The ualfat card can talk serial, but it can also talk SPI, which might seem a bit silly considering that SD cards also talk SPI, but the key is the simplification of the interface. The ualfat card uses commands that are simple enough you can type them in via hyperterminal or similar. So simple enough for a picaxe ?? even an 08M.

BCJKiwi seems our resident expert http://www.picaxeforum.co.uk/showthread.php?t=8513

 

[lanternfish]

Simpler perhaps than analogue multiplexing multiple I2C buses is to use a 1-to-N decoder and connect each output to one of the A2/A1/A0 legs of the I2C Eeprom. For example 64 I2C Eeproms all wired, A2=0V, A1=0V, A0=active low output of a 1-to-64 decoder. Always address Eeprom at $A0 and only the one which is selected via the decoder will actually be at $A0, the rest will all be at $A2 and 'play dead'. If it's an active high 1-to-64, address $A2, all the rest will be at $A0.

What you are doing is moving the unused Eeproms out of the range being addressed rather than selecting through the Device Address. You can mix and match, so you can still have a bank of four contiguous Eeproms at $A0, $A2, $A4, $A6 and select which bank via decoder, and even drive A2/A1 or A1/A0 direct from PICAXE pins as well to save on size of decoder.

And that has just provided a simple solution for an idea I have been working on. Thanks Hippy

 

[Marcwolf]

I have been using the UDrive in my animatronics experiments. Its a nice very small and simple to use module. I have a SD21 card (21 servo controller) and my UDrive is glues ontop of the SMD Pic chip to resude space.

FAT would be very nice as it means that syncronising the code between my UDrive and my PC would be a whole lot easier.

At the moment I am having to write to the UDrive using a USB-Serial convertor and sending the information byte by byte. With the FAT system I can just treat it as another drive.

Currently what I do is to treat the fitst 20 bytes on the drive as control bytes, then I have a block of 10 x 4 byte array. This correponds to commands and their starting point on the drive.
From there I can read in groups of bytes to set servo positions and additional control sequences. As no servo ever has a value of 255 - if the PicAxe sees that then its a control byte and the following byte has special significance.

Just my random musings :>

take care
Dave

 

[moxhamj]

4dsystems just sent me an email saying "The new PmmC for uDrive will be available soon which will support the FAT File functions. This will work for existing uDrives as well."

Hmm - simplicity and low power consumption. While standard SD cards are everywhere for cameras etc they do seem so very complicated to use. This topic came up last year in this thread http://www.picaxeforum.co.uk/showthread.php?p=79522 and MFB posted this interesting link http://www.emesystems.com/BS2flash.htm

This is the sort of code that looks small enough to get into an 08M.

That is a 512k chip and costs $1.40.

Then there is this little board for $9.90 which has 2 megabytes http://www.futurlec.com/Mini_FLASH.shtml and which looks to use very similar code.

Looking at the $1.40 chip http://www.futurlec.com/Memory/AT45DB041D-SU.shtml it uses 7mA when reading but 25uA when sleeping. It could be an option when you want more data than you can store in an eeprom, but less than an sd card (which might take more code than an 08M anyway).

So - how would you get the data out? I'm wondering about a little circuit that uses an 08M as a spi to serial converter. Run the picaxe 08M at 3.3V so it is directly compatible with the flash chip. Use a max3232 (the 3V version of a max232) to convert to RS232 levels.

Hmm - maybe a bit much for an 08M, as we need 4 lines to do the flash chip (maybe 6 with write protect and reset). Two for serial comms to a PC. Maybe a line or two to sample things. So perhaps something for a 14M?

But, consider a 14M sampling some data. It stores the data in flash ram. Every now and again it says "Hello" out of a serial out line (which is not connected to anything out in the field) and listens using pulsin for a reply. When you have finished datalogging, plug the board into a PC via the serial port, the PC sends back "Hi", pulsin registers something and then the 14M goes into serin for two way comms to the PC. This avoids the "serin hang" problem. Then some commands go back and forth to get the data out. The final command might be "go back to datalogging". Or just reset it.

Could this end up cheaper/lower power than other options?

 

[MFB]

Same old request

Dr_Acula. I certainly agree that it would be very useful to have the option of interfacing a few Mbytes of non-volatile storage to a PICAXE, which could be done using a single 8-pin AT25DF321 etc. User configurable low power/cost data logging could well be the ‘killer application’ for the new X2 range and I would have thought it well worth Rev-Eds time to develop the required interface software for the rest of us.

 

[moxhamj]

I might do some experiments with the 8 pin atmega chips and a picaxe tomorrow. Thanks to your link to that code, MFB, I'm hoping I might get something working fairly quickly as it looks straightforward. Famous last words a la Jeremy Clarkson; "how hard can it be??" One trick will be running the picaxe at 3V3 instead of 5V. But I have some 40109 chips for 3V to 5V and some 4050 chips for 5V to 3V so maybe we can do level translation. 3V3 seems to be the trendy new voltage. I'm not sure how the download circuit will handle a 3V3 supply - maybe some experimentation will be required.

Addit: New FAT software for the uDrive just released http://www.4dsystems.com.au/prod.php?id=22

 

[MFB]

You would be providing a really useful utility for anyone using a PICAXE for serious data logging and I really hope your development project is successful.

Regarding PICAXE operation at less than 5 volts, I have used 18X and 28X1 based circuitry reliably at 3.3 volts. This includes storing data on FRAM and EEPROM at I2C bus speeds of 1MHz.

Even communicating with a PC, whilst powered from a 3.3 volt supply, works reliably at speeds of up to 38.4bps. But I have only ever used laptop PC serial links for these tests, because they tend to use a +/- 5 volt version of RS-232.

Although the above tests are no guarantee of reliable operation, the results do indicate that running all components (rather than using level translators) from 3.3 volts should be acceptable for non-production designs.

 

[moxhamj]

Well, I put a post on the 4dsystems forum about FAT for the uDrive, and 20 minutes later they had uploaded all the new files and documentation. So I'm as happy as a pig in mud testing it all out. See their forum for the new commands http://4d.websitetoolbox.com/post?id=3402498&pid=33319664#post33319664
I haven't quite got it all working but it is very close.
I built a prototype and have been testing out the new commands. Looks simple enough for a picaxe. Maybe even an 08M.

But to simplify things, do it in stages. It is much easier to send data at high speed (38400 or more) rather than via a picaxe at 2400. I built a little uDrive to RS232 adaptor to test it via a PC. This also "robustifies" the uDrive - you can't plug it in the wrong way and zap it etc. Down the track I'll be plugging this into a 'robustified' picaxe on its own board, ie one with a RS232 connection as well. Which might seem a bit daft going picaxe <=>max232<=>max232<=>uDrive. But I am thinking it will simplify debugging.

This opens up some interesting possibiliites. Eg a picaxe logs some data and saves it into a standard .txt file on an sd card. Now, instead of downloading this data via a slow serial link, you just take the card out, pop it into an sd card reader and read it all off at USB speeds.

Another cool thing - you can read in and out huge data files in little tiny chunks. Just work out how many bytes at the beginning (up to 2^32), send that number, send how big the chunks are going to be, eg 10 bytes, and then start sending. This makes it very easy to interface with picaxe. You might read off 10 bytes, then send them to a display, then read another 10 etc.

 

[moxhamj]

Had to go to work for a bit. Back now at nearly midnight (Dr_Acula prefers to work at night...) I inadvertantly overwrote the file allocation table with the random read and writes, so the sd card needed a reformat. The steps are here http://4d.websitetoolbox.com/post?id=3402498&pid=33323611#post33323611

Everything works perfectly now. Fill the sd card up with some files, and you can read and write and dir and erase with simple commands that any picaxe can send.

So - 2Gb of storage on an 08M. I know the uDrive is a bit expensive at $29US, but it is so simple to use that if you factor in your hourly rate trying to write raw SPI code to access a sd card, this is well worth it.

Plus 4dsystems do seem very responsive. I am quite impressed that I posted a request for a timeline for FAT access and 23 minutes later they delivered it. Ok, it probably was almost ready, but I'm still very impressed.

There are several choices testing. You can build a little uDrive to RS232 adaptor like I did and use that to talk to a PC serial port. Or you can buy a $20 USB to serial adaptor from 4dsystems. Or you could talk to it via a picaxe with some simple picaxe code that just listens to a PC serial port, forwards the data to a uDrive, waits for a response and then sends it back to the PC. This latter would work but there are two opportunities for serin hang.

Or you could just start writing picaxe code knowing that this device does work as advertised.

I think the FatController software is worth playing with, because it gives a feel for the actual bytes sent and received when issuing commands.

The only one that might be a bit tricky with picaxe is the DIR command which dumps out the directory listing with no pauses. But if you have been writing to the board, presumably you know the names of the files you have been writing so a DIR might never be needed.

A random thought. I wonder if two picaxes could exchange a file via wireless? Maybe with a "mini xmodem" protocol that sends in chunks of 8 bytes instead of 128 bytes. Hmm, an 08M exchanging .jpg picture files?!

 

[moxhamj]

I've posted some vb.net code in the "completed projects" section. if you really stripped it down and just did one function, eg "write" and had a fixed file size etc, you might be able to get this into an 08M. But it probably is more realistic to get it into a bigger picaxe eg 18X and above.

Step 1 was getting it working with the supplied software.
Step 2 is getting it working with hand coded vb.net software (done now)
Step 3 is translating that vb.net basic into picaxe basic

I'm seeing some clever ways this can save codespace. Eg I've got an 18X with some code that prints lots of text messages. It would be easier to have one bit of code that prints out files, and store all the text on the sd card.

Mass transfer of data is extremely quick using a standard sd card reader/writer.

If you can get the data out quick enough (4800 baud is a bit slow for audio, but it works happily at 38400), you could store wavetable data. Convert your mp3 to a raw .wav file, and output sine waves, audio etc. So many possibilities!

 

[leftyretro]

Dr.

Thanks for the update. I bought the uDrive about 6 months ago and tested it out via my PC and a Max232 interface module. The basic commands worked fine and I put it away for future projects. Now I see that FAT16 is possible with this module if I upload the new firmware. I've downloaded all the files and will try to upload sometime later. Is the uploading of new firmware hard or tricky?

Thanks
Lefty

 

[moxhamj]

Yes mine was sitting on the back burner as well, but this FAT support makes the drive much more useful.

It was pretty easy to upload the new software. The hardest part was soldering up a little RS232 adaptor circuit. But you could do that a lot faster on a breadboard. The main issue I had was that it needed a clean reformat first as all the tinkering in Raw mode had put some bytes where they shouldn't have been.

Addit - I'm just reading through the 20X2 datasheet at the moment - it looks like you can run "external" programs off eeprom. I wonder if you can also write to those eeproms? Or run off other I2C devices, eg ram chips? Maybe you could move programs from a 2 Gig uDrive into an eeprom or ram chip and then run it from there? If so, then you would have a small computer, capable of having an operating system and running programs. Eg, DIR, ERA, COPY and run. Keyboard. LCD. Some intriguing possibilities there...

 

[hippy]

The X2's support running external programs from I2C Eeprom and it should be possible to use I2C Ram in its place if you can find such a thing of comparable size.

It should also be possible to take a downloaded I2C Eeprom 'slot', copy that elsewhere and restore it later. The main limitations would be in speed of transferring the data and wearing out the I2C Eeprom as code is being copied into it to later execute.

One can experiment now with a 28X2/40X2; download to external 'slot 4', download a program which copies 'slot 4' to 'slot 5', overwrite 'slot 4' and see if you can restore it from 'slot 5'.

 

[MFB]

FRAM buffer

Hippy, how about using I2C FRAM as a buffer. Much faster and more read/write cycles life than EEPROMs. I have been using the FM24CL256 (32Kbyte 8-pin chip from Ramtron) at bus speeds of 800KHz without having to add a write pause.

 

[hippy]

Yes, I imagine FRAM would work as it's a transparent drop-in replacement for I2C Eeprom.

 

[leftyretro]

Yes mine was sitting on the back burner as well, but this FAT support makes the drive much more useful.

It was pretty easy to upload the new software. The hardest part was soldering up a little RS232 adaptor circuit. But you could do that a lot faster on a breadboard. The main issue I had was that it needed a clean reformat first as all the tinkering in Raw mode had put some bytes where they shouldn't have been.

Addit - I'm just reading through the 20X2 datasheet at the moment - it looks like you can run "external" programs off eeprom. I wonder if you can also write to those eeproms? Or run off other I2C devices, eg ram chips? Maybe you could move programs from a 2 Gig uDrive into an eeprom or ram chip and then run it from there? If so, then you would have a small computer, capable of having an operating system and running programs. Eg, DIR, ERA, COPY and run. Keyboard. LCD. Some intriguing possibilities there...

Well I downloaded the new firmware and then formatted my card on the PC and put 10 small test test files in it. I was able to read the directory listing successfully from the module to a serial monitor program so I guess all is good. Looking over the commands it looks like you can still use it as a simple 512 block read/write module or as a simple (single root folder only) FAT16 drive. So all in all a nice upgrade and you can't complain about the free firmware update, lots of vendors would charge you for a upgrade of this significance.

So making a data logger has become a lot simpler now for this module, I highly recommend this module, it's been very stable in my limited testing of it and the documentation is first class.

Thanks again for the update tip.

Lefty

 

[moxhamj]

I've written an Instructable http://www.instructables.com/id/Simple-mass-storage-for-your-microcontroller-proje/

Lots of pictures and not too many words. Just for fun I tried writing a file with just 1 byte in it, and it worked fine.

Good news from Hippy et al re the new picaxes. I think we might start seeing some intriguing possibilities emerge. The uDrive can easily store everything written for CP/M from the mid 70's to the 1990s, so it could easily store libraries for every picaxe routine ever written.

A thought - where are the "programs" stored in the X2? Are they stored in internal eeprom or in ram? The uDrive can get programs in bite size chunks (eg 10 bytes at a time), so if you could poke those bytes somewhere, maybe an external I2C device is not needed? Hmm - that is speculating a bit given I don't have the full specs, but I can see some experimenting going on here that could have some intriguing outcomes.

 

[hippy]

The internal slots 0 through slot 3 are held in internal flash, but there's no way to access that memory directly to get the program out. You'd need to download to a slot in external I2C Eeprom/Fram and save that. Likewise you'd need I2C Eeprom/Fram to copy a program previously saved to uDrive back into.