using git to track marmoset svn repository

I'm doing some work on marmoset this summer. As an experiment, I'm doing my development in a git repository, using git-svn to track changes in the main svn repository. My changes are somewhat experimental, so I didn't want to commit to svn HEAD, and svn branches are so 1990s. We'll see how it goes. I'm also pushing my changes to a publically-visible git repos:

http://faculty.ycp.edu/~dhovemey/marmoset.git

Greatest Song Ever

Here's a screenshot of Pandora playing the greatest song ever:

Some of the things I was obsessed with in high school haven't stood the test of time, but The Smiths most definitely have.

gdb debugging using simavr

I just got debugging using gdb working with simavr. It's as simple as putting

avr->gdb_port = 1234;
avr->state = cpu_Stopped;
avr_gdb_init(avr);

in the code that preceeds the simulation loop. Then, start avr-gdb (using the name of your firmware ELF file as the executable), and issue the command "target remote localhost:1234". Presto, you're debugging your firmware. Sweet.

simavr

One of the headaches of developing code for an embedded system is the difficulty of debugging target code. I suppose you can use an ICE if you have money and expertise, but a nice simple alternative is a software simulator.

I just discovered simavr, which is an open-source software simulator for AVR microcontrollers. It is a library which simulates a variety of AVR cores, and has hooks through which you can emulate hardware (such as devices attached to I/O pins). The idea is you write a C program which defines your hook functions, and then call into the library to run the actual simulation.

I was able to get a "blinking LED" program working in a couple hours by adapting the example code. I used ANSI control sequences to visualize the pins of an output port, but you can use any kind of UI you want. It looks as though simavr supports debugging of the target firmware using gdb, which is totally awesome. I will try that next.

Fare thee well, Firefox?

Is it just me, or has firefox gotten to be intolerably slow to start up? I've timed it, and 10-15 seconds is not unusual on the computers I use.

I'm trying out Google Chrome, and I have to say, it seems a lot more responsive.

It doesn't seem all that long ago that I was trying out Phoenix (remember when it was called that?) and it was the best browser out there. I think Firefox was more or less perfect fairly early in its development. I can distinctly remember thinking, in the 2.0 days, "Why is development continuing? It already does everything it needs to do."

I suppose in 10 years I'll be posting about how bloated Chrome has become.

Makefiles 101

Just finished up some lecture notes on building C/C++ programs using a makefile:

http://faculty.ycp.edu/~dhovemey/spring2010/cs320/lecture/lecture23.html

I think I've covered the essential concepts and techniques, although I should probably include a complete example (program and makefile). We'll see how it goes in class...

More progress on OO language interpreter

Garbage collection is now (I think?) working in Thud, my object-oriented scripting language:

[dhovemey@nobby]$ cat LongLoop.thud
# With the heap set to 8192 objects,
# this program causes the garbage collector to run.

import System::IO;

var n = 0;
while (n < 9000) {
 n = n + 1;
}

IO.out.println(n);
[dhovemey@nobby]$ thud LongLoop.thud
9000

At this point, the compiler and bytecode interpreter are more or less working. What remains is to add all of the standard library classes needed to make it a useful language: I/O, containers, regular expressions, etc.

I began this project with the idea that implementing a language like Python or Ruby would be a fairly easy task. Well, it was harder than I thought it would be, but really not that hard overall. Right now, there are about 15,000 lines of source, including comments and whitespace. This is bloated somewhat by the 2,500 or so lines generated by bison for the parser, and also the fact that I essentially recreated the Java I/O classes (streams, readers/writers, etc.) rather than use iostreams.

[Aside: is it just me, or is iostreams ridiculously complicated?]

Eventually, I'm hoping to use Thud as my main day-to-day scripting language. In the longer term, it would be an interesting project to replace the bytecode-interpreter-based virtual machine with one based on LLVM.