Here's the story: AGES ago, I set out to make a homebrew game console like the Uzebox. I picked out some parts and started playing, but real-life quickly got in the way.
Before too long, the STM32F4[DISCOVERY] came out and my little console was totally obsolete before it even existed!
Well, I recently decided I wanted a bit of a challenge after being away from any electronics-hobbying for a while. I already had all the parts, so I figured, "Screw it! I'm going to start making this thing anyway!"
So, I did. And here it is.
These were my goals for the console & criteria to help me choose the right MCU:
- At least one free, 16-bit data port with DMA (for 15-bit color video)
- All programming capability is built-in. You build it, you can program it.
- To facilitate the above, chip needs built-in USB capability. USB functionality can't require a specific clock speed. (Built-in Ethernet is also a plus) EDIT: Oops! Chosen chip doesn't have that! See below.
- At least two 16-bit timers that can trigger interrupts. At least 3 timers total.
- Predictable, well-documented CPU with most instructions being single-cycle (or thereabouts) and especially single-cycle (or thereabouts) multiply. (I'm giving dirty looks at you, Propeller!)
- Chips need to be sample-able.
- It's gotta be powerful!
I chose the MCP2200 to allow hobbyists like myself to talk to the Pic32 with no other hardware, like a $50 ICSP programmer or JTAG probe. This could really be a "project" in and of itself but I consider the goal of including programmability in the design to be a very important one. Other than including this chip, I'm shamelessly stealing the Uzebox's simple design philosophy .
The MCP2200 is a very inexpensive USB to UART chip with a fairly easy-to-use API interface. The idea is to use the MCP2200 to bit-bang JTAG, then use the JTAG port to load a more-permanent USB bootloader into flash. Of course, if you already have a JTAG probe or choose to buy one, you can presumably just use that.
This USB->JTAG project is where about 100% of the progress has been, so far.
I've made a little program that can use the MCP2200 to talk to the pic32.
This is how it works and what is working so far:
- The program uses the MCP2200 to bit-bang a JTAG interface.
- It uses that JTAG interface to ID the PIC and put it into Serial Execution Mode.
- SEx mode (lol) allows the program to feed the PIC's CPU instructions and make it execute them.
- The program feeds the CPU code which copies each instruction of the programming executive loader to RAM.
- The PE loader runs on the PIC CPU.
- The program parses a hex file from Microchip containing the Programming Executive and sends the code to the PE loader.
- The PE loader takes the PE code and copies it to RAM.
- The Programming Executive is executed on the PIC CPU. The PE allows for much faster and simpler programming over the JTAG interface.
- The program sends a command to ask the PE for it's version number. The PE responds appropriately.
I don't think I can tell you how rewarding it felt to see that unassuming version number come across the first time. Or, how many times I've run this program in the background just to see those same glorious results . I think you can tell how excited I was throughout the process by the program's output:
TODO:
- Get tool chain up and running and making .hex's.
- Add arbitrary .hex programming functionality to program, via PE command set.
- Make MCU say, "Hello World!" over UART .
- Install flash bootloader that allows for programming over UART or USB. (Hopefully not as hard as it sounds; I think Microchip provides one)
- Get system clocked up to speed.
Add video, sound, port Uzebox kernel, etc...
Would be very cool:
Integrate support for this JTAG hardware into some other open source JTAG software.
Notes and Gotchas for fellow builders:
- Just by attempting this build you join a super-elite club and I really hope you do . It would be super-awesome if someone besides me ends up building this!
- The adapter boards can easily be found on ebay. Look up "tqfp" for the PIC board and you can't miss em. I have good experiences with an eBay store called thaishopetc. Get a few boards and chips; it took me two tries . IME, you shouldn't get chips on eBay.
- Make sure you avoid the 0.4mm chips and boards. 0.5mm is plenty small enough to please the sickest masochist, LOL.
- Don't get the same double-sided board as I did from eBay: the holes aren't big enough to allow headers to pass through :*(.
- With this many pins, low insertion headers on the PIC breakout are absolutely crucial. I won't lie to you; it won't be fun (or cheap) finding them. You'll probably have to get something bigger and cut it down. Samtec low insertion headers can usually be identified by a two in the part number like so:
SSW-XXX-2x-X-X. If you just want to be lazy and buy the perfect female headers from Samtec, you can use part number SSW-113-21-F-D. You'll need 4 of them, and the matching male headers, of course. - At this point in the design, the MCP2200 MUST be configured properly before trying to communicate with the PIC. You can do this with Microchip's provided utility. I believe failure to do so may result in one or both chips being fried. I made it really easy for you though; the only important setting is IO CONFIG, which NEEDS TO BE 00000001.
- For the same reason, USBSSPND MUST NOT be enabled.
- Leave all the check boxes in the MCP2200 configurator unchecked, for now. I have noticed that if I enable Tx/Rx LED's, GP5(TCK) is no longer controllable via the API. This is odd because GP5,6 & 7 all work as expected individually if set through the control utility, and Tx/Rx LED's (GP6 & 7) also behave as expected when enabled as such. I just noticed the same thing with USBCFG and GP4(TDO). p.s. Tx/Rx only applies to the UART anyway; nothing this program does will light them up.
- Schematic is untested but the only real difference I know of is that my MCP2200 gets its 3.3v separately, from an ADP122. That's just the way my hardware evolved; only the large 3.3v LDO regulator should be needed to power both chips.
- The code is meant to be easily configurable but the program has little in the way of error-checking right now. It seems to make the assumption that it was made alongside one single piece of hardware and the bugs in each were fixed in tandem. What could have given it that idea?
- If something looks wrong, it probably is, so let me know! I've got no damn clue what I'm doing here!
Please check out the schematic, check out the code, leave comments and if you're feeling intrepid, build the hardware and run the program!
TLDR: I made a thing that hooks up to a pc and blinks!!!!! Oh, how it bliiinks! xD