We want to make a standalone device, Martin. I have the prototype board wired, though I am faced with a dilemma: The DS outputs 3.x volts, and the USB spec calls for of course 5V.

Many cameras do not pull power off the 5V USB bus so it can be left disconnected. If you find some that require power off the USB bus the USB spec calls for 500mA @ 5v which I do not think the DS was designed to output that. You would have to use an external battery with a linear regulator or buck supply.

We want to make a standalone device, Martin. I have the prototype board wired, though I am faced with a dilemma: The DS outputs 3.x volts, and the USB spec calls for of course 5V.

Hello Steve,

that is no problem, you can put two diodes between each voltage circuit so the 5V form the USB Camera Port ( if a camera puts it on the line ) don´t detroy the DS. Each circuit can be connected without causing problems. ( just tested at home ). To hold the Atmega stabil to 3.3V insert a zener diode into the V+ line.

Steve, I do not think a charge pump regulator is a good choice because it can not source much current. A boost regulator is a better choice if you want to pull power from the DS and meet the USB spec. Something like the LM2735: http://www.national.com/pf/LM/LM2735.html

Have you tried leaving the USB power disconnected? It works in my testing.

There is one question left. "Is it needed to transmit 5V by using the usb port to the camera or are only the GND and both signal lines required"

If the 5V are not required you have anyhow to connect all contacts. I don´t know if the usb port is planed only for controlling the camera or should it be possible to update the device by this port too? If an update possibility is planed by usb too, the 5V pin ( pin 1 ) has to be connected to power up the occ.

Achim,Only the GND and the two data lines are needed for communications with devices that do not pull power off the USB bus.

A 5V user supplied input connector could me added on the board for the rare cases when you need USB power like if you want to connect a USB flash drive for firmware update like you said. The input could be connected through a simple LDO 5V linear regulator to protect the device.

I designed a Nintendo GBA (slot-2) DMA to FTDI parallel FIFO interface. This is one of the interfaces used on the FTDI vinculum USB host controller. I have tested it on a Xilinx CoolRunner-II development board and DS read\write is working.

I know Steve is working on a USB host controller and seems to be further along but I decided to have some fun and see what I could come up with while we are waiting to see what he comes up with.

I am testing\debugging the CPLD interface with a FTDI 2232H instead of a FTDI vinculum which uses the same parallel FIFO interface. Using the FTDI 2232H just lets the DS communicate with a computer instead of the USB host controller for easy debugging. To allow the DS to talk to USB slaves, like a camera, I just have to disconnect the FT2232H eval board and connect the FTDI Vinculum USB host controller eval board.

What needs to be done now is implement PTP on the DS to talk to a camera. I have part of the protocol figured out but will take a few weeks to get it working.

In the picture most of the stuff is not needed, the dev board has a bunch of other components on it that I am not using, a much smaller CPLD can be used, and on the right is a logic analyzer that is just for testing.

One weird thing I am running into is when I try and read from address 0x8000003 the following codes does not work.

DummyVar = *(vu16 *)0x8000003;

This reads from 0x8000001 instead of 0x8000003.Edit: It was a stupid mistake, since it reads in word blocks not byte blocks you have to multiply the address by two when reading bytes, for example to read from 0x8000003 on the GBA port you need to read from 0x8000006 in DS code.

I have gigs in Montana and Hawaii for the next couple of weeks. I gather your work (Luke) is based around using the DS to send the ptp commands directly, a logical choice, though I'm attempting to avoid this because I question the future of the DS product, with DSi probably taking it's place, and the 3DS becoming the main product later this year. Of course there will be DS's available used for years to come, one can still buy a GBA at Gamestop a half-decade after it was discontinued.

If we make a device that needs the DS solely for UI we can more easily transport that portion to iPhone, Android, etc.

I think you've concluded that the bus can't be made to behave as GPIO, my hope was that we could do bi-directional comms without any additional circuitry. As an open-source project we need to try to keep this DIY friendly, but that may be too strict a limitation, and it seems that many visitors to OCC solely want to buy a prebuilt device, which is cool because we're mostly photographers here.

im no board engineer, ds homebrew expert or anything, just an idiot with an idea. but couldnt you build a program that uses the wifi, like a game(built into the bracketer and other programs), and communicates data back and forth through the wireless to a reciever for instance a arduino and connects to xbee through usb and a shutter cable, for long and shorter exposures.

the hard bit is cracking the wifi, i would assume, re engineering it to do something different then what it was set out to do. and steve you are doing a really good job.

I have been playing around with a lot of ideas but I think the simplest and lowest cost solution is to implement the PTP protocol on a FTDI Vinclum-II IC then it could be easily interfaced to work on the DS, Bluetooth, iphone, android and just about anything else. The FTDI Vinculum-II IC will not be released until September this year, so that is why I stared with the Vinculum-I to get a head start and learn PTP & USB before the release. The FTDI Vinculum-II is a USB host IC with a built-in 16-bit microcontroller and free IDE so it is open source friendly. This makes a simple one chip solution that would support SPI, FTDI PFIFO, UART, and DMA (not the DMA used on the GBA port). The SPI connection could be used to connect to the DS\DSi cartridge slot and work with all the DS’s through the newest DSi XL. Or my CPLD design could be used to interface to the PFIFO on vinculum-II with the GBA (Slot-2) port on the DS. The vinculum-II could also be easily connected to a Bluetooth chip for communication with phones or computers.

Martin, the USB host capability on some android devices is pretty sweet, I have a droid and it has USB host capabilities but it is not implemented in the version of android OS that comes with the phone. You have to root your phone from what I have read. I think it would be cool to implement PTP on android, the linux app gphoto could be ported over to android because it has full PTP support and a huge number of cameras supported. Android runs on a Linux kernel so it wouldn’t be a big leap. For an all around cross platform solution to use with the DS and others hardware a standalone device using a USB host controller like the vinculum-II would be the best choice.

I vote for the Vinculum, as well, Martin. I'd avoid wifi because it doesn't provide us with anything more than we already have. I used the iPhone app & on-one remote for shooting on a movie last fall, though that requires a nearby laptop/hotspot, and the OCC device was originally made to alleviate the need to carry a heavy laptop.

As of now, the only component I have added to the original OCC design is a Vinculum VDIP1

I've found that the ptp USB connection does not provide 5v to the Vinculum (at least from my test camera), so I'm left with using a boost circuit. Right now, for testing, I'm using a mains ac supply.