HDRI Community

Hi!

I was pointed to this forum by a friend who is shooting lots of HDR.
I am a professional software developer and I also use Atmel CPUs quite a lot for small controllers and embedded devices. Although I love to work with the little buggers, they sometimes are simply overkill.
When looking at the circuitry and the software I saw a few points where the design could be simplified dramatically.
The way the Atmel is wired to the DS bus, it is hard to do an efficient communication. The software driving it may be rewritten to be far more power saving. A cheaper CPU would do it too. The way it is currently used, it may even be replaced by a simple HEXFET transistor.

This would result in the following part list:
one IRLU 2905 or IRLR 2905 (HEXFET)
one 300 Ohm resistor (to limit the current through the optocouplers)
one 1M Ohm resistor (as pull-up for teh HEXFET)
one PC827 optocoupler (two units in one case, one for AF, the other for the shutter)

... resulting in a total cost of 2.40 Euro (approx. 3.2 USD) excluding the PCB. No need for a programming adaptor. Slim, easy to solder, no critical parts.

You may use eqivalent parts if the above mentioned items are not available in your area.

I' made a wiring diagram (see attachment). A PCB layout will follow.

Helge ;-)=)

Helge,
I really like this design for the simple trigger cable.  Where did you find the eagle footprint for GBA connector (if that is eagle you are using for the schematic)?

Blochi,
The USB interface is a whole different beast and should be considered a new interface. It will require quite a lot of new circuitry with a different interface method to the DS instead of just strobing the write line.  Parallel read \ writing with a CPLD or uC connected to a USB host controller.  Also a lot of new code will need to be added to the DS to handle a USB interface cartridge.

That sounds like a great idea, especially since it'll fit in a standard GBA cartridge.

Another good improvement would be to design the board with room for that 6mm diameter hole in the middle where the screw boss goes and the two notches in the sides.  That way it'd be a drop-in replacement for the cartridge's stock circuit board; no need to cut out the plastic posts and no need to glue the new board in.

Here's a diagram of where the hole and notches should be (marked in red).  I took the measurements from the Warioware:Twisted cartridge.  I suppose they're the same for a standard-sized cartridge, but I'm not sure.

Those of you wishing to help with board design, (and help me out here if I'm wrong, Achim,) here are a few things to know about our current interface:

The DS bus is set high at 3.3v on power-up. The signal to the microcontroller is a 30ms low pulse, & will not stay low for the desired duration of the shot. The design must wait for a "go" signal, trigger the shutter, then listen for a "stop" signal - which is the same as a "go" signal!

You could really help us if you could outline the DS specific ARM code needed to keep bus pins low for longer than 30ms. We're not ARM assembly programmers, sadly, & must use the abilities the SDK has provided for us. With more control over the bus, we can utilize a more complex communication method required for signaling specific USB PTP requests. Right now, what we have is a sort of "Knock knock. Who's there?" signal protocol.

Steve,
I would be happy to help you guys out but I need more information on how and what you are connecting to the GBA port.  As you said strobing the WR pin is not going to work for USB so I have worked a bit on using DMA transfer.  This will allow for parallel writes and reads with cartridge interrupts. I got the code working on the DS and was able to write to the GBA port.  That is not the full code but that should work, the trick was setting the ARM9 in control of the bus for DMA.

The next thing I need to check is if a AVR running at 20Mhz with an interrupt is fast enough to grab the data of GBA bus when using a DMA write.  If not a latch chip may have to be used.

Okay so I just tried using a interrupt to catch the data of the GBA bus but an AVR at 20Mhz is far too slow.  This is with the DS GBA bus setup to the slowest clock wait cycles.

A $1-$2 cpld could be used to handle the communications with the bus that would then be connected directly to a USB host controller IC.  This would eliminate the need for a uC and let the DS talk directly to the USB host controller.  Another option is to use a latch chip.  If no one else has come up with a solution I will move forward in getting one of these working.

In the attached image you can see the AVR (AVR_ISR line 0) responding to an interrupt on the falling edge of the WR line.  I made the AVR toggle a pin so I could see the timing.

Here is the AVR ISR code
[code]
ISR(INT0_vect)
{
     //Set bit high to indicate interrupt has started
     Bit_Set(PORTD,7);

     //Copy data to variable
     GBAinput=PORTC;

     //Set bit to tell main routine new data is has arrived from the DS
     //GBANewData=0xFF;

     //Set bit low to indicate interrupt is finished
     Bit_Clear(PORTD,7);
}
[/code]

Helge wrote on 05/29/10 at 23:27:55:


Helge,
It does not appear to be possible to keep the write line low for longer periods of time due to how the DS\GBA DMA hardware is setup.  You do not have direct control over the GBA pins in software.


Quote:

I was using a different ATmega but not as a USB host controller, just as a interface to the GBA port.  Either way it is not fast enough to handle garbing data off a DMA transfer, a latch or replacing the uC and latch with a CPLD will have to be used. As for the AT90USBxx7, this chip is end of life and is not a good choice for a new design.  The new vinculum II with on board programmable uC will work with a latch IC or the older vinculum with a CPLD or uC and latch IC.

Quote:

SPI is only available on the DS cartridge not on the GBA cartridge.  This would require booting off R4 or equivalent then swapping out the card for the USB host controller card.  I have been thinking of this but my big question is if the entire program is loaded from the R4 upon load?  If not the DS would try and access the program off the R4 when it is not longer available due to card swap.

Cheers,
Luke

You'll have to forgive me, I have a few too many projects "on the burner" at the office, so I'm basing this on recollection only: The firmware doesn't hold the shutter closed while the GBA line is low, rather it holds it while the bool variable is false. There's a subtle difference, and I'll have to go back to the breadboard to remember why it was built this way.