VS Electronics and Embedded Development

Per has brought to my attention that the JTAG Wiggler schematic on the “JTAG Wigger Clone” page has an error. I jumbled up the P4/P3 connections on the parallel port when I was adapting the schematic in EAGLE (the schematic is based on this one http://jtag-arm9.sourceforge.net/circuit.txt). I have fixed this error in the JTAG Wiggler schematic image, and I also posted the EAGLE schematic file.

Thanks to Per for bringing up the error.
I apologize for this mistake and I’ll do my best to look out for them in the future.

I’ve been pretty busy lately… I recently designed and built my Science Fair project board–I’m still working out all of the bugs in the hardware, but I’m getting there. The project is about embedded networking and encryption on an ARM microcontroller (I chose the Philips LPC2148). I’ll post full details on the project when I’m done with it.

This was my first real PCB. It is almost completely all surface mount, with the exception of a few headers, serial port and stuff like that. The passive component’s size is 0805, which I thought would be a good start with smt. I discovered that smt is awesome. It is much more convenient than through-hole, and you don’t have to reach around and flip the board in all kinds of directions if you need to desolder something.

Since I had little time after developing the schematic in two weeks, I rush designed the board in about 3 days. In the end, not too bad. I chose the wrong component packages for a few things, but I made them fit when I soldered them down. That’s all cosmetics. As for true design mistakes, I shared the TXD0 and RXD0 UART pins of the microcontroller with chip select and interrupt pins on an ethernet controller which happens to hold them high (thus screwing up my uart channel), and I think I messed up the SO/SI - MISO/MOSI lines on the spi. Well, it’s all correctable with wire wrap wire.

Continue reading for more info and cool pictures. 

__(’Read the rest of this entry »’)

I’m not entirely new to microcontrollers, although I’ve never been around the ARM ones. Most of my experience comes from the Atmel AVR line of microcontrollers, but I still consider myself a noob.

The JuiceBox is a great dev board to learn on. Everything is production prewired, all you have to do is write the code to work it…

Today I have made some significant progress with the general understanding of this embedded hardware. Using just JTAG/OCDCommander, the datasheet, and the register definitions in s3c44b0x.h, I have gotten two different parts of the board to work. First, the buttons. This was pretty easy, since I have worked with the idea of setting the direction of a port and manipulating the port in the past.

The buttons of the juicebox are located on port G, so two primary registers are involved: PCONG and PDATG. The first one being the direction of the port (16-bit register, 2 bits per pin to be: input, output, special), and the second one being the data representing that port (8-bit). Instead of fumbling with the math and finding the bitwise masks required to push certain buttons, I simply read the PDATG back in OCDCommander with different buttons pressed at different times, and then defined these values in my own code to be easily accessible and easily compared to PDATG. I get this in the end:

#define JB_PLAY 0×9D
#define JB_RETURN 0×9E
#define JB_STAR 0×8F
#define JB_FORWARD 0×9B
#define JB_REVERSE 0×97
#define JB_ATREST 0×9F

To use the port G, I first set the direction of the whole port to input (pcong = 0×0000;), and then the data on port G can be directly compared to these constants. It works great.

Since this worked out of the box so well, I decided to write my own UART interface. I am familiar with UART in general (used it a lot in the AVRs), so I have a basic understanding of how it works. The init() and putc() of my UART interface also surprisingly worked out of the box, but the getc() still needs a bit of work (it half works). When I’m done, I’ll post the UART interface code.

JB Button Test Source Code (prints out in the LCD what button you have pressed), precompiled elf included as well:
http://www.frozeneskimo.com/electronics/wp-content/uploads/Software/JBButtons.zip
Note: I take absolutely no responsibility for any damage this software may cause.

After writing the game itself for the first time on my computer, I proceeded to clean up some of the LCD Demo Code and then port the Game of Life to the JuiceBox. It uses the whole screen as the grid of cells, and each individual pixel as a cell. The initial grid is randomly generated (although not really random at all, it uses the very psuedo-rand() included in the LCD demo code), and then the generations pass by forever, with 5 milliseconds rest in between. Each pixel changes color (any color but black) when it is replotted, just to make them look cool.

Since births and deaths simultaneously occur in the Game of Life, you can’t modify a grid directly when applying the three rules of the game. Originally I kept a temporary copy grid that would be checked, while the original would be modified. But, due to memory limitations on the JuiceBox itself, I had to rewrite the grids to use a more complex “marked for death/birth” status in the cells. Anyway, it runs perfectly, and it’s pretty cool to watch.

Here is a picture of a sample game, near the beginning:

Here is it towards the end, when it is rather stable:

If you want to try it for yourself, here is the elf file that can be downloaded with OCD Commander or similar program to your JuiceBox (given you have a JTAG emulator as well): gol.elf
I take absolutely no responsibility for any damage this software may cause.
I will post the sources shortly…

Next project is learning to use those buttons and I/O ports on this ARM chip.

Shortly after I got my JTAG Wiggler working with the JuiceBox, I hunted out some homebrew code precompiled for the JuiceBox. I found it here: http://www.elinux.org/wiki/JuiceBoxCodeTest

Using OCD Commander you can easily upload the code to the processor’s memory through a JTAG emulator, and it will automatically set the PC register to the start of the program. All you have to do is hit go, and your program is running.

I played with the LCD demos, and modified the second one to print a greeting message, which I took a picture of to post here:

My next familiarization project is to port, for the first time ever, the game of life to the JuiceBox. I will have pictures of this tomorrow when the project is complete. It shouldn’t be too difficult, since the LCD demo code has shows how to drive the LCD and plot pixels.

In addition, I want to mess with the buttons. They are located on PORTG, but I still have yet to learn how I am supposed to properly manipulate the PORT registers on this ARM chip…

I love JTAG and $15 ARM development boards.

After realizing where I messed up in building my Wiggler JTAG dongle, I fixed the small problems and connected it back to the computer. I ran jtag (from openwince project) and detect’d the Wiggler… it worked flawlessly. Here was the output:

jtag> cable parallel 0×378 WIGGLER
Initializing Macraigor Wiggler JTAG Cable on parallel port at 0×378
jtag> detect
IR length: 4
Chain length: 1
Device Id: 00011111000011110000111100001111
Manufacturer: Samsung
Part: s3c44b0x
Stepping: 0
Filename: /usr/local/share/jtag/samsung/s3c44b0x/s3c44b0x
jtag>

In addition, I ran ocdremote, which recognized the Wiggler, connected to it immediately, and setup the local TCP server for GDB to connect to. I ran the arm-elf-insight (Insight is a standalone frontend to GDB) that is packaged with the GNUARM toolchain, and connected to OCDRemote. After the connection I could view all of the juicebox’s CPU registers and internal RAM. I could also step through the program instructions.

Now I’m compiling jtager over cygwin so I can dump the internal RAM of the CPU and compare some of it to the chunks that are posted on the linuxhacker forums…

Soon I’ll write a tutorial for integrating OCDRemote with GDB with Code::Blocks, so people can easily develop and debug all ARM7 projects through Code::Blocks. Finally, I can uninstall eclipse.

After frying my last juicebox (long story), I bought another one off ebay and it recently arrived. Finally I have had some time to get it up to speed (open it up, solder the sd/mmc lines, solder the UART lines). It is working great, and for the first time I am seeing the kernel boot messages, which I have posted here. Read on to see pictures and more information.

__(’Read the rest of this entry »’)

Well, I finally got around to building the JTAG Wiggler emulator on a perf board. As with most perf boards, it looks ugly, but the joints are good (I’ve gotten better). Next step is to test it… Since my LPC2148 development board is still enroute for its replacement, I guess I’ll be testing this wiggler in my juicebox projects…

See the JTAG Wiggler page for more information…

I was searching around for IDEs with GDB support I could potentially use on Windows, and I didn’t find many. There was of course Eclipse, which as you might know I really don’t like, there are a few small text editors that support invoking Makefiles, and then there was Code::Blocks. Code::Blocks looks really nifty. The setup is only 4mb, and it installed with no problems. My first impressions were that it was robust, capable of handling a wide variety of projects, and definitely configurable.

It defaults to using a specified compiler and on-the-fly writing of its own makefile based on your project. After messing around a bit, I found out in the faq how to set the IDE to use a custom makefile. Code::Blocks now calls a custom makefile with make and builds ARM project code perfectly (easily compiled the demo lpc2148 project).

The IDE, along with all of the standard features you would expect, supports debugging, specifically with GDB. This is very useful, and once I figure it out, it can be my complete replacement for the memory-eating Eclipse. I’ve been running Code::Blocks for a while now, and it is using under 10mb of memory. Code::Blocks’ GUI is built on the wxWidgets toolkit (cross-platform).

Soon I’ll post a guide to setting it up to use custom Makefiles, and when I figure it out, setting it up to use OCDRemote and gdb for ARM debugging.

Well, following the famous “ARM Cross Development with Eclipse Tutorial“, I setup the ARM-GCC toolchain and installed several other programs necessary to compile, flash and debug ARM code for my lpc2148 board.

I’ll start off by saying that Eclipse is a nasty piece of crap, no matter what you think. It shouldn’t take a 2.0ghz 1gig computer to edit a file and call a few programs. An IDE should be clean, simple, and fast (Eclipse lacking the latter). It’s Java, really. I don’t think that in today’s world the cross-compatibility is worth the performance it forgoes.

So, realizing half-way through the tutorial that in this embedded gnu environment Eclipse does nothing but essentially call make and take up 200megs of memory to edit main.c, I decided that I could use another tiny IDE I already happen to have installed, “Programmers Notepad“. This thing is packaged with WinAVR and I use it for my AVR projects. It’s nothing special, really, but it delivers almost everything you need in a notepad and fast IDE. WinAVR happened to configure it to have menu options to call make all, make clean, make program. Since I have the whole arm-gcc toolchain setup with the windows path, it can compile the demo ARM projects out of the box.

The next issue is debugging with gdb. This is the main reason eclipse is still installed, as it is currently my only option for using the whole ocdremote and arm-gdb setup. Although for the first part of my project debugging isn’t necessarily crucial, it might be necessary as the code becomes more complex. As for eclipse, I’m aiming to get rid of it altogether–Programmer’s Notepad is one step, but hopefully I can build an IDE entirely with vim. However, I don’t think I could build a fully functioning IDE with vim because integrating gdb might be impossible. Eclipse provides several built-in windows to watch the system registers and memory, but this doesn’t seem to feasible with vim alone. Maybe I should just use vim as my editor and compiling IDE, and then use some very light but capable gdb frontend, I dunno. As long as it’s not eclipse.