Slashdot Mirror
Most CF Cards Fail DMA Transfers
Anomalyst writes "In his quest to create an open source video camera, Andrey Filippov of elphel.com has determined that most Compact Flash devices, although claiming to be DMA capable, do not perform Direct Memory Access transfers correctly. This means successful movement of data to and from the device takes much more time with DMA disabled." The culprit appears to be the controller chip packaged with most of the CF cards Filippov tried. We last visited Elphel and their work on open source digital cameras in 2002. Filippov gave a Tech Talk at Google last year.
How do you know that it indeed works in a full-fledged UDMA mode and not in some half-assed workaround mode, used specifically because of the problems in question existing in the cards' controllers. Did you reverse engineer the camera's firmware?
It would not be possible to get the performance the camera gets if it did not use DMA mode. It may be that it uses 1K blocks like the article says they used for a workaround. The cards also work fine in UDMA capable external readers, otherwise I would be seeing a ton of messages in the camera forums I frequent. Sandisk and Lexar UDMA CF cards are frequently used with the new cameras that can support it and are widely used by professional photographers.
Also, the article said that the Sandisk card they tried worked. They did not mention anything about Lexar but did mention problems with Transcend, which is not certified for my camera.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
I'm guessing size is the main factor, according to Wiki SD has already maxed out at 32GB while CF has a theoretical max of 137GB. You need a lot of storage space for video.
I've been struggling with CF cards in embedded applications, and I can verify that they don't always comply with the interface specs. I've gone through at least a half-dozen different CF card brands, and all display some form of misbehavior if they're put on an IDE chain with another device. By themselves they work fine, but add a CD-ROM or a hard drive, and the system will fail with either bus timeouts or stalled transfers. My suspicion is that the CF card vendors are playing games with performance metrics in photography apps, and in those environments they can bend the spec because there's exactly zero chance of another device being installed on the interface.
As far as I can tell (without a bus analyzer,) there's something hinky happening during device auto-detection and initialization. Many times, the CF card will be detected as the Master device, but no Slave device will be detected. Swap to a different brand CF card, and the symptom will change - both devices will auto-detect, but the IDE bus will throw timeout errors during boot. Swapping in just about any not-a-CF-card device, and everything is fine.
In the article I was only describing CF working in "true IDE" mode, inside the cameras thy usually do not use it, so do not care much about the problem I've got. But it is important if you try to connect the camera with a simple adapter instead of the HDD
Two of the reasons wewrw already mentioned: 1 - I've got IDE interface "for free" in from the processor chip, just needed connector. 2 - CF cards are higher capacity. 3 - I can download CF and ATA specs from the Internet, while SD (when I checked it) was much more difficult to get.
I upgraded from onboard audio to an X-Fi Fatal1ty. My Kill to Death ratio went up by about 25% within a few days.
NEVER underestimate the power of.... Celebrity Endorsement !
Get the Fatal1ty mousepad to go up another percent.
music lover since 1969