Messages

Camera bus is limited to 167MB/sec (so are all CF cards used in MK III). That is plenty enough for 1080p24.

COuld it actually mean 50fps 1920x1080?

No. 24fps tops out at 93MB/sec. As max data rate for CF interface is 167MB/sec, you will never ever be able to record more than roughly 40fps in 1920p, no matter how fast storage you use.

There is a lot of dreaming on here... so I'm going to dream a little too!

The solution for this isn't going to be a simple CF to SSD adapter.  Someone needs to design a CF/SSD hybrid comprised of a CF card that has only a giant buffer memory that is then sent via some cable externally to an SSD.

The whole point is to get the fastest possible write speed to open up more features... like 3.6K recording.

Theoretical max speed is 167 MB/sec, no matter what you connect to CF slot. Thus, you can use any resolution ML supports, but if it doesn't fit in 167MB/sec (probably little lower), it won't work.

Filesystem is working again - I tried a MBR Partition instead of a GUID Partition Table but with no access. After configuring the parallel record option in canon firmware and restart the camera - there was no card1 error occured., When i hit record the cam was short peeping and something was on display i couldnt read (maybe a failure message in blue writing) because it was very fast upnaway..., Nothing get recorded...

Hi,

Do you hava PC? I would recommend following: Format a working CF card in camera, connect to computer and use a partitioning software (Partition Magic or similar) to copy complete partition from CF  to your HDD as-is.
Also,  avoid trying to record RAW to begin with (in case your HDD cannot swallow 90MB/sec).

Regards,

^ Yes, I know, but esskabel products are not easy to buy, and others are working on that front too. Right now, I'm just looking for "proof-of-concept" on a CF card reader.

I suppose camera checks the capabilities of CF card prior to connecting (in order to recognize older non-UDMA7-capable CF cards. If you can configure your adapter to PIO mode to begin with, it would eliminate one of potential problems during the tests.

No, just lots of patience, some ingenuity, and a couple of CF cards to trash. I know the most likely outcome is a useless adapter...

I strongly recommend using ribbon foil cable instead of discrete wires.

This one, together with custom made re-mapping PCB should do the trick:

http://en.esskabel.de/adapter/datasheet/ada-compactflash-extender-0430fpc-dma/77/

While ordinary flat-ribbon cable might work for PIO-mode, the signal speed is way too high for unshielded wires. The problems with recognizing the external drive might as well be camera not being able to communicate with drive at high speed.

I hooked all my parts together: SATA to mSata adapter (and SATA power connector from my computer), mSata to ZIF, ZIF to Toshiba CF, CF to USB3 CF card reader, Card reader to computer, and got nothing. The LED on the card reader lights up when powered up and a card is recognized, but it remained unlit. The orientation of the ZIF to CF cable wasn't obvious, so I tried it both ways (didn't seem to fry anything, but neither worked).

It'd be nice if I had devices that'd work with each element of the chain (i.e. something that takes an mSata connector, something that takes ZIF) so that I could find the weak link. I'm not sure where to go from here. It seemed like a possible route that might work using available hardware.

Try to start with simplest chain possible: female CF -> female IDE -> IDE HDD (formated as FAT32 and powered by external Molex cable).

if you want padded and aligned data, this means you will have a higher data rate.

(assuming you want it to be 16 bit aligned)

It would lead to more data being transferred internally, but it would also mean that CPU doesn't need to do unpacking of the primaries, right?

Instead of trying to catch this unicorn (see benchmarks), I'd say it's better to investigate how to enable 12-bit output directly from DIGIC.

You can select different raw types from c0f37014: denoised, with different byte order, compressed and so on. Some test code: http://www.magiclantern.fm/forum/index.php?topic=5614.msg39696#msg39696

This.

If we could make CMOS output shifted RAW data, then it would be much easier. It would be much easier even if it could output padded & aligned pixel data (so we don't have to "dig out" the RGB values from packed Bayer-data)., thus making it easier to shift diown to 10 bit in CPU

this is for ARM946E-S vs. ARM946E which we have

but i didnt verify

Ok! That's a pity

My understanding is that Canon licensed  basic ARM946E core and then added some of their ow stuff to it. do you know if there is any way to check for procedure/op -calls done from, for example H264 encoder? I bet it has $hitload of DSP/SIMD op's hardcoded on die in order to do real-time H264 encoding, some of those could be "re-used" for 4 x small int bitshift? (Or is raw data offloaded to buffer, to be handled by some sort of co-processor involved)

Pity "d" didn't make rawc.o ASM available. It would be very interesting to take a peek...

My suggestion:

-. Possibility of using dark-current substraction (take one raw pic with lens cover on, save and let raw2dng substract it from raw files. This will average out FPN and eventual pixel errors (as this is not being done by camera any more when using raw).

You mean... raw2dng feels kinda slow?

Ah, I didn't know which application this snippet of code belonged to. I just reacted when i saw the code

[count/2]

Modified reverse_bytes_order() for words instead of half-words in chdk-dng.c ,it's a bit better now.

Code Select Expand

static void FAST reverse_bytes_order(char* buf, int count)
{
long* buf32 = (long*) buf;
    int i;
    for (i = 0; i < count/4; i++)
    {
        long x = buf32[i];
buf[4*i+3] = x;
        buf[4*i+2] = x >> 8;
        buf[4*i+1] = x >> 16;
        buf[4*i] = x >>24;
    }
/*
    short* buf16 = (short*) buf;
    int i;
    for (i = 0; i < count/2; i++)
    {
        short x = buf16[i];
        buf[2*i+1] = x;
        buf[2*i] = x >> 8;
    }
*/
}

Will try this now.

Hi!


    for (i = 0; i < count/2; i++)

What about pre-calculating "count/2" into it's own variable and use that variable instead in your "for"-loop, otherwise it will waste precious CPU cycles evaluating "count/2" for each loop (giving same results over and over again)?

As far as i know the Digic 5+ is a modification of this core:
http://www.arm.com/products/processors/classic/arm9/arm946.php?tab=Specifications

Well as long as Arm 946 supports NEON, there is a neat quad-word SIMD shift instruction that is potentially able to do shift to 10 bits for one whole RGB pixel in one instruction:

http://infocenter.arm.com/help/topic/com.arm.doc.dui0489c/CIHEDCEG.html

In that case, there is even more speed to be gained. If not, we need to check into "Enhanced DSP instructions" which seems to be onboard on 946 for sure:
http://infocenter.arm.com/help/topic/com.arm.doc.dvi0022a/DVI0022A.pdf

For those trying this: the cheapest thing you can brick is, probably, a card reader. I only plan to put the thing inside a camera if I get it working there first.

Risk of bricking will be fairly low as long as you get CF <-> PATA leads right. You could start by trying to write to PATA HDD from old CF camera, using PIO mode (= no active SATA/PATA converter in-between). That would be quite safe

Good luck!

Are there any vector-ish OP's on this implementation of ARM that can do shifts on multiple 16-bit integers packed into 64 or 128-bit registers?

I got back a short mail from ESS kabel that they don't sell to private customers.
Also, my questions about which combinations of adapters/cables would fit went unanswered.

It's a pity really, they don't understand that they are missing potential market if it works.

I mailed them on 15th and they repled, that it is decontinued.

I'll try to call them, may be if there will be a substential interest say 100 pieces, they would be interested.

It should be in their interest that this works as we imagined. If it does, they might sell rather more than 100 pieces

P.S. I found a 500GB Seagate Barracuda PATA drive that woyuld be perfect for this. Only ATA-100 though, which means max 100MB/sec.

Has anyone suggested Compact Flash Ethernet Card?

Fastest speed is 100Mbit, which is a magnitude slower than needed for raw.

I read somewhere that EDMA can write 500 Mbps

Yes, but only way to write it to storage is through CF controller, and max controller speed is 167MB/sec (even if storage bandwidth is bigger). So maximum bitrate would be around 150MB/s realistically.

dashv:
Remember to format it to same file system as camera expects from CF
Also, most older CF cameras couldn't write to big CF cards. For example, 5D classic needed firmware update to use CF cards bigger than 4 (or was it 8?) GB. So start with small FAT32 or FAT16-partition.

Is the CF drive on the 5D MKII and III using memory mode or IDE?

If it uses IDE mode then an adapter like this:

http://www.esskabel.de/upload/files/pdf/ADA-COMPACTFLASH-ATA-IDE40_DE.pdf

Great find! That's the thing we are looking for! First test could be done towards IDE HDD w/o any electronics in-between.

P.S.
Re: CF-door microswith, I bet it could be solved the following way:

1. Cut a slit on CF-door with a Dremel tool.
2. Insert the CF-dummy
3. Pull the FPC ribbon cable through the slit
4. Close the CF door.
4. Connect the ribbon to whatever it needs to be connected to.

They say "minimum 5mm bending radii" so I huess you couldn't just let it go under the door.

Yep Grunf, I posted links to both versions but just used the photo from the basic version if you look

Yep I sent of a mail too, lets see whats happens, I like the idea of being able to close the 5D III flap I hope this works out, either way there is a little microswitch when the flap closes senses the card door shut if you push in this microswitch it lets you use the cards with the flap open if you hold it in, so you can use cards with the card door open.

That's great Peter! If anyone is able to provide correct cabling, I bet these guys will be the ones. Their stuff looks like real deal. All other CF breakout-boxes I've found on the net were either old-school thin-wire cables (that probably wouldn't be able to do 22ns signaling) or just vaporware.

I did some thinking. While ADA-FLEX-45P looks like exactly the thing we are looking for, it seems to be just a straight-through connector interface. Thus, the line mapping between CF and IDE (like seen here: http://pinouts.ru/DiskCables/ide2cf_cable_pinout.shtml ) is probably not implemented.

I believe that smarter solution would be to just crimp two female CF adapters on ribbon cable (as displayed on picture of 0430FPC-DMA), and then use any of readily-available bi-directional CF-to-PATA/SATA interface boards?

What do you think?

Regards,

P.S. As 5Dmk3 uses UDMA7, I think using ADA-COMPACTFLASH-EXTENDER-0430FPC-DMA would be better solution as it's printed two-ply cabling can support fast(er) clock speeds.