Electronics > Projects, Designs, and Technical Stuff

Help request to finish coding a Kodak DCS (first commercial DSLR) storage unit.

(1/5) > >>

pieroc91:
Hi everyone!

TL;DR: I have a DueProLogic FPGA board based on a Altera Cyclone 4, at the moment i've coded enough to command the camera to stream the sensor data in parallel 8bits at 6mhz and with the appropriate clock signal i can read it back and dump it on some LEDs. Now my coding skill reached the end and i need help to store or transfer that data.

TL;RA (Too Long Read Anyway):

I'll start with a little bit of story. Back on 2018 i got a Kodak DCS, the very first commercial DSLR and made on a small run it is one very important item that shaped today's life, it paved the way for every digital camera we have, the one on top of your display or the back of your phone too. The one I got was incomplete and in very rough shape, most importantly the DSU (Digital Storage Unit) which contains most of the logic was missing.
On a quick googling session I came across the schematics and original source code from it, Jim McGarvey, which was the lead engineer of the design took care to put online a lot of resources from the camera. Having all this I came with the idea of replacing all that bulk of PLDs and ancient storage technology with something more modern, in that moment I though of an arduino.
Not understanding much of what I was doing I sent an e-mail to Jim McGarvey itself telling him about my idea, few days later, to my surprise, Jim answered my e-mail, he told me he had the same idea but I will need an FPGA since timing was a critical thing and even more surprising he sent me an scan of an original hand written paper defining the communication protocol between the winder (the part I have) and the DSU, that was more than enough motivation to still be here 5 years later keeping up with it.

I originally started posting about the project over here https://www.nikonweb.com/forum/viewtopic.php?t=841 .
The progress and the excitement are clearly visible on the posts, I got farther than I would've ever imagined and even got to fully control the camera and transmit a few light sensitive bytes, but giving my almost null knowledge about high level coding interfacing an SD card or negotiating with a PC is really far from what I can accomplish, still I feel the project stopped very close to the point where results can be seen.

So well, here's the actual moment, I've travelled back and reunited with all the parts, tested it and works exactly as the day I stored it and since I got some time to test I'm reaching the community looking for someone interested in this project

I really appreciate any comment on the subject, even if you can't help, a thumbs up is good enough for me so thanks to everyone reading this and I hope we can throw some life on the DCS.

Berni:
Impressive amount of effort into that thing.

It shouldn't be hard to transfer an image over a UART serial port over to a computer. Excellent excuse to learn some programming for it.

It wold be more difficult to create a self contained unit with a MCU, LCD, SD card etc. You do need a fair bit of embedded programing to get all of that to work and run fast. Yet you could still use Arduino stuff to get a quick jumping off point for it.

pieroc91:
Hi Berni, Thanks for your answer, and yes you are absolutely right in everything.

It is indeed a lot of effort that i've put on it, but that I loved doing and learnt a lot by doing it, i'll do it again if i had to.

About the UART that's also the way to go but now i have to learn about coding for a modern PC operating system and that's a completely different topic, I still tried to do it based on some examples included whit the FPGA board and the results were far from useful, the computer side overflowed very quick, it was also very slow... real coding skills were required there.

And lastly the self contained unit is the final step, and also yes, using a dedicated MCU is the way to go, an Arduino might or might not work, it needs to be a really fast one to keep with the speed of the UART and to write fast enough to the high speed SD card (the data is not being buffered on dedicated DRAM like on actual cameras), regular ATmega328 based ones cannot do that at all. Using a Raspberry PI could be somewhat more reasonable, it is powerful enough to do all the tasks without a problem.
Once I tried adding a small 128x96 i2s OLED display directly to the FPGA and bitbang the data to it... that was a whole lot of nonsense

Berni:
You can use serial terminal programs(like putty,teraterm,realterm etc..) to send the data from a serial ports directly into a file, this can help you debug to make sure data is making it in. If you are using linux you can just pipe a serial port device directly into a file using the terminal.

Serial ports are pretty slow so it should not be hard to make an application that receives at the datarate of a few Mbits per second. The main thing to keep in mind when writing software under a OS is that you can no longer have full control of when the CPU is going to be executing your code. So for servicing a serial port one would typical have some sort of event fire up periodically (be it a timer every few miliseconds, or an receive event from the serial port). Inside that event you start taking data out of the serial port for as long as there are bytes still in the buffer, looping around and around in place to pump it out, this will near instantly drain the buffer (since PCs are very fast) then you can exit out of the event and wait for a new one. PCs will always tend to have a few kilobytes of buffer and you can usually increase it into the megabytes if you want (but doesn't make sense to do that when you only have a transfer rate of like 300 KB/s)

Something like C# makes writing windows apps really easy as the IDE sets up all the GUI for you and the language is much like plain old C. Only real caveat being the garbage collection, so you just need to be mindful of when memory is being allocated, everything else is very fast.

pieroc91:
Yeah, classic serial ports are out of scope because of speed, the camera transfer speed is 8 parallel signals at 6mhz clock, so 6Mbytes, doubling the data rate would be very nice to avoid data corruption.
The FPGA board has a FT2232h chip which can create a real UART via the USB port (plus other cool modes) but that requires talking to a specific driver and writing some code that does it.

Here is the board and its characteristics https://earthpeopletechnology.com/products-page-2/modules/dueprologic (mine is the same but without the LED array).

C# is what is used on the examples included, but my knowledge at high level coding are near 0, last time i tried was on Visual Basic 6 and the results weren't great either.

I tried modifying the examples and understood what the driver expects but when it came to dealing with data inside the c# code I online managed to crash the program or even to not compile at all.

This was the fastest i could get to transfer data without overflowing something or losing a lot of data

On an important matter, the data must be read as fast as possible, the CCD when is exposed to light retains the picture and via a some sort of analog shift register it will spit one pixel at a time at a fixed 6mhz rate to the ADC which converts it to 8 parallel bits, when the current line of pixels is read completely the sensor must be clocked and the whole picture shifts the whole picture one pixel so the next line falls into the shift register buffer.

The only possible moment where the ccd can take a pause is between each line, this for testing purposes is kinda okay, but for final usage is not possible since the CCD itself will start collecting noise from the ambient heat and the image will end up severely damaged.

Navigation

[0] Message Index

[#] Next page