PDA

View Full Version : Propellor chip question



michaelw
09-11-2007, 11:01 AM
Hi there

I'm completely new to this forum, and pretty green with electronics in general tbh other than basic tinkering.

What I have in mind is a project to transfer data from a compact flash card to a IDE 2.5" hard disk to backup digital camera pics. Functionally can be very simple initially, but I may decide to expand and add a LCD viewer etc at a later stage.

My question is, what would be the approximate throughput for this chip? Lets say that each file is approx 8Mb each, approx 200 images per compact flash.

What kind of throughput could this chip manage? Would the disk & flash card be the bottleneck? Is a propeller chip overkill?

Btw yes, I know I probably have a lot to learn :) but any info is very, very appreciated. I think this would be a cool project to learn with.

Thanks
Mike

Peter Jakacki
09-11-2007, 01:33 PM
Do you mean compact flash or SD?

If it's SD then this:
The prop doesn't have an SD card interface or even fast SPI so you have to do it all in software. But the prop does have "the power of eight" so that you can be reading the SD card and writing to the IDE drive at the same time. If you really want the speed you probably have to go to 4-bit SD mode just to speed up the reading but you would still be lucky to get 4MB/sec read speed (at a quick guess). This translates into 400 seconds or over 6 minutes which might be a bit long, maybe you could get the prop to talk to you while it's doing it or even run the "singing monks" object :)

If it's Compact Flash then this:
too many I/O lines for the prop and no way to give you more fast I/O.

*Peter*

Harrison.
09-11-2007, 01:33 PM
It seems like michaelw is trying to use a compact flash card, which is very different from a SD card. CF cards use an interface that is very close, if not the same, as IDE which allows them to be used as solid state hard drives in IDE / PATA systems.

The issue here is that you will have to write your own software for accessing the devices and for controlling the file system. Wouldn't it be easier to just buy a bunch of cheap CF cards and worry about copying when you have access to a computer? IDE requires a lot of data lines so you would have to use some sort of io expander, which would get messy and would probably be slow.

Gadgetman
09-11-2007, 04:54 PM
This is one instance where I would advise against 'reinventing the wheel'.
Not only will you get problems with the control signals on the IDE interface(someone have experimented with Propeller and IDE using a I/O chip commonly found in older PCs, but it's slow going and it can be difficult to source the chip), but the Propeller won't be able to write very fast, and there's the mess of handling the file system, too...

Why not just get one of these:
http://www.thecus.com/products_over.php?cid=10&pid=7

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

michaelw
09-11-2007, 08:08 PM
Thanks for the info everyone :)

Yes, I said Compact Flash. There is a old project here that is similar, using a PIC16C64 and FPGA to transfer the data:

http://home.nikocity.de/andymon/hfg/Alya/alya.html

Why not just get a N1050 or similar? Well, I have a very specific application that I would like to build, and there is nothing similar available on the market.

Thanks again, sounds like I need to look for another processor.

regards
Mike

Lawson
09-11-2007, 10:27 PM
for something like this a small PC might be a good idea. de.kontron.com/index.php?id=82&cat=34 (http://de.kontron.com/index.php?id=82&cat=34) poped up on the top of a Google search for "dimm pc". Looks like it has a IDE interface onboard, and would probably boot Linux without too much pain. It's probably not cheap though. gumstix.com/store/catalog/product_info.php?products_id=167 (http://gumstix.com/store/catalog/product_info.php?products_id=167) has support for CF cards and probably has an IDE port somewhere. The Gumstix are ARM based with a Linux distribution.

Later

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?

deSilva
09-12-2007, 04:05 AM
I think there are many misunderstandings here... That a CF connector has 50 pins does not mean you MUST use all. Study this example e.g. www.edn-europe.com/isup2supcinterfaceconnectscompactflashcardtomicroc ontroller+article+231+Europe.html (http://www.edn-europe.com/isup2supcinterfaceconnectscompactflashcardtomicroc ontroller+article+231+Europe.html)

Microcontrollers are very well suited to access CF cards.. Why do you think they had been so popular some years ago? It was the easy interface!

michaelw
09-12-2007, 06:40 AM
Thanks again for the input

On further research, it seems a "Atmel AVR" might do the trick, coupled to a IDE driver, then to Compact Flash.

http://www.robs-projects.com/mp3proj/newplayer.html

(note the fat32 IO library - sounds cool)

Sparks-R-Fun
10-13-2007, 05:11 AM
I apologize for catching this thread rather late. However, could the original poster not have accomplished his end goal by using two Parallax Memory Stick Dataloggers (http://www.parallax.com/detail.asp?product_id=27937)? Even though the name says “Memory Stick” it seems like it should work fine with any USB connected mass storage device be it a compact flash card in a USB adaptor or a rotating hard drive with a USB adaptor. Is this not so?

- Sparks

Mike Green
10-13-2007, 05:35 AM
The CF interface is certainly possible with a Propeller. It's still very I/O pin intensive. You can use I/O expanders like in the EDN article, but this slows things down. You could also use several 8-bit latches to hold the current address and control information and that would require only 11-12 I/O pins and would slow down the transfers only a little. You should be able to get a megabyte per second transfer rate, probably faster. If you want to trade I/O pins for speed, you could use 3 or 4 74HC595 serial-out shift registers in series to hold the CF address, data, and control signals and a 74HC195 serial-in shift register to read the data lines. You might need a tri-state buffer too. I don't remember whether the 74HC595 has an output enable or not.