I figured it would be best to start a new thread for this then posting it in the USB thread.

This is my first rough prototype of a USB host controller for the GBA (slot-2) of a nintendo DS & DS lite. You may have seen the GBA DMA interface in the USB thread. The code was written and developed on an Atmel AVR (non-Arduino) and ported over to the DS. It is much easier to develop code on an AVR then on the DS which you have to constantly swap SD cards on every recompile. I wrote the code to be as platform independent as possible so it can be moved to whichever device needed. I do not think it would be too hard to add to the OCC code once done, you will just need to call a few functions to init the vinculum and to take picture, change exposure time, etc. It is still very rough and once I clean it up and get some more kinks worked out I will post it (that could take some time). I am only using a very, very small subset of commands from the PTP & MTP specification.

I am using a FTDI Vinculum USB host controller for the USB interface. A xilinx CoolRunner-II CPLD is used to convert the GBA (slot-2) DMA interface to the FTDI PFIFO. There are only two main components uses the Xilinx CPLD and the Vinculum USB host controller, everything else is for development and debugging.

USB power is left disconnected from the USB port as it is not needed. A connector for external power and simple linear LDO regulator can be used for the rare cases where USB power is needed, for instant a firmware update from a flash drive.

This design can also trigger a camera from a standard shutter release cable for cameras not supported by USB commands. It is also slightly faster to command an exposure setting via USB and fire the shutter release cable then to send a command over USB to fire a shot. This is also how the promote controller does it.

Here is the development platform I am using to write and test the code on. The development board is an Atmel STK600, a STK500 can also be used. I am running an ATmega 644 uC 44-TQFP @ 20 Mhz. The 44 pin uC is used to have more IO pins for debugging but a smaller IC can be used. I hope to upgrade to an xMEGA running at 32Mhz, it is much faster and lower cost uC.

Hardware:- ATmega644 uC, on a Atmel STK600 dev board- The USB controller is a FTDI Vinculum VNC1L, I am using the VDIP2 board for testing- To the right is a FTDI FT232RL USB to UART for high speed terminal debugging, I was unable to get a clean serial signal from the STK600 at speeds over 57600 baud, I am running the UART at 250Kbaud

In the video you see an 8 second exposure to show how the code keeps checking the camera events info until it sees the shot has finished. The second part is a 7 shot HDR bracket, the code commands an exposure time, fires a shot, waits for the shot to finish and then repeats for each shot in the bracket.

By the way, have you allready a connection diagram of the working prototype?

The coolrunner II has a XC2C256-7TQG144 installed. That MC ist really big for implementation on the occ. I think a little bit oversized . Do you think it is possible to use the XC2C32A-6VQG44 in combination with the Vinculum chip instead?

@Achim,Most development boards come with larger parts than needed and as you said the XC2C256 is definitely overkill for this project. The current logic consumes 45 macrocells so the XC2C32A part unfortunately cannot be used. I plan to use a VQFP-44 Pin XC9572XL ($2-$3 75 macrocell part) or a VGFP-44 Pin XC2C64A ($2-$3 64 macrocell part) on the final design.

I will be out of town for a week starting this weekend but after that I will do schematic capture and layout.

@Ichabod,That is correct, with USB control you can command shots down to your camera's shutters limit. That was my main driver for doing this project; I wanted to be able to do 5+ shot brackets at faster then 1/20.

it will enable the shutter speed to be used at your fastest shutter speed - technically (easier said then done - and im not saying 4-8 thousandth of a second is a good thing), but there is no reason why it cant.

i think the hard part is changing the shutter speed for the next exposure of the sequence and getting this to tie in with the camera(s) because all cameras have different FPS e.g.

i think the 1ds mk3? (or is it the 1d mk3? yes the APS-C size sensor not 35mm) does 10 per second and mine (500D) can squeeze 3.5

im thinking that the ui might have to be changed to accommodate this new factor for the speed that the shutter is going to be popping out at

all i was thinking is, a on a screen before you see bracketing ui on the occ bracketer. there could be a "what camera are you using" dialogue box

witch will utilize a Vlookup (Excell) sort of command where it will dig out the fps of the camera, and how many frames the camera can continually shoot. till it has to release its buff. so the usb wont swamp certian cameras or be too slow for others.

on this page you could also integrate the save speed of the camera.

like what CF or SD card speed you have and change the save speed times accordingly.

i will grab the data for all the CF cards you guys have(and cameras) and collate it into a table of FPS and savespeed times.

so its just select camera, chance save speed (write speed because it sometimes causes issues with slower rated CF and SD cards)

it will still need to utilize the shutter cable release that the system has now for longer than 30s exposures but this means the camera will be far more EFFICIENT. and faster at shooting off your bracketing sequence

so there would be 2 cables comming out of the one OCC

rant over... was that a rant or a continuous prose...? anyway i thaught i would feed that to you guys

...i think the hard part is changing the shutter speed for the next exposure of the sequence and getting this to tie in with the camera(s) because all cameras have different FPS e.g. ...

Martin,This is the easy part and not a problem with USB as with the shutter release cable. This is another benefit of using USB control.

Here is how it works:1) Command the exposure you want to the camera2) Check the cameras response to confirm command, if no response or responded with a wait state then keep checking until confirms change or timeout.3) Command a shutter fire4) Keep pinging the camera until it confirms the shot is finished then repeat for the total number of shots you want in the bracket.

This is all done in code with no user specification or look up table of the camera FPS, etc. It will fire off as fast as the camera lets it.

Martin,I was out of town for over a week, this weekend I had some time to work on this some more. I ran into a few issues working out the quirks of the canon MTP implementation. I have a lot more things working such as 5+ shot bracketing. I will post a video and info on the AVR development platform sometime this week.