Welcome, Guest. Please Login or Register
Home Help Search Login Register
Pages: 1 2 
Send Topic Print
Why use a microcontroller? (Read 20549 times)
Helge
Junior Member
**
Offline


I love HDR

Posts: 3
Why use a microcontroller?
05/26/10 at 20:21:28
 
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 ;-)=)
Back to top
« Last Edit: 05/28/10 at 04:11:15 by N/A »  

circuitry.png (Attachment deleted)
 
IP Logged
 
Blochi
Administrator
*****
Offline



Posts: 1726
Hollywood
Re: simplified board layout
Reply #1 - 05/26/10 at 21:58:09
 
Interesting.
Brings up two questions:

A) The current effort goes towards adding USB support - will this go the right direction?
B) Does this result in a slimmer board, so it will fit inside a standard GBA casing?

Back to top
 
WWW  
IP Logged
 
Luke Skaff
Full Member
***
Offline


I love HDR

Posts: 40
East Coast, USA
Re: simplified board layout
Reply #2 - 05/27/10 at 01:52:09
 
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.
Back to top
 
WWW  
IP Logged
 
Helge
Junior Member
**
Offline


I love HDR

Posts: 3
Re: simplified board layout
Reply #3 - 05/27/10 at 06:58:27
 
Hi!

@ Blochi: You may build a very slim board. I will try to fit a prototype in a standard case. No sockets needed. No programming either.

For USB support you have to change a lot of other things. First, the ATmega isn't the choice for USB hosting. I'd use at least an AT90USB1287 which provides USB OTG limited host functionality.
Driving cameras through USB is a real pain. There are lots of traps on the way. Luckily, there's an open source project that allows USB camera control based on Linux and Windows. Maybe the source can be ported at least in significant parts. Hopefully it has enough memory to hold the code.

For USB control you also need a better communication between DS and micro. This would result in a complete redesign of the board.

I would also add a six pin ISP connector to flash the micro right on the board.


@ Luke:
Yes, it's an Eagle template. You find it in the  [url=http://www.cadsoft.de/cgi-bin/download.pl?page=/home/cadsoft/html_public/download.htm.de&dir=eagle/userfiles/libraries]Eagle Library Collection[/url]. The name is gameboy.lbr. If you can't find it, just drop me an email and I send you the file.

Helge ;-)=)
Back to top
 
 
IP Logged
 
o12
Ex Member


Re: simplified board layout
Reply #4 - 05/27/10 at 09:02:46
 
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.
Back to top
 

WWTwisted_Cutouts.jpg (Attachment deleted)
 
IP Logged
 
Achim Berg
Moderator
*****
Offline


I love HDR

Posts: 177
Germany, near Cologne
Re: simplified board layout
Reply #5 - 05/27/10 at 11:16:40
 
nice, but i think maybe the spirit of the occ was not understood.

The OCC and the at the moment used version is the basis to develop the next level OCC. The occ should not be a simple shutter release unit controlled by the DS but at the moment it is. I agree that this could be done more easy, but to develop a usb atached device you have to do several steps before. This OCC is the first step.

Those who want to use the OCC as a DS controlled shutter release unit should stop at this point and use the simple circuit instead a mc controlled type. Those who want to step forward maybe try to help to go forward to realise a brilliant occ that supports things a "promote" for example is not able to support.

Anyway nice smart plan. By the way. If using a standard GBA case the inside is a little different to the warioware twisted case. The case is very flat so it could be a problem to install the pc827 because of the thick. The same will happen using the PG203J.

Here is a circuit layout that fits in a small GBA case. I decided to omit the PG203J connector. Three solderpoints are installed instead.

Yours Achim

PS. that the usb combined OCC needs a new circuit board is well known. We are working on it.

Back to top
« Last Edit: 05/27/10 at 12:48:57 by Achim Berg »  

gba_small_prototype.jpg (Attachment deleted)
WWW  
IP Logged
 
Steve Chapman
Ex Member


Re: simplified board layout
Reply #6 - 05/27/10 at 20:48:08
 
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.
Back to top
 
 
IP Logged
 
Steve Chapman
Ex Member


Borrowing a bit from Luke:
Reply #7 - 05/27/10 at 23:15:47
 
Edit: to clarify, I'm quoting Luke below.

I am trying to write to a memory address on a GBA cartridge (I am working on a custom cartridge with a uC).  I know the GBA RAM starts at address 0x0A000000 and ROM at 0x08000000 but how do I write to it?

I am a bit rusty on my C, it's been three years.  I tested the following but nothing shows up on the logic analyzer.


*(vu16 *)0x8020000 = 0xD500;
*(u16 *)0x8020000 = 0xD200;
*(u16 *)0xA000000 = 0x0F0F;

---
vu16 *addrPtr;
addrPtr = (vu16 *) 0xA000000;
addrPtr = 0x0f0f;

vu16 *addrPtr2;
addrPtr2 = (vu16 *) 0x8000000;
addrPtr2 = 0x0f0f;

EDIT: for anyone searching in the future, I figured it out, you have to give the ARM9 processor control to the slot with this line of code
sysSetBusOwners(BUS_OWNER_ARM9, BUS_OWNER_ARM9);

This may be on the libnds somewhere but the site has been down this past week so it took a ton of digging to find this.

LUKE: Did you confirm this with the logic analyzer?
Back to top
« Last Edit: 05/28/10 at 15:30:47 by N/A »  
 
IP Logged
 
Luke Skaff
Full Member
***
Offline


I love HDR

Posts: 40
East Coast, USA
Re: Why spend $4.50 on a microcontroller?
Reply #8 - 05/28/10 at 00:33:07
 
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.
Back to top
 
WWW  
IP Logged
 
Achim Berg
Moderator
*****
Offline


I love HDR

Posts: 177
Germany, near Cologne
Re: Why use a microcontroller?
Reply #9 - 05/28/10 at 15:05:54
 
@Steve, you are absolute right.

Yesterday I spoke with a fiend who worked till last year for Eidos a big producer for DS Games. Maybe he can persuade one of the programmer for the software for the DS to the comunity and maybe he can give us the information about grabbing informations by a 20Mhz clock Atmega connected to the DS.

    


Back to top
 
WWW  
IP Logged
 
Luke Skaff
Full Member
***
Offline


I love HDR

Posts: 40
East Coast, USA
Re: Why use a microcontroller?
Reply #10 - 05/29/10 at 21:24:43
 
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]
Back to top
 

AVR_int.gif (Attachment deleted)
WWW  
IP Logged
 
Helge
Junior Member
**
Offline


I love HDR

Posts: 3
Re: Why use a microcontroller?
Reply #11 - 05/29/10 at 23:27:55
 
Hi again!

@Steve:
When you just strobe the write signal the simplified solution won't work. You'd need a monostable flip-flop to keep the camera side signal 'till the second strobe. That's where a small micro is the more flexible solution.
Changing the DS side software to keep the line low long enough would allow the use of the simplified circuit.

As for USB: the ATmega 16 is not suitable for USB host functionality. The AT90USBxx7 could do it.

What I would try is to implement something like a SPI interface on the DS side. SPI has a quite simple timing and works fast on the Atmels. You need 4 lines (send, receive, clock, chip select) to transfer data between micro and DS.
Again, the main key to this solution is better control over the bus lines.
This could work reliable without extra hardware. A dedicated USB conroller that is completely managed by the DS would be another possible option. The tricky part is to find one that interfaces well with the DS.

Helge Wink=)
Back to top
 
 
IP Logged
 
Luke Skaff
Full Member
***
Offline


I love HDR

Posts: 40
East Coast, USA
Re: Why use a microcontroller?
Reply #12 - 05/30/10 at 01:26:26
 
Helge wrote on 05/29/10 at 23:27:55:
Hi again!

@Steve:
When you just strobe the write signal the simplified solution won't work. You'd need a monostable flip-flop to keep the camera side signal 'till the second strobe. That's where a small micro is the more flexible solution.
Changing the DS side software to keep the line low long enough would allow the use of the simplified circuit.


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:
As for USB: the ATmega 16 is not suitable for USB host functionality. The AT90USBxx7 could do it.

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:
What I would try is to implement something like a SPI interface on the DS side. SPI has a quite simple timing and works fast on the Atmels. You need 4 lines (send, receive, clock, chip select) to transfer data between micro and DS.
Again, the main key to this solution is better control over the bus lines. This could work reliable without extra hardware. A dedicated USB conroller that is completely managed by the DS would be another possible option. The tricky part is to find one that interfaces well with the DS.

Helge Wink=)

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




Back to top
 
WWW  
IP Logged
 
vic
Ex Member


Re: Why use a microcontroller?
Reply #13 - 06/02/10 at 16:27:56
 
Hi,

I've been reading the website and the forums for quite some time (great work, by the way), and I'd like to build the simplified cicuit to be able to fit it inside a standard GBA cartridge. However I studied the schematic and I have a few questions :

  • WR is an active-low signal, therefore shouldn't it be inverted before triggering the FET?
  • The simplified circuit is missing the Guitar Hero emulation lines that the standard board has, will it still work correctly?
  • Steve, you state that the shutter should be triggered by a 30ms pulse, then released by another 30ms pulse. However when I read the arduino firmware, that's not how it works, it triggers the shutter as long as there is a low state on WR. So which one is the correct behaviour?


Thanks.
Back to top
 
 
IP Logged
 
Steve Chapman
Ex Member


Re: Why use a microcontroller?
Reply #14 - 06/02/10 at 17:58:03
 
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.
Back to top
 
 
IP Logged
 
Pages: 1 2 
Send Topic Print