[Bogdan] makes a good point. When you use a dev board you get programming, debugging, power sourcing, and usually a UART. When you go to the trouble of hooking up a programmer why don’t you get the same thing? Astutely, he points out that all you usually get with programmers is programming. So he set out to add features to the hardware he uses to program XMEGA.
The first part of the trick hinges on his use of PDI programming. This is slightly different from ISP programming. Both use a six-pin connector cable but with PDI two of these pins are unused. He took this opportunity to reroute the chip’s TX and RX pins through the cable, which now gives him an avenue to use a UART-to-USB adapter without adding any cables to his target board. Rather than add a second USB cable he rolled a USB hub into the mix. An LM1117 regulates the 5V USB rail down to 3.3V as a source for the target board.
The programmer being used is an Atmel ICE. As you might imagine he didn’t want to make permanent alterations to it. His modifications are all handled externally, with one IDC cable connecting the programmer to his added circuitry and another headed off to the target board. For now he’s jumpering RX/TX to the programming header but plans to route the signals on future PCBs.
[Andrew] is developing a game for the Nintendo Entertainment System (NES). Emulators are great for this, but [Andy] loves running on the real iron. To help, he’s created a dual port RAM interface for his NES. As the name implies, a dual port RAM is a memory with two separate data and address buses. The Cypress Semiconductor CY7C136 [Andy] used also includes arbitration logic to ensure that both ports don’t attempt to access the same memory cell and cause data corruption. In [Andy’s] case the NES was on one side, oblivious to the new hardware. On the other side of the dual port RAM, [Andy] installed an ATmega164 running his own custom firmware.
The new hardware gives [Andy] a live view of what’s going on in the NES’s memory. He added a live memory view/edit screen similar to the FCEUX emulator. The window runs on a PC while the game itself is running on an NES. [Andy] was even able to add rudimentary break and step features by connecting his circuit to the Non Maskable Interrupt (NMI) line of the NES. By holding the NMI asserted, the ATmega can essentially freeze the game in progress.
[Andy] has even used his circuit to teach the NES some new tricks. By reading the timer and score memory locations on Ice Hockey, he was able to create a scoreboard and goal light. Similar techniques were used to give Contra a muzzle flash light which puts Ambilight systems to shame.
We don’t know what [Andy] is planning next, but we hope it’s a source release so we can start hacking some some games ourselves!
Click past the break to see a couple of [Andy’s] Vine videos.
Continue reading “Dual Port RAM Teaches an Old NES New Tricks”
A serial monitor is an easy way to debug your projects. As we step through code, it’s nice to see a “Hey! I’m working, moving to next thing!” across the monitor, and not so nice to see nothing – the result of a bug that needs debugging. This has always meant needing a PC loaded with your favorite serial terminal program close at hand.
Most of the time this is not an issue, because the PC is used to compile the code and program the project at hand. But what if you’re in the field, with a mission of fixing a headless system, and in need a serial monitor? Why lug around your PC when you can make your own External Serial Monitor!
[ARPix] built this fully functional serial monitor based on an Atmega328 and a 102 x 64 LCD display. While it doesn’t have a keyboard port like this microcontroller based serial terminal, tact switches allow access to the user interface to start and stop the reading and set the baud rate. The Atmega328 has 2K of SRAM, which is needed for the project. Apparently, 1K was not enough to handle all the data. All code, schematics and a very well done parts layout are available, making this sure to be your next weekend project!
Very few people know assembly. [Luto] seeks to make learning assembly just a little bit easier with his “fully functional web-based assembler development environment, including a real assembler, emulator and debugger.”
These days, you can be a microcontroller expert without knowing a thing about assembly. While you don’t NEED to know assembly, it actually can help you understand quite a bit about embedded programming and how your C code actually works. Writing a small part of your code in assembly can reduce code size and speed things up quite a bit. It also can result in some very cool projects, such as using Java to program microcontrollers.
With high quality example code, it is very easy to get started learning assembly. The emulator consists of a microcontroller with 32 registers, hooked up to three LEDs, two buttons, and a potentiometer. This is way better than painfully learning assembly on real hardware. Be sure to check out the online demo! Being able to step through each line of code and clearly see the result help make assembly easier to use and understand. It would be great to see this kind of tool widely adopted in engineering programs.
Have you used assembly in any of your projects? Let us know how it went and why you choose to use assembly
Oh that title is so misleading. But if you squint your eyes and scratch your noggin it’s almost true. Thanks to the hard work of [Peter Lawrence] it is now possible to hack together an extremely inexpensive CMSIS-DAP ARM debugger.
Let’s talk about function and we’ll get back to cost later. CMSIS-DAP is a standard that gives you the kind of breakpoint control you expect from a proper debugger. In this case [Peter] implemented the standard using 4k words of space on a PIC 16F1454. This lets it talk to the debug port on ARM chips, and the bootloader (also written by him) doubles as a USB-to-UART bridge. Boom, done. OpenOCD (and a couple of other software packages) talks to the PIC and it talks to the ARM. Nice.
Back to the cost question. You can get a 16F1454 for nearly a dollar when you order in quantity. If you cut up an old USB cable, recycle some jumper wire, and already have power and decoupling on hand, you’re in business for nearly one dollar.
The folks at Matasano Security and Square have teamed up to build an online capture the flag (CTF) competition. The Microcorruption CTF focuses on embedded security and challenges players to reverse engineer a fictional “Lockitall LockIT Pro” lock system.
Each level places you in a debugging environment with a disassembly listing, live memory view, register view, and debugging console. You can set breakpoints, step through code, and modify registers like in a real debugging environment. Your goal is to figure out how to bypass the lock to collect bearer bonds.
While the device and motive may be fictional, the assembly is actual MSP430 code. The debugger is similar to GDB connected to a remote target using OpenOCD. There’s even a manual (PDF) to help you get up to speed with writing MSP430 code for the device.
This CTF looks like a great introduction to embedded security, and doesn’t require buying real hardware. It even includes a full tutorial to get you started.
It looks as though Texas Instruments are really reaching out to the hacker community with their new ARM-powered Stellaris dev board. On the Stellarisiti forums, a member asked about the debugging options for the Stellaris board. The Stellaris already features an In-Circuit Debug Interface (ICDI), but unfortunately it’s a little hard to get working in Linux-ey environments.
One of the devs for the Open On-Chip Debugger was already talking with TI to get the ICDI spec released for the Stellaris board. TI released the info, and after quite a bit of work, everything is open for all to see.
Right now, OpenOCD support for the Stellaris is still incomplete, but there is an project up on the Gits that allows for multi-platform development for TI’s new board.
Needless to say, getting everything up and running is still a chore. That’s not really a concern, though; the Stellaris has only been around for a few months and it takes devs time to put all the required tools into nice, neat packages. We’re just glad TI is being so forthcoming with the relevant documentation, lest development becomes a million times harder.