Andrew Olson

So I stumbled upon this really sweet and unique cartridge dumper about a couple months ago.  It's called the Retrode and it shows up as a storage device with the ROM as a file on the drive.  It creates the files from only the carts ROM and RAM.


I've been working on my third revision of my Gameboy ROM Dumper that is based on the Retrode.  I've been working on it off and on since November.  I'm almost at the point where I can offload the ROM but I was running into a problem.  I recently figured out that the source of my problem was that the processor was crashing.

So how did I get to this point?

I spent some time in the beginning researching FAT file systems since I was going to have to emulate one in order to get the ROM to appear as a file on faked mass storage device.  Once I understand how the FAT system worked, I wrote code to interface with the cartridge the way the file system would and wrote code to build the necessary data structures(FAT table, Directory Entry, Boot record) that the host would expect to see on the mass storage device.

I'm using the StellarisWare drivers again and there happens to be a mass storage device example that I've based my application on.  When I first started this I couldn't find a lot of information about other people that had done this but then I came across NXP microcontrollers and they use this concept as their programmer.  Basically when you plug the micro into a usb slot it shows up as a mass storage device with the firmware on it.  You can then drag and drop new firmware onto the micro.  Travis Goodspeed also gave a talk about faking mass storage devices at CCC this year.

I got to the point where I could view the contents of the device in WinHex but I couldn't transfer the file to my computer.  The readout from WinHex gave me confidence that I had setup everything correctly but doing a file transfer broke my system.  Around that time someone had ported the drag/drop firmware transfer to the Stellaris Launchpad.  I compared my code to theirs and didn't find much difference in our process.  I was a little confused as to why mine wasn't not working.  I used their debug messages in my code and found that it would read sectors then freeze.  It would freeze on different sectors every time.  I assumed it was timing out and the host wasn't requesting the data again.  I finally put a debug message in the mainloop and that message stopped when the sector reading froze.  The USB mass storage is interrupt driver.  This could still mean that its getting into an infinite loop.  I haven't had the chance to dig through the USB driver library and see if there's anywhere it could get stuck.  It could also mean that the processor is crashing, due to a stack overflow, out of bound array reading, etc.  I don't have a JTAG debugger so it will be difficult to track this down.  Well I do have a bus pirate so I might be able to setup some debugger with OpenOCD or something.  That is something I will have to check out.

That's where I'm at and I hoping to get this solved at some point. When I do I'll post my code.

I posted about my senior project a couple months ago.  Well the platform(http://synbotics.com/) was used as the mobile base for a set of awesome robotic arms from APL.  Those arms were featured on 60 Minutes but you can see the platform in the lab and driving around.  Check out the video from CBS.
Link to 60 Minutes Video
I'm pretty stoked that something I helped create has come this far and I'm looking forward to see what it will do in the future!

 I got a RPi for Christmas.  I have it all set up and computering along.  Setup was very simple: Connect all the Things!, load the image onto the SD card, and apply power. 


I'm currently running 2012-12-16-wheezy-raspbian.  I plan to experiment with this distro and try all the others. 


I'm looking forward to getting my hands dirty, making mistakes and learning a lot about linux and other things.  I'll be sure to post what I do with it.

(This is late getting posted.  This happened 2 weeks ago.)
Here's a little brushless motor controller I whipped up over the weekend.  It's got an atmega88 running at 20MHz, programming port, serial port, and 7805 voltage regulator.  The power electronics consist of 6 n channel FETs connected in 3 half bridges.  Since all the FETs are n channel driving the upper ones are a little tricky.  nFETs need a positive voltage difference between the gate and source.  This is easy to generate on the low side since the source is referenced to ground but the high is a different story.  The source is basically floating.  Through some google fu I found that it can be driven with a bootstrap circuit that bumps up the gate voltage in order for the fet to turn on.  The circuit I reference is also used on some mystery esc that I found in a RCGroups thread.

I ran into a problem when I was trying to test the bootstrap circuit.  Ever time I tried to measure the boosted voltage I would discharge the cap.  I'm going to guess that it's a result of the circuit and the cheapo DMM I was using.

I spent a majority of Saturday soldering it together.  I made up layout as I went along so that took some time and resulted in a sort of inefficient layout.  But it worked when I powered it up.


I started with my hello world code, where I send Hello World over the serial port.  I ran into a problem where I was just receiving garbage when I was sending at 115.2kbs.  I looked at the data sheet and at 20MHz, there is a ~1.5% error in rate for 115.2kbps.  So I switched to 9600b with an error of 0.2% and that solved my problem.  Another thing that might have contributed to this problem was that I had forgotten to solder the ground connection to the Xtal caps.  I'm not totally sure but that might give me an unstable clock source.

In order to control the motor, I modified some code from an ATMEL appnote on brushless motor controllers.  The just steps through the commutation states without any feedback as to where the rotor is.  This causes the motor to be very jerky, sometimes stall or stutter.  Any way I'm not going to post the code since it isn't very useful as you would never want to drive a BLDC like this besides the very short time in some start up routines before the rotor's position is known.

I'm planning on adding some feedback in the form of either sense resisters to measure phase current or a voltage dividers to measure phase voltage.  I will probably do current sense resisters so that I can implement a Field Oriented Control algorithm.

Anyway I have a nice little dev board for the atmega88 now.  I've been thinking about brushless motor control for awhile and I have a couple ideas up my sleeve.  I need to finish my own motor so that I can drive it with my own controller.  How cool is that.  I plan to develop more brushless motor controllers and motors and possible some things that will be controlled by them.