First thoughts on the Teensy 3.1

Wow it has been a while; I have not written since August.

I entered a contest of sorts this past week which involves building an autonomous turret which uses an ultrasonic sensor to locate a target within 10 feet and fire at it with a tiny dart gun. The entire assembly is to be mounted on servos. This is something my University is doing as an extra-curricular for engineers and so when a friend of mine asked if I wanted to join forces with him and conquer, I readily agreed.

The most interesting part to me, by far, is the processor to be used. It is going to be a Teensy 3.1:

Teensy 3.1

Teensy 3.1

This board contains a Freescale ARM Cortex-M4 microcontroller along with a smaller non-user-programmable microcontroller for assistance in the USB bootloading process (the exact details of that interaction are mostly unknown to me at the moment). I have never used an ARM microcontroller before and never a microcontroller with as many peripherals as this one has. The datasheet is 1200 pages long and is not really even being very verbose in my opinion. It could easily be 3000 pages if they included the level of detail usually included in AVR and PIC datasheets (code examples, etc). The processor runs at 96Mhz as well, making it the most powerful embedded computer I have used aside from my Raspberry Pi.

The Teensy 3.1 is Arduino-compliant and is designed that way. However, it can also be used without the Arduino software. I have not used an Arduino before since I rather enjoy using microcontrollers in a bare-bones fashion. However, it is become increasingly more difficult for me to be able to experiment with the latest in microcontroller developments using breadboards since the packages are becoming increasingly more surface mount.

The Arduino IDE

Oh my goodness. Worst ever. Ok, not really, but I really have a hard time justifying using it other than the fact that it makes downloading to the Teensy really easy. This post isn’t meant to be a review of the arduino IDE, but the editor could use some serious improvements IMHO:

  • Tab indentation level: Some of us would like to use something other than 2 spaces, thank you very much. We don’t live in the 70′s where horizontal space is at a premium and I prefer 4 spaces. Purely personal preference, but I feel like the option should be there
  • Ability to reload files: The inability to reload the files and the fact that it seems to compile from a cache rather than from the file itself makes the arduino IDE basically incompatible with git or any other source control system. This is a serious problem, in my opinion, and requires me to restart the editor frequently whenever I check out a different branch.
  • Real project files: I understand the aim for simplicity here, but when you have a chip with 256Kb of flash on it, your program is not going to be 100 lines and fit into one file. At the moment, the editor just takes everything in the directory and compiles it by file extension. No subdirectories and every file will be displayed as a separate tab with no way to close it. I am in the habit of separating my source and not having the ability to structure my files how I please really makes me feel hampered. To make matters worse, the IDE saves the original sketch file (which is just a cpp file that will be run through their preprocessor) with its own special file extension (*.ino) which makes it look like it should be a project file, but in reality it is not.

There are few things I do like, however. I do like their library of things that make working with this new and foreign processor rather easy. I also like that their build system is very cross-platform and easy to use.

First impression of the processor

I must first say that the level of work that has gone into the surrounding software (the header files, the teensy loader, etc) truly shows and makes it a good experience to use the Teensy, even if the Arduino IDE sucks. I tried a Makefile approach using Code::Blocks, but it was difficult for me to get it to compile cross-platform and I was afraid that I would accidentally overwrite some bootloader code that I hadn’t known about. So, I ended up just going with the Ardiuno IDE for safety reasons.

The peripherals on this processor are many and it is hard at times to figure out basic functions, such as the GPIO. The manual for the peripherals is in the neighborhood of 60 chapters long, with each chapter describing a peripheral. So far, I have messed with just the GPIOs and pin interrupts, but I plan on moving on to the timer module very soon. This project likely won’t require the DMA or the variety of onboard bus modules (CAN, I2C, SPI, USB, etc), but in the future I hope to have a Teensy of my own to experiment on. The sheer number of registers combined with the 32-bit width of everything is a totally new experience for me. Combine that with the fact that I don’t have to worry as much about the overhead of using certain C constructs (struct and function pointers for example) and I am super duper excited about this processor. Tack on the stuff that PJRC created for using the Teensy such as the nice header files and the overall compatibility with some Arduino libraries, and I have had an easier time getting this thing to work than with most of my other projects I have done.

Conclusion

Although the Teensy is for a specific contest project right now, at the price of $19.80 for the amount of power that it gives, I believe I will buy one for myself to mess around with. I am looking forward to getting more familiar with this processor and although I resent the IDE I have to work with at the moment, I hope that I will be able to move along to better compilation options that will let me move away from the arduino IDE.

Pop ‘n Music controller…AVR style

Every time I do one of these bus emulation projects, I tell myself that the next time I do it I will use an oscilloscope or DLA. However, I never actually break down and just buy one. Once more, I have done a bus emulation project flying blind. This is the harrowing tale:

Code & Schematics (kicad): https://github.com/kcuzner/pop-n-music-controller

Introduction

A couple of days ago, I was asked to help do some soldering for a modification someone was trying to do to a PS1 controller. He informed me that it was for the game Pop ‘n Music and that it required a special controller to be played properly. Apparently, official controllers can sell for $100 or more, so modifying an existing controller was the logical thing to do. After much work and pain, it was found that while modifying an existing controller was easy, it wasn’t very robust and could easily fall apart and so I built one using an ATMega48 and some extra components I had lying around. The microcontroller emulates the PSX bus which is used to communicate between the controller and the playstation/computer. As my reference for the bus, I used the following two web pages:

The complete schematics and software can be found on my github.

The first attempt: Controller mod

The concept behind the controller mod was simple: Run wires from the existing button pads to some arcade-style buttons arranged in the pattern needed for the controller. It worked well at first, but after a little while we began to have problems:

  • The style of pad that he purchased had conductive rubber covering all of the copper for the button landings. In order to solder to this, it was necessary to scrape off the rubber. This introduced a tendency for partially unclean joints, giving rise to cold connections. While with much effort I was able to mitigate this issue (lots of scraping and cleaning), the next problem began to manifest itself.
  • The copper layout for each button pad was of a rather minimalist design. While some pads shown online had nice large areas for the button to contact, this particular controller had 50-100 mil lines arranged in a circular pattern rather than one huge land. While I imagine this is either economical or gives better contact, it sure made soldering wires onto it difficult. I would get the wire soldered, only to have it decide that it wanted to come off and take the pad with it later. This was partly due to bad planning on my part and using wire that wasn’t flexible enough, but honestly, the pads were not designed to be soldered to.
  • With each pad that lifted, the available space for the wires on certain buttons to be attached to began to become smaller and smaller. Some buttons were in the large land style and were very easy to solder to and the joints were strong (mainly the arrow pad buttons). The issue was with the start and select buttons (very narrow) and the X, square, triangle, and O buttons (100mil spiral thing mentioned earlier). Eventually, I was resorting to scraping the solder mask off and using 30awg wire wrapping wire to solder to the traces. It just got ridiculous and wasn’t nearly strong enough to hold up as a game controller.
  • In order for the controller to be used with a real playstation, rather than an emulator, the Left, Right, and Down buttons had to be pressed at the same time to signify to the game that it was a Pop ‘n Music controller. Emulators generally can’t handle this sort of behavior when mapping the buttons around, so putting a switch was considered. However, any reliable switch (read: Nice shiny toggle switch) was around $3. Given the low cost aim of this project, it was becoming more economical to explore other options

So, we began exploring other options. I found this site detailing emulation of these controllers using either 74xx logic or a microcontroller. It is a very good resource, and is mostly correct about the protocol. After looking at the 74xx logic solution and totaling up the cost, I noticed that my $1.75 microcontroller along with the required external components would actually come out to be cheaper than buying 4 chips and sockets for them. Even better, I already had a microcontroller and all the parts on hand, so there was no need for shipping. So, I began building and programming.

AVR PSX Bus Emulation: The Saga of the Software

PSX controllers communicate using a bus that has a clock, acknowledge, slave select, psx->controller (command) line, and controller->psx (data) line. Yes, this looks a lot like an SPI bus. In fact, it is more or less identical to a SPI Mode 3 bus with the master-in slave-out line driven open collector. I failed to notice this fact until later, much to my chagrin. Communication is accomplished using packets that have a start signal followed by a command and waiting for a response from the controller. During the transaction, the controller declares its type, the number of words that it is going to send, and the actual controller state. I was emulating a standard digital controller, so I had to tell it that my controller type was 0×41, which is digital with 1 word data. Then, I had to send a 0x5A (start data response byte) and two bytes of button data. My initial approach involved writing a routine in C that would handle pin changes on INT0 and INT1 which would be connected to the command and clock lines. However, I failed to anticipate that the bus would be somewhere in the neighborhood of 250Khz-500Khz and this caused some serious performance problems and I was unable to complete a transaction with the controller host. So, I decided to try writing the same routine in assembly to see if I could squeeze every drop of performance out of it possible. I managed to actually get it to complete a transaction this way, but without sending button data. To make matters worse, every once in a while it would miss a transaction and this was quite noticeable when I made an LED change state with every packet received. It was very inconsistent and that was without even sending button data. I eventually realized the problem was with the fact that making the controller do so much between cycles of the clock line actually caused it to miss bits. So, I looked at the problem again. I noticed that the ATMega48A had an SPI module and that the PSX bus looked similar, but not exactly like, an SPI bus. However, running the bus in mode 3 with the data order reversed and the MISO driving the base of a transistor operating in an open-collector fashion actually got me to be able to communicate to the PSX bus on almost the first try. Even better, the only software change that had to be made was inverting the data byte so that the signal hitting the base of the transistor would cause the correct changes on the MISO line. So, I hooked up everything as follows:

Pop 'n Music Controller Schematic

Pop ‘n Music Controller Schematic

After doing that, suddenly I got everything to work. It responded correctly to the computer when asked about its inputs and after some optimization, stopped skipping packets due to taking too much time processing button inputs. It worked! Soon after getting the controller to talk to the computer, I discovered an error in the website I mentioned earlier that detailed the protocol. It mentioned that during transmission of the data about the buttons that the control line was going to be left high. While its a minor difference, I thought I might as well mention this site, which lists the commands correctly and was very helpful. As I mentioned before, one problem that was encoutered was that in order for the controller to be recognized as a pop-n-music controller by an actual playstation, the left, right, and down buttons must be pressed. However, it seems that the PSX->USB converter that we were using was unable to handle having those 3 pressed down at once. So, there needed to be a mode switch. The way for switching modes I came up with was to hold down both start and select at the same time for 3 seconds. After the delay, the modes would switch. The UI interaction for this is embodied in two LEDs. One LED is lit for when it is in PSX mode and the other when it is in emulator mode. When both buttons are pressed, both LEDs light up until the one for the previous mode shuts off. At first, I had the mode start out every time the controller was started in the same mode, no matter what the previous mode was before it was shut off. It soon became apparent that this wouldn’t do, and so I looked in to using the EEPROM to store the flag value I was using to keep the state of the controller. Strangely, it worked on the first try, so the controller will stay in the same mode from the last time it was shut off. My only fear is that switching the mode too much could degrade the EEPROM. However, the datasheet says that it is good for 100,000 erase/write cycles, so I imagine it would be quite a while before this happens and other parts of the controller will probably fail first (like the switches).

On to the hardware!

I next began assembly. I went the route of perfboard with individual copper pads around each hole because that’s what I have. Here are photos of the assembly, sadly taken on my cell phone because my camera is broken. Sorry for the bad quality…

Socket and PSX plug mouted

Socket and PSX plug mouted

Wiring between PSX plug and socket

Wiring between PSX plug and socket

Adding some transistors...first try

Adding some transistors…first try

Adding the transistors, try 2

Adding the transistors, try 2

Wiring almost done

Wiring almost done

Inside of switch box

Inside of switch box

Controller assembled

Controller assembled

The controller in action

The controller in action

Conclusion

So, with the controller in the box and everything assembled, it seems that all will be well with the controller. It doesn’t seem to miss keypresses or freeze and is able to play the game without too many hiccups (the audio makes it difficult, but that’s just a emulator tweaking issue). The best part about this project is that in terms of total work time, it probably took only about 16 hours. Considering that most of my projects take months to finish, this easily takes the cake as one of my quickest projects start to finish.

Raspberry Pi as an AVR Programmer

Introduction

Recently, I got my hands on a Raspberry Pi and one of the first things I wanted to do with it was to turn it into my complete AVR development environment. As part of that I wanted to make avrdude be able to program an AVR directly from the Raspberry Pi with no programmer. I know there is this linuxgpio programmer type that was recently added, but it is so recent that it isn’t yet included in the repos and it also requires a compile-time option to enable it. I noticed that the Raspberry Pi happens to expose its SPI interface on its expansion header and so I thought to myself, “Why not use this thing instead of bitbanging GPIOs? Wouldn’t that be more efficient?” Thus, I began to decipher the avrdude code and write my addition. My hope is that things like this will allow the Raspberry Pi to be used to explore further embedded development for those who want to get into microcontrollers, but blew all their money on the Raspberry Pi. Also, in keeping with the purpose that the Raspberry Pi was originally designed for, using it like this makes it fairly simple for people in educational surroundings to expand into different aspects of small computer and embedded device programming.

As my addition to avrdude, I created a new programmer type called “linuxspi” which uses the userspace SPI drivers available since around Linux ~2.6 or so to talk to a programmer. It also requires an additional GPIO to operate as the reset. My initial thought was to use the chip select as the reset output, but sadly, the documentation for the SPI functions mentioned that the chip enable line is only held low so long as the transaction is going. While I guess I could compress all the transactions avrdude makes into one giant burst of data, this would be very error prone and isn’t compatible with avrdude’s program structure. So, the GPIO route was chosen. It just uses the sysfs endpoints found in /sys/class/gpio to manipulate a GPIO chosen in avrdude.conf into either being in a hi-z input state or an output low state. This way, the reset can be connected via a resistor to Vcc and then the Raspberry Pi just holds reset down when it needs to program the device. Another consequence which I will mention here of choosing to use the Linux SPI drivers is that this should actually be compatible with any Linux-based device that exposes its SPI or has an AVR connected to the SPI; not just the Raspberry Pi.

Programming an AVR

Raspberry Pi Programming an AVR

Usage

So, down to the nitty gritty: How can I use it? Well, at the moment it is in a github repository at https://github.com/kcuzner/avrdude. As with any project that uses the expansion header on the Raspberry Pi, there is a risk that a mistake could cause your Raspberry Pi to die (or let out the magic smoke, so to speak). I assume no responsibility for any damage that may occur as a result of following these directions or using my addition to avrdude. Just be careful when doing anything involving hooking stuff up to the expansion port and use common sense. Remember to measure twice and cut once. So, with that out of the way, I will proceed to outline here the basic steps for installation and usage.

Installation

The best option here until I bother creating packages for it is to  do a git clone directly into a directory on the Raspberry Pi and build it from there on the Raspberry Pi itself. I remember having to install the following packages to get it to compile (If I missed any, let me know):

  • bison
  • autoconf
  • make
  • gcc
  • flex

Also, if your system doesn’t have a header at “linux/spi/spidev.h” in your path, you probably need to install that driver. I was using Arch Linux and it already had the driver there, so for all I know its always installed. You also should take a look to make sure that “/dev/spidev0.0″ and “/dev/spidev0.1″ or something like that exist. Those are the sort of endpoints that are to be used with this. If they do not exist, try executing a “sudo modprobe spi_bcm2708″. If the endpoints still aren’t there after that, then SPI support probably isn’t installed or enabled for your kernel.

After cloning the repo and installing those packages, run the “./boostrap” script which is found in the avrdude directory. This will run all the autoconf things and create the build scripts. The next step is to run “./configure” and wait for it to complete. After the configure script, it should say whether or not “linuxspi” is enabled or disabled. If it is disabled, it was not able to find the header I mentioned before. Then run “make” and wait for it to complete. Remember that the Raspberry Pi is a single core ARM processor and so building may take a while. Afterwards, simply do “sudo make install” and you will magically have avrdude installed on your computer in /usr/local. It would probably be worthwhile to note here that you probably want to uninstall any avrdude you may have had installed previously either manually or through a package manager. The one here is built on top of the latest version (as of May 26th, 2013), so it should work quite well and be all up to date and stuff for just using it like a normal avrdude. I made no changes to any of the programmer types other than the one I added.

To check to see if the avrdude you have is the right one, you should see an output similar to the following if you run this command (tiny-tim is the name of my Raspberry Pi until I think of something better):

kcuzner@tiny-tim:~/avrdude/avrdude$ avrdude -c ?type

Valid programmer types are:
  arduino          = Arduino programmer
  avr910           = Serial programmers using protocol described in application note AVR910
  avrftdi          = Interface to the MPSSE Engine of FTDI Chips using libftdi.
  buspirate        = Using the Bus Pirate's SPI interface for programming
  buspirate_bb     = Using the Bus Pirate's bitbang interface for programming
  butterfly        = Atmel Butterfly evaluation board; Atmel AppNotes AVR109, AVR911
  butterfly_mk     = Mikrokopter.de Butterfly
  dragon_dw        = Atmel AVR Dragon in debugWire mode
  dragon_hvsp      = Atmel AVR Dragon in HVSP mode
  dragon_isp       = Atmel AVR Dragon in ISP mode
  dragon_jtag      = Atmel AVR Dragon in JTAG mode
  dragon_pdi       = Atmel AVR Dragon in PDI mode
  dragon_pp        = Atmel AVR Dragon in PP mode
  ftdi_syncbb      = FT245R/FT232R Synchronous BitBangMode Programmer
  jtagmki          = Atmel JTAG ICE mkI
  jtagmkii         = Atmel JTAG ICE mkII
  jtagmkii_avr32   = Atmel JTAG ICE mkII in AVR32 mode
  jtagmkii_dw      = Atmel JTAG ICE mkII in debugWire mode
  jtagmkii_isp     = Atmel JTAG ICE mkII in ISP mode
  jtagmkii_pdi     = Atmel JTAG ICE mkII in PDI mode
  jtagice3         = Atmel JTAGICE3
  jtagice3_pdi     = Atmel JTAGICE3 in PDI mode
  jtagice3_dw      = Atmel JTAGICE3 in debugWire mode
  jtagice3_isp     = Atmel JTAGICE3 in ISP mode
  linuxgpio        = GPIO bitbanging using the Linux sysfs interface (not available)
  linuxspi         = SPI using Linux spidev driver
  par              = Parallel port bitbanging
  pickit2          = Microchip's PICkit2 Programmer
  serbb            = Serial port bitbanging
  stk500           = Atmel STK500 Version 1.x firmware
  stk500generic    = Atmel STK500, autodetect firmware version
  stk500v2         = Atmel STK500 Version 2.x firmware
  stk500hvsp       = Atmel STK500 V2 in high-voltage serial programming mode
  stk500pp         = Atmel STK500 V2 in parallel programming mode
  stk600           = Atmel STK600
  stk600hvsp       = Atmel STK600 in high-voltage serial programming mode
  stk600pp         = Atmel STK600 in parallel programming mode
  usbasp           = USBasp programmer, see http://www.fischl.de/usbasp/
  usbtiny          = Driver for "usbtiny"-type programmers
  wiring           = http://wiring.org.co/, Basically STK500v2 protocol, with some glue to trigger the bootloader.

Note that right under “linuxgpio” there is now a “linuxspi” driver. If it says “(not available)” after the “linuxspi” description, “./configure” was not able to find the “linux/spi/spidev.h” file and did not compile the linuxspi programmer into avrdude.

Configuration

There is a little bit of configuration that happens here on the Raspberry Pi side before proceeding to wiring it up. You must now decide which GPIO to sacrifice to be the reset pin. I chose 25 because it is next to the normal chip enable pins, but it doesn’t matter which you choose. To change which pin is to be used, you need to edit “/usr/local/etc/avrdude.conf” (it will be just “/etc/avrdude.conf” if it wasn’t built and installed manually like above). Find the section of the file that looks like so:

programmer
  id = "linuxspi";
  desc = "Use Linux SPI device in /dev/spidev*";
  type = "linuxspi";
  reset = 25;
;

The “reset = ” line needs to be changed to have the number of the GPIO that you have decided to turn into the reset pin for the programmer. The default is 25, but that’s just because of my selfishness in not wanting to set it to something more generic and having to then edit the file every time I re-installed avrdude. Perhaps a better default would be “0″ since that will cause the programmer to say that it hasn’t been set up yet.

Wiring

After setting up avrdude.conf to your desired configuration, you can now connect the appropriate wires from your Raspberry Pi’s header to your microchip. A word of extreme caution: The Raspberry Pi’s GPIOs are NOT 5V tolerant, and that includes the SPI pins. You must do either one of two things: a) Run the AVR and everything around it at 3.3V so that you never see 5V on ANY of the Raspberry Pi pins at any time (including after programming is completed and the device is running) or b) Use a level translator between the AVR and the SPI. I happen to have a level translator lying around (its a fun little TSSOP I soldered to a breakout board a few years back), but I decided to go the 3.3V route since I was trying to get this thing to work. If you have not ever had to hook up in-circuit serial programming to your AVR before, perhaps this would be a great time to learn. You need to consult the datasheet for your AVR and find the pins named RESET (bar above it), MOSI, MISO, and SCK. These 4 pins are connected so that RESET goes to your GPIO with a pullup resistor to the Vcc on your AVR, MOSI goes to the similarly named MOSI on the Raspberry Pi header, MISO goes to the like-named pin on the header, and SCK goes to the SPI clock pin (named SCLK on the diagram on elinux.org). After doing this and double checking to make sure 5V will never be present to the Raspberry Pi, you can power on your AVR and it should be able to be programmed through avrdude. Here is a demonstration of me loading a simple test program I made that flashes the PORTD LEDs:

kcuzner@tiny-tim:~/avrdude/avrdude$ sudo avrdude -c linuxspi -p m48 -P /dev/spidev0.0 -U flash:w:../blink.hex 
[sudo] password for kcuzner: 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9205
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "../blink.hex"
avrdude: input file ../blink.hex auto detected as Intel Hex
avrdude: writing flash (2282 bytes):

Writing | ################################################## | 100% 0.75s

avrdude: 2282 bytes of flash written
avrdude: verifying flash memory against ../blink.hex:
avrdude: load data flash data from input file ../blink.hex:
avrdude: input file ../blink.hex auto detected as Intel Hex
avrdude: input file ../blink.hex contains 2282 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.56s

avrdude: verifying ...
avrdude: 2282 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

There are two major things to note here:

  • I set the programmer type (-c option) to be “linuxspi”. This tells avrdude to use my addition as the programming interface
  • I set the port (-P option) to be “/dev/spidev0.0″. On my Raspberry Pi, this maps to the SPI bus using CE0 as the chip select. Although we don’t actually use CE0 to connect to the AVR, it still gets used by the spidev interface and will toggle several times during normal avrdude operation. Your exact configuration may end up being different, but this is more or less how the SPI should be set. If the thing you point to isn’t an SPI device, avrdude should fail with a bunch of messages saying that it couldn’t send an SPI message.

Other than that, usage is pretty straightforward and should be the same as if you were using any other programmer type.

Future

As issues crop up, I hope to add improvements like changing the clock frequency and maybe someday adding TPI support (not sure if necessary since this is using the dedicated SPI and as far as I know, TPI doesn’t use SPI).

I hope that those using this can find it helpful in their fun and games with the Raspberry Pi. If there are any issues compiling and stuff, either open an issue on github or mention it in the comments here.

Lessons in game design…in a car!

For the greater part of this week I have been trapped in a car driving across the United States for my sister’s wedding. Of course, I had my trusty netbook with me and so I decided to do some programming. After discovering that I had unwittingly installed tons of documentation in my /usr/share/doc folder (don’t you love those computer explorations that actually reveal something?), I started building yet another rendition of Tetris in Python. I did several things differently this time and the code is actually readable and I feel like some structure things I learned/discovered/re-discovered should be shared here.

Game State Management

One problem that has constantly plagued my weak attempts at games has been an inability to do menus and manage whether the game is paused or not in a reasonably simple manner. Of course, I could always hack something together, but I could also write the whole thing in assembly language or maybe write it all as one big function in C. The issue is that if I program myself into a hole, I usually end up giving up a bit unless I am getting paid (then I generally bother thinking before programming so that I don’t waste people’s time). After finishing the game logic and actually getting things to work with the game itself, I remembered a funny tutorial I was once doing for OGRE which introduced a very simple game engine. The concept was one of a “stack” of game states. Using this stack, your main program basically injects input into and then asks a rendering from the state on the top of the stack. The states manipulate the stack, pushing a new state or popping themselves. When the stack is empty, the program exits.

My game state stack works by using an initial state that loads the resources (the render section gives back a loading screen). After it finishes loading the resources, it asks the manager to pop itself from the stack and then push on the main menu state. The menu state is quite simple: It displays several options where each option either does something immediate (like popping the menu from the stack to end the program in the case of the Quit option) or something more complex (like pushing a sub-menu state on to create a new game with some settings). After that there are states for playing the game, viewing the high scores, etc.

The main awesome thing about this structure is that switching states is so easy. Want to pause the game? Just push on a state that doesn’t do anything until it receives a key input or something, after which it pops itself. Feel like doing a complex menu system? The stack keeps track of the “breadcrumbs” so to speak. Never before have I been able to actually create an easily extensible/modification-friendly game menu/management system that doesn’t leave me with a headache later trying to understand it or unravel my spaghetti code.

The second awesome thing is that this helps encourage an inversion of control. Rather than the state itself dictating when it gets input or when it renders something, the program on top of it can choose whether it wants to render that state or whether it wants to give input to that state. I ended up using the render function like a game loop function as well and so if I wanted a state to sort of “pause” execution, I could simply stop telling it to render (usually by just pushing a state on top of it). My main program (in Python) was about 25 lines long and took care of setting up the window, starting the game states, and then just injecting input into the game state and asking the state to render a window. The states themselves could choose how they wanted to render the window or even if they wanted to (that gets into the event bubbling section which is next). It is so much easier to operate that way as the components are loosely tied to one another and there is a clear relationship between them. The program owns the states and the states know nothing about about the program driving them…only that their input comes from somewhere and the renderings they are occasionally asked to do go somewhere.

Event bubbling

When making my Tetris game, I wanted an easy to way to know when to update or redraw the screen rather than always redrawing it. My idea was to create an event system that would “notice” when the game changed somehow: whether a block had moved or maybe the score changed. I remembered of two event systems that I really really liked: C#’s event keyword plus delegate thing and Javascript’s event bubbling system. Some people probably hate both of those, but I have learned to love them. Mainly, its just because I’m new to this sort of thing and am still being dazzled by their plethora of uses. Using some knowledge I gleaned from my database abstraction project about the fun data model special function names in Python, I created the following:

class EventDispatcher(object):
    """
    Event object which operates like C# events

    "event += handler" adds a handler to this event
    "event -= handler" removes a handler from this event
    "event(obj)" calls all of the handlers, passing the passed object

    Events may be temporarily suppressed by using them in a with
    statement. The context returned will be this event object.
    """
    def __init__(self):
        """
        Initializes a new event
        """
        self.__handlers = []
        self.__supress_count = 0
    def __call__(self, e):
        if self.__supress_count > 0:
            return
        for h in self.__handlers:
            h(e)
    def __iadd__(self, other):
        if other not in self.__handlers:
            self.__handlers.append(other)
        return self
    def __isub__(self, other):
        self.__handlers.remove(other)
        return self
    def __enter__(self):
        self.__supress_count += 1
        return self
    def __exit__(self, exc_type, exc_value, traceback):
        self.__supress_count -= 1

My first thought when making this was to do it like C# events: super flexible, but no defined “way” to do them. The event dispatcher uses the same syntax as the C# events (+=, -= or __iadd__, __isub__) to add/remove handlers and also to call each handler (() or __call__). It also has the added functionality of optionally suppressing events by using them inside a “with” statement (which may actually be breaking the pattern, but I needed it to avoid some interesting redrawing issues). I would add EventDispatcher objects to represent each type of event that I wanted to catch and then pass an Event object into the event to send it off to the listening functions. However, I ran into an issue with this: Although I was able to cut down the number of events being sent and how far they propagated, I would occasionally lose events. The issue this caused is that my renderer was listening to find out where it should “erase” blocks and where it should “add” blocks and it would sometimes seem to forget to erase some of the blocks. I later discovered that I had simply forgotten to call the event during a certain function which was called periodically to move the Tetris blocks down, but even so, it got my started on the next thing which I feel is better.

Javascript events work by specifying types of events, a “target” or object in the focus of the event, and arguments that get passed along with the event. The events then “bubble” upward through the DOM, firing first for a child and then for the parent of that child until it reaches the top element. The advantage of this is that if one wants to know, for example, if the screen has been clicked, a listener doesn’t have to listen at the lowest leaf element of each branch of the DOM; it can simply listen at the top element and wait for the “click” event to “bubble” upwards through the tree. After my aforementioned issue I initially thought that I was missing events because my structure was flawed, so I ended up re-using the above class to implement event bubbling by doing the following:

class Event(object):
    """
    Instance of an event to be dispatched
    """
    def __init__(self, target, name, *args, **kwargs):
        self.target = target
        self.name = name
        self.args = args
        self.kwargs = kwargs

class EventedObject(object):
    def __init__(self, parent=None):
        self.__parent = parent
        self.event = EventDispatcher()
        self.event += self.__on_event
    def __on_event(self, e):
        if hasattr(self.__parent, 'event'):
            self.__parent.event(e)
    @property
    def parent(self):
        return self.__parent
    @parent.setter
    def parent(self, value):
        l = self.parent
        self.__parent = value
        self.event(Event(self, "parent-changed", current=self.parent, last=l))

The example here is the object from which all of my moving game objects (blocks, polyominoes, the game grid, etc) derive from. It defines a single EventDispatcher, through which Event objects are passed. It listens to its own event and when it hears something, it activates its parent’s event, passing through the same object that it received. The advantage here is that by listening to just one “top” object, all of the events that occurred for the child objects are passed to whatever handler is attached to the top object’s dispatcher. In my specific implementation I had each block send an Event up the pipeline when the were moved, each polyomino send an Event when it was moved or rotated, and the game send an Event when the score, level, or line count was changed. By having my renderer listen to just the game object’s EventDispatcher I was able to intercept all of these events at one location.

The disadvantage with this particular method is that each movement has a potentially high computational cost. All of my events are synchronous since Python doesn’t do true multithreading and I didn’t need a high performance implementation. It’s just method calls, but there is a potential for a stack overflow if either a chain of parents has a loop somewhere or if I simply have too tall of an object tree. If I attach too many listeners to a single EventDispatcher, it will also slow things down.

Another problem I have here has to do with memory leaks which I believe I have (I haven’t tested it and this is entirely in my head, thinking about the issues). Since I am asking the EventDispatcher to add a handler which is a bound method to the object which owns it, there is a loop there. In the event that I forget all references to the EventedObject, the reference count will never decrease to 0 since the EventDispatcher inside the EventedObject still holds a reference to that same EventedObject inside the bound method. I would think that this could cause garbage collection to never happen. Of course, they could make the garbage collector really smart and notice that the dependency tree here is a nice orphan tree detached from the rest and can all be collected. However, if it is a dumb garbage collector, it will probably keep it around. This isn’t a new issue for me: I ran into it with doing something like this on one of my C# projects. However, the way I solved it there was to implement the IDisposable interface and upon disposal, unsubscribe from all events that created a circular dependency. The problem there was worse because there wasn’t a direct exclusive link between the two objects like there is with this one (here one is a property of the other (strong link) and the other only references a bound method to its partner (weak…kinda…link)).

Overall, even though there are those disadvantages, I feel that the advantage gained by having all the events in one place is worth it. In the future I will create “filters” that can be attached to handlers as they are subscribed to avoid calling the handlers for events that don’t match their filter. This is similar to Javascript in that handlers can be used to catch one specific type of event. However, mine differs in that in the spirit of Python duck typing, I decided to make no distinction between types of events outside of a string name that identifies what it is. Since I only had one EventDispatcher per object, it makes sense to only have one type of event that will be fed to its listeners. The individual events can then just be differentiated by a property value. While this feels flaky to me since I usually feel most comfortable with strong typing systems, it seems to be closer to what Python is trying to do.

Conclusion

I eventually will put up this Tetris implementation as a gist or repository on github (probably just a gist unless it gets huge…which it could). So far I have learned a great deal about game design and structure, so this should get interesting as I explore other things like networking and such.

Database Abstraction in Python

As I was recently working on trying out the Flask web framework for Python, I ended up wanting to access my MySQL database. Recently at work I have been using entity framework and I have gotten quite used to having a good database abstraction that allows programmatic creation of SQL. While such frameworks exist in Python, I thought it would interesting to try writing one. This is one great example of getting carried away with a seemingly simple task.

I aimed for these things:

  • Tables should be represented as objects which each instance of the object representing a row
  • These objects should be able to generate their own insert, select, and update queries
  • Querying the database should be accomplished by logical predicates, not by strings
  • Update queries should be optimized to only update those fields which have changed
  • The database objects should have support for “immutable” fields that are generated by the database

I also wanted to be able to do relations between tables with foreign keys, but I have decided to stop for now on that. I have a structure outlined, but it isn’t necessary enough at this point since all I wanted was a database abstraction for my simple Flask project. I will probably implement it later.

This can be found as a gist here: https://gist.github.com/kcuzner/5246020

Example

Before going into the code, here is an example of what this abstraction can do as it stands. It directly uses the DbObject and DbQuery-inheriting objects which are shown further down in this post.

from db import *
import hashlib

def salt_password(user, unsalted):
    if user is None:
        return unsalted
    m = hashlib.sha512()
    m.update(user.username)
    m.update(unsalted)
    return m.hexdigest()

class User(DbObject):
    dbo_tablename = "users"
    primary_key = IntColumn("id", allow_none=True, mutable=False)
    username = StringColumn("username", "")
    password = PasswordColumn("password", salt_password, "")
    display_name = StringColumn("display_name", "")
    def __init__(self, **kwargs):
        DbObject.__init__(self, **kwargs)
    @classmethod
    def load(self, cur, username):
        selection = self.select('u')
        selection[0].where(selection[1].username == username)
        result = selection[0].execute(cur)
        if len(result) == 0:
            return None
        else:
            return result[0]
    def match_password(self, password):
        salted = salt_password(self, password)
        return salted == self.password

#assume there is a function get_db defined which returns a PEP-249
#database object
def main():
    db = get_db()
    cur = db.cursor()
    user = User.load(cur, "some username")
    user.password = "a new password!"
    user.save(cur)
    db.commit()

    new_user = User(username="someone", display_name="Their name")
    new_user.password = "A password that will be hashed"
    new_user.save(cur)
    db.commmit()

    print new_user.primary_key # this will now have a database assigned id

This example first loads a user using a DbSelectQuery. The user is then modified and the DbObject-level function save() is used to save it. Next, a new user is created and saved using the same function. After saving, the primary key will have been populated and will be printed.

Change Tracking Columns

I started out with columns. I needed columns that track changes and have a mapping to an SQL column name. I came up with the following:

class ColumnSet(object):
    """
    Object which is updated by ColumnInstances to inform changes
    """
    def __init__(self):
        self.__columns = {} # columns are sorted by name
        i_dict = type(self).__dict__
        for attr in i_dict:
            obj = i_dict[attr]
            if isinstance(obj, Column):
                # we get an instance of this column
                self.__columns[obj.name] = ColumnInstance(obj, self)

    @property
    def mutated(self):
        """
        Returns the mutated columns for this tracker.
        """
        output = []
        for name in self.__columns:
            column = self.get_column(name)
            if column.mutated:
                output.append(column)
        return output

    def get_column(self, name):
        return self.__columns[name]

class ColumnInstance(object):
    """
    Per-instance column data. This is used in ColumnSet objects to hold data
    specific to that particular instance
    """
    def __init__(self, column, owner):
        """
        column: Column object this is created for
        initial: Initial value
        """
        self.__column = column
        self.__owner = owner
        self.update(column.default)

    def update(self, value):
        """
        Updates the value for this instance, resetting the mutated flag
        """
        if value is None and not self.__column.allow_none:
            raise ValueError("'None' is invalid for column '" + \
                             self.__column.name + "'")
        if self.__column.validate(value):
            self.__value = value
            self.__origvalue = value
        else:
            raise ValueError("'" + str(value) + "' is not valid for column '" + \
                             self.__column.name + "'")

    @property
    def column(self):
        return self.__column

    @property
    def owner(self):
        return self.__owner

    @property
    def mutated(self):
        return self.__value != self.__origvalue

    @property
    def value(self):
        return self.__value

    @value.setter
    def value(self, value):
        if value is None and not self.__column.allow_none:
            raise ValueError("'None' is invalid for column '" + \
                             self.__column.name + "'")
        if not self.__column.mutable:
            raise AttributeError("Column '" + self.__column.name + "' is not" +
                                 " mutable")
        if self.__column.validate(value):
            self.__value = value
        else:
            raise ValueError("'" + value + "' is not valid for column '" + \
                             self.__column.name + "'")

class Column(object):
    """
    Column descriptor for a column
    """
    def __init__(self, name, default=None, allow_none=False, mutable=True):
        """
        Initializes a column

        name: Name of the column this maps to
        default: Default value
        allow_none: Whether none (db null) values are allowed
        mutable: Whether this can be mutated by a setter
        """
        self.__name = name
        self.__allow_none = allow_none
        self.__mutable = mutable
        self.__default = default

    def validate(self, value):
        """
        In a child class, this will validate values being set
        """
        raise NotImplementedError

    @property
    def name(self):
        return self.__name

    @property
    def allow_none(self):
        return self.__allow_none

    @property
    def mutable(self):
        return self.__mutable

    @property
    def default(self):
        return self.__default

    def __get__(self, owner, ownertype=None):
        """
        Gets the value for this column for the passed owner
        """
        if owner is None:
            return self
        if not isinstance(owner, ColumnSet):
            raise TypeError("Columns are only allowed on ColumnSets")
        return owner.get_column(self.name).value

    def __set__(self, owner, value):
        """
        Sets the value for this column for the passed owner
        """
        if not isinstance(owner, ColumnSet):
            raise TypeError("Columns are only allowed on ColumnSets")
        owner.get_column(self.name).value = value

class StringColumn(Column):
    def validate(self, value):
        if value is None and self.allow_none:
            print "nonevalue"
            return True
        if isinstance(value, basestring):
            print "isstr"
            return True
        print "not string", value, type(value)
        return False

class IntColumn(Column):
    def validate(self, value):
        if value is None and self.allow_none:
            return True
        if isinstance(value, int) or isinstance(value, long):
            return True
        return False

class PasswordColumn(Column):
    def __init__(self, name, salt_function, default=None, allow_none=False, \
                 mutable=True):
        """
        Create a new password column which uses the specified salt function

        salt_function: a function(self, value) which returns the salted string
        """
        Column.__init__(self, name, default, allow_none, mutable)
        self.__salt_function = salt_function
    def validate(self, value):
        return True
    def __set__(self, owner, value):
        salted = self.__salt_function(owner, value)
        super(PasswordColumn, self).__set__(owner, salted)

The Column class describes the column and is implemented as a descriptor. Each ColumnSet instance contains multiple columns and holds ColumnInstance objects which hold the individual column per-object properties, such as the value and whether it has been mutated or not. Each column type has a validation function to help screen invalid data from the columns. When a ColumnSet is initiated, it scans itself for columns and at that moment creates its ColumnInstances.

Generation of SQL using logical predicates

The next thing I had to create was the database querying structure. I decided that rather than actually using the ColumnInstance or Column objects, I would use a go-between object that can be assigned a “prefix”. A common thing to do in SQL queries is to rename the tables in the query so that you can reference the same table multiple times or use different tables with the same column names. So, for example if I had a table called posts and I also had a table called users and they both shared a column called ‘last_update’, I could assign a prefix ‘p’ to the post columns and a prefix ‘u’ to the user columns so that the final column name would be ‘p.last_update’ and ‘u.last_update’ for posts and users respectively.

Another thing I wanted to do was avoid the usage of SQL in constructing my queries. This is similar to the way that LINQ works for C#: A predicate is specified and later translated into an SQL query or a series of operations in memory depending on what is going on. So, in Python one of my queries looks like so:

class Table(ColumnSet):
    some_column = StringColumn("column_1", "")
    another = IntColumn("column_2", 0)
a_variable = 5
columns = Table.get_columns('x') # columns with a prefix 'x'
query = DbQuery() # This base class just makes a where statement
query.where((columns.some_column == "4") & (columns.another > a_variable)
print query.sql

This would print out a tuple (" WHERE x.column_1 = %s AND x.column_2 > %s", ["4", 5]). So, how does this work? I used operator overloading to create DbQueryExpression objects. The code is like so:

class DbQueryExpression(object):
    """
    Query expression created from columns, literals, and operators
    """
    def __and__(self, other):
        return DbQueryConjunction(self, other)
    def __or__(self, other):
        return DbQueryDisjunction(self, other)

    def __str__(self):
        raise NotImplementedError
    @property
    def arguments(self):
        raise NotImplementedError

class DbQueryConjunction(DbQueryExpression):
    """
    Query expression joining together a left and right expression with an
    AND statement
    """
    def __init__(self, l, r):
        DbQueryExpression.__ini__(self)
        self.l = l
        self.r = r
    def __str__(self):
        return str(self.l) + " AND " + str(self.r)
    @property
    def arguments(self):
        return self.l.arguments + self.r.arguments

class DbQueryDisjunction(DbQueryExpression):
    """
    Query expression joining together a left and right expression with an
    OR statement
    """
    def __init__(self, l, r):
        DbQueryExpression.__init__(self)
        self.l = l
        self.r = r
    def __str__(self):
        return str(self.r) + " OR " + str(self.r)
    @property
    def arguments(self):
        return self.l.arguments + self.r.arguments

class DbQueryColumnComparison(DbQueryExpression):
    """
    Query expression comparing a combination of a column and/or a value
    """
    def __init__(self, l, op, r):
        DbQueryExpression.__init__(self)
        self.l = l
        self.op = op
        self.r = r
    def __str__(self):
        output = ""
        if isinstance(self.l, DbQueryColumn):
            prefix = self.l.prefix
            if prefix is not None:
                output += prefix + "."
            output += self.l.name
        elif self.l is None:
            output += "NULL"
        else:
            output += "%s"
        output += self.op
        if isinstance(self.r, DbQueryColumn):
            prefix = self.r.prefix
            if prefix is not None:
                output += prefix + "."
            output += self.r.name
        elif self.r is None:
            output += "NULL"
        else:
            output += "%s"
        return output
    @property
    def arguments(self):
        output = []
        if not isinstance(self.l, DbQueryColumn) and self.l is not None:
            output.append(self.l)
        if not isinstance(self.r, DbQueryColumn) and self.r is not None:
            output.append(self.r)
        return output

class DbQueryColumnSet(object):
    """
    Represents a set of columns attached to a specific DbOject type. This
    object dynamically builds itself based on a passed type. The columns
    attached to this set may be used in DbQueries
    """
    def __init__(self, dbo_type, prefix):
        d = dbo_type.__dict__
        self.__columns = {}
        for attr in d:
            obj = d[attr]
            if isinstance(obj, Column):
                column = DbQueryColumn(dbo_type, prefix, obj.name)
                setattr(self, attr, column)
                self.__columns[obj.name] = column
    def __len__(self):
        return len(self.__columns)
    def __getitem__(self, key):
        return self.__columns[key]
    def __iter__(self):
        return iter(self.__columns)

class DbQueryColumn(object):
    """
    Represents a Column object used in a DbQuery
    """
    def __init__(self, dbo_type, prefix, column_name):
        self.dbo_type = dbo_type
        self.name = column_name
        self.prefix = prefix

    def __lt__(self, other):
        return DbQueryColumnComparison(self, "<", other)
    def __le__(self, other):
        return DbQueryColumnComparison(self, "<=", other)
    def __eq__(self, other):
        op = "="
        if other is None:
           op = " IS "
       return DbQueryColumnComparison(self, op, other)
    def __ne__(self, other):
        op = "!="
        if other is None:
            op = " IS NOT "
        return DbQueryColumnComparison(self, op, other)
    def __gt__(self, other):
        return DbQueryColumnComparison(self, ">", other)
    def __ge__(self, other):
        return DbQueryColumnComparison(self, ">=", other)

The __str__ function and arguments property return recursively generated expressions using the column prefixes (in the case of __str__) and the arguments (in the case of arguments). As can be seen, this supports parameterization of queries. To be honest, this part was the most fun since I was surprised it was so easy to make predicate expressions using a minimum of classes. One thing that I didn’t like, however, was the fact that the boolean and/or operators cannot be overloaded. For that reason I had to use the bitwise operators, so the expressions aren’t entirely correct when being read.

This DbQueryExpression is fed into my DbQuery object which actually does the translation to SQL. In the example above, we saw that I just passed a logical argument into my where function. This actually was a DbQueryExpression since my overloaded operators create DbQueryExpression objects when they are compared. The DbColumnSet object is an dynamically generated object containing the go-between column objects which is created from a DbObject. We will discuss the DbObject a little further down

The DbQuery objects are implemented as follows:

class DbQueryError(Exception):
    """
    Raised when there is an error constructing a query
    """
    def __init__(self, msg):
        self.message = msg
    def __str__(self):
        return self.message

class DbQuery(object):
    """
    Represents a base SQL Query to a database based upon some DbObjects

    All of the methods implemented here are valid on select, update, and
    delete statements.
    """
    def __init__(self, execute_filter=None):
        """
        callback: Function to call when the DbQuery is executed
        """
        self.__where = []
        self.__limit = None
        self.__orderby = []
        self.__execute_filter = execute_filter
    def where(self, expression):
        """Specify an expression to append to the WHERE clause"""
        self.__where.append(expression)
    def limit(self, value=None):
        """Specify the limit to the query"""
        self.__limit = value
    @property
    def sql(self):
        query = ""
        args = []
        if len(self.__where) > 0:
            where = self.__where[0]
            for clause in self.__where[1:]:
                where = where & clause
            args = where.arguments
            query += " WHERE " + str(where)
        if self.__limit is not None:
            query += " LIMIT " + self.__limit
        return query,args
    def execute(self, cur):
        """
        Executes this query on the passed cursor and returns either the result
        of the filter function or the cursor if there is no filter function.
        """
        query = self.sql
        cur.execute(query[0], query[1])
        if self.__execute_filter:
            return self.__execute_filter(self, cur)
        else:
            return cur

class DbSelectQuery(DbQuery):
    """
    Creates a select query to a database based upon DbObjects
    """
    def __init__(self, execute_filter=None):
        DbQuery.__init__(self, execute_filter)
        self.__select = []
        self.__froms = []
        self.__joins = []
        self.__orderby = []
    def select(self, *columns):
        """Specify one or more columns to select"""
        self.__select += columns
    def from_table(self, dbo_type, prefix):
        """Specify a table to select from"""
        self.__froms.append((dbo_type, prefix))
    def join(self, dbo_type, prefix, on):
        """Specify a table to join to"""
        self.__joins.append((dbo_type, prefix, on))
    def orderby(self, *columns):
        """Specify one or more columns to order by"""
        self.__orderby += columns
    @property
    def sql(self):
        query = "SELECT "
        args = []
        if len(self.__select) == 0:
            raise DbQueryError("No selection in DbSelectQuery")
        query += ','.join([col.prefix + "." + \
                 col.name for col in self.__select])
        if len(self.__froms) == 0:
            raise DbQueryError("No FROM clause in DbSelectQuery")
        for table in self.__froms:
            query += " FROM " + table[0].dbo_tablename + " " + table[1]
        if len(self.__joins) > 0:
            for join in self.__joins:
                query += " JOIN " + join[0].dbo_tablename + " " + join[1] + \
                         " ON " + str(join[2])
        query_parent = super(DbSelectQuery, self).sql
        query += query_parent[0]
        args += query_parent[1]
        if len(self.__orderby) > 0:
           query += " ORDER BY " + \
                    ','.join([col.prefix + "." + \
                    col.name for col in self.__orderby])
        return query,args

class DbInsertQuery(DbQuery):
    """
    Creates an insert query to a database based upon DbObjects. This does not
    include any where or limit expressions
    """
    def __init__(self, dbo_type, prefix, execute_filter=None):
        DbQuery.__init__(self, execute_filter)
        self.table = (dbo_type, prefix)
        self.__values = []
    def value(self, column, value):
        self.__values.append((column, value))
    @property
    def sql(self):
        if len(self.__values) == 0:
            raise DbQueryError("No values in insert")
        tablename = self.table[0].dbo_tablename
        query = "INSERT INTO {table} (".format(table=tablename)
        args = [val[1] for val in self.__values \
                if val[0].prefix == self.table[1]]
        query += ",".join([val[0].name for val in self.__values \
                          if val[0].prefix == self.table[1]])
        query += ") VALUES ("
        query += ",".join(["%s" for x in args])
        query += ")"
        return query,args

class DbUpdateQuery(DbQuery):
    """
    Creates an update query to a database based upon DbObjects
    """
    def __init__(self, dbo_type, prefix, execute_filter=None):
        """
        Initialize the update query

        dbo_type: table type to be updating
        prefix: Prefix the columns are known under
        """
        DbQuery.__init__(self, execute_filter)
        self.table = (dbo_type, prefix)
        self.__updates = []
    def update(self, left, right):
        self.__updates.append((left, right))
    @property
    def sql(self):
        if len(self.__updates) == 0:
            raise DbQueryError("No update in DbUpdateQuery")
        query = "UPDATE " + self.table[0].dbo_tablename + " " + self.table[1]
        args = []
        query += " SET "
        for update in self.__updates:
            if isinstance(update[0], DbQueryColumn):
                query += update[0].prefix + "." + update[0].name
            else:
                query += "%s"
                args.append(update[0])
            query += "="
            if isinstance(update[1], DbQueryColumn):
                query += update[1].prefix + "." + update[1].name
            else:
                query += "%s"
                args.append(update[1])
        query_parent = super(DbUpdateQuery, self).sql
        query += query_parent[0]
        args += query_parent[1]
        return query, args

class DbDeleteQuery(DbQuery):
    """
    Creates a delete query for a database based on a DbObject
    """
    def __init__(self, dbo_type, prefix, execute_filter=None):
        DbQuery.__init__(self, execute_filter)
        self.table = (dbo_type, prefix)
    @property
    def sql(self):
        query = "DELETE FROM " + self.table[0].dbo_tablename + " " + \
                self.table[1]
        args = []
        query_parent = super(DbDeleteQuery, self).sql
        query += query_parent[0]
        args += query_parent[1]
        return query, args

Each of the SELECT, INSERT, UPDATE, and DELETE query types inherits from a base DbQuery which does execution and such. I decided to make the DbQuery object take a PEP 249-style cursor object and execute the query itself. My hope is that this will make this a little more portable since, to my knowledge, I didn’t make the queries have any MySQL-specific constructions.

The different query types each implement a variety of statements corresponding to different parts of an SQL query: where(), limit(), orderby(), select(), from_table(), etc. These each take in either a DbQueryColumn (such as is the case with where(), orderby(), select(), etc) or a string to be appended to the query, such as is the case with limit(). I could easily have made limit take in two integers as well, but I was kind of rushing through because I wanted to see if this would even work. The query is built by creating the query object for the basic query type that is desired and then calling its member functions to add things on to the query.

Executing the queries can cause a callback “filter” function to be called which takes in the query and the cursor as arguments. I use this function to create new objects from the data or to update an object. It could probably be used for more clever things as well, but those two cases were my original intent in creating it. If no filter is specified, then the cursor is returned.

Table and row objects

At the highest level of this hierarchy is the DbObject. The DbObject definition actually represents a table in the database with a name and a single primary key column. Each instance represents a row. DbObjects also implement the methods for selecting records of their type and also updating themselves when they are changed. They inherit change tracking from the ColumnSet and use DbQueries to accomplish their querying goals. The code is as follows:

class DbObject(ColumnSet):
    """
    A DbObject is a set of columns linked to a table in the database. This is
    synonomous to a row. The following class attributes must be set:

    dbo_tablename : string table name
    primary_key : Column for the primary key
    """
    def __init__(self, **cols):
        ColumnSet.__init__(self)
        for name in cols:
            c = self.get_column(name)
            c.update(cols[name])

    @classmethod
    def get_query_columns(self, prefix):
        return DbQueryColumnSet(self, prefix)

    @classmethod
    def select(self, prefix):
        """
        Returns a DbSelectQuery set up for this DbObject
        """
        columns = self.get_query_columns(prefix)
        def execute(query, cur):
            output = []
            block = cur.fetchmany()
            while len(block) > 0:
                for row in block:
                    values = {}
                    i = 0
                    for name in columns:
                        values[name] = row[i]
                        i += 1
                    output.append(self(**values))
                block = cur.fetchmany()
            return output
        query = DbSelectQuery(execute)
        query.select(*[columns[name] for name in columns])
        query.from_table(self, prefix)
        return query, columns

    def get_primary_key_name(self):
        return type(self).__dict__['primary_key'].name

    def save(self, cur):
        """
        Saves any changes to this object to the database
        """
        if self.primary_key is None:
            # we need to be saved
            columns = self.get_query_columns('x')
            def execute(query, cur):
                self.get_column(self.get_primary_key_name()\
                                ).update(cur.lastrowid)
                selection = []
                for name in columns:
                    if name == self.get_primary_key_name():
                        continue #we have no need to update the primary key
                    column_instance = self.get_column(name)
                    if not column_instance.column.mutable:
                        selection.append(columns[name])
                if len(selection) != 0:
                    # we get to select to get additional computed values
                    def execute2(query, cur):
                        row = cur.fetchone()
                        index = 0
                        for s in selection:
                            self.get_column(s.name).update(row[index])
                            index += 1
                        return True
                    query = DbSelectQuery(execute2)
                    query.select(*selection)
                    query.from_table(type(self), 'x')
                    query.where(columns[self.get_primary_key_name()] == \
                                self.get_column(self.get_primary_key_name()\
                                                ).value)
                    return query.execute(cur)
                return True
            query = DbInsertQuery(type(self), 'x', execute)
            for name in columns:
                column_instance = self.get_column(name)
                if not column_instance.column.mutable:
                    continue
                query.value(columns[name], column_instance.value)
            print query.sql
            return query.execute(cur)
        else:
            # we have been modified
            modified = self.mutated
            if len(modified) == 0:
                return True
            columns = self.get_query_columns('x')
            def execute(query, cur):
                for mod in modified:
                    mod.update(mod.value)
                return True
            query = DbUpdateQuery(type(self), 'x', execute)
            for mod in modified:
                query.update(columns[mod.column.name], mod.value)
            query.where(columns[self.get_primary_key_name()] == self.primary_key)
            return query.execute(cur)

DbObjects require that the inheriting classes define two properties: dbo_tablename and primary_key. dbo_tablename is just a string giving the name of the table in the database and primary_key is a Column that will be used as the primary key.

To select records from the database, the select() function can be called from the class. This sets up a DbSelectQuery which will return an array of the DbObject that it is called for when the query is executed.

One fallacy of this structure is that at the moment it assumes that the primary key won’t be None if it has been set. In other words, the way I did it right now does not allow for null primary keys. The reason it does this is because it says that if the primary key hasn’t been set, it needs to generate a DbInsertQuery for the object when save() is called instead of a DbUpdateQuery. Both insert and update queries do not include every field. Immutable fields are always excluded and then later selected or inferred from the cursor object.

256Mb doesn’t do what it used to…

So, this last week I got an email from rackspace saying that my server was thrashing the hard drives and lowering performance of everyone else on that same machine. In consequence, they had rebooted my server for me.

I made a few mistakes in the setup of this first iteration of my server: I didn’t restart it after kernel updates, I ran folding@home on it while running nodejs, and I didn’t have backups turned on. I had it running for well over 200 days without a reboot while there had been a dozen or so kernel updates. When they hard rebooted my server, it wouldn’t respond at all to pings, ssh, or otherwise. In fact, it behaved like the firewalls were shut (hanging on the “waiting” step rather than saying “connection refused”). I ended up having to go into their handy rescue mode and copy out all the files. I only copied my www directory and the mysql binary table files, but as you can see, I was able to restore the server from those.

This gave me an excellent opportunity to actually set up my server correctly. I no longer have to be root to edit my website files (yay!), I have virtual hosts set up in a fashion that makes sense and actually works, and overall performance seems to be improved. From now on, I will be doing the updates less frequently and when I do I will be rebooting the machine. That should fix the problem with breaking everything if a hard reboot happens.

I do pay for the hosting for this, 1.5 cents per hour per 256Mb of RAM with extra for bandwidth. I only have 256Mb and since I don’t make any profit off this server whatsoever at the moment, I plan on keeping it that way for now. Considering that back in the day, 256Mb was a ton of memory, it clearly no longer suffices for running too much on my server (httpd + mysql + nodejs + folding@home = crash and burn).

MMO Asteroids in Node.js…but for real.

Many people saw this april fools joke where the author said that he had created an asteroids MMO using Node.js. In reality, it was completely client side and was a bunch of bots. However, I did find the whole thing rather intriguing and decided to see what I could do with Node.js along this line. Last week I started on the project and this weekend I made enough progress that I can publish v0.0.1. It leaves several things to be desired, including a better game background so that one can tell when the view is shifting and user tracking so that you accumulate your scores over time. It does work and from what I can see its not horribly bad performance. While it certainly won’t be able to handle thousands of clients, I expect that it should be able to handle somewhere between 50-100 before it starts dying. At the moment, its quite limited by the memory on my server and the client side scripting gives the impression of “stuttering” with the dead reckoning system used to make the animations smooth. The stuttering is caused by the linear and angular damping that I have running on the server side not being factored into the projected location on the client side.

For physics I am using Box2Dweb in a Node.js module which may be overkill, but its the simplest Javascript physics engine I could find since I didn’t feel like writing my own. The server keeps track of all of the entities in the game and each client requests a “view” of an area of the room. The client is informed which player is them, but other than that it just sees all players and entities in the same list. The actual rendering function draws the entities onto the canvas dependent upon the type of the object.

I have made the source available on github here: https://github.com/kcuzner/mmo-asteroids

The MMO itself can be viewed here: http://kevincuzner.com:8080/. Note that at times it may be down since I am messing with my firewall right now and I might accidentally close the port. Just leave me a note in the comments and I’ll try to get it working.

Simulation in C++ finally works

After redoing this project several times, I have finally managed to get it working in C++. I gave up for the moment on the GUI since I figured it would be best to get the back end model working first before tackling the GUI. The biggest change I made from my previous paradigm is that I decided to split this into several Qt projects. The model is held in a project called Engine and doesn’t actually depend on Qt. Instead I decided to use Boost so that if I one day decide to ditch Qt I won’t have to throw out my model.

In designing the model I had two principal design concerns: Everything has to implement interfaces and everything has to be interchangeable. By defining everything as an interface (classes with a virtual destructor and all pure virtual methods returning types easily resolved without any additional code) this allows for additional expansion later at the hands of myself or somebody else who decides on a better implementation of any component of the engine. It also allows the Qt plugin system to be able to handle references to any of the types in the engine so that a future plugin interface can use them.

The structure I decided on is similar, but not identical to, the one that I used in the python version of this. The basic unit of a simulation is the Block which implements the IBlock interfaces. There are three child interfaces of IBlock: IEntryBlock, IExitBlock, and IModelBlock. IBlocks define inputs (IBlockInput) and outputs (IBlockOutput) and are contained in Models (IModel interface) which represents units to be simulated. Blocks may define entries and exits (IEntryBlock & IExitBlock) and hold any number of interconnected blocks. Entries with the same name as an Exit will be set to the value of the Exit at the end of each step. This allows for persistent variables in the structure (as opposed to just putting them in code). IBlockOutputs can be attached to multiple IBlockInputs but each IBlockInput may only be attached to one IBlockOutput. Boost Signals2 are used for maintaining the cleanliness of the model so that when an input has its attached output replaced, the formerly attached output is notified. IBlocks also signal when the have an input or output added or removed. Models can also be used as blocks (IModelBlock) inside of other Models, allowing for nested execution and creation of reusable components. When a simulation is running, a block can be re-used multiple times in different “contexts”. An example of this is a model that is used inside an IModelBlock. The model and all of its component blocks are only instantiated once, but the IModel could be used in multiple IModelBlocks which could be placed inside of different parent IModels. For this reason, I created the IContext interface. An IBlock is passed the IContext whenever an option is set, the block is initialized, or the block is executed. The block is expected to store all of its input, output, and stored values inside the context and not actually use any class member variables to store values between steps. In the case of an IModelBlock, it is expected that the block will “own” a child context in a parent context. This is so that each “instance” of the model being executed as a child model will have its own context to store variables in. The root context and root model are tracked by an IEngine. The IEngine takes care of setting the number of steps that constitute a simulation, the size of the delta value between steps, and what step the simulation is on. The IContext does the actual execution and is created by the IEngine (IEngine::getContext()). It is expected that when executing a step the IContext will queue up all the IBlocks in the IModel that have no inputs and that once all the inputs are set for an IBlock it will be queued for execution. A step is finished when there are no longer blocks to execute. To facilitate looping blocks like those that are found in Simulink, the IContext should re-queue a block for execution each time an input is set again after all of its inputs have already been set. While this leads to the possibility of infinite loops, the connection function should try to locate possible loops and stop them from happening.

As for exact implementation, I have created an IEngine called SimpleEngine (creating DefaultContexts) and I plan on creating a ThreadedEngine (creating ThreadeContexts) since the execution of blocks can become parallel at points where an IBlockOutput connects to multiple IBlocks. Other that those specifics, the default implementation is pretty much as specified above. The IModelBlock implementation subscribes to the signals on the IModel which are fired when IEntryBlocks and IExitBlocks are added/removed so that it can keep its IOs in sync.

A gist of how a simple simulation can be set up and run:

[gist id="4391549" file="simulate_basic_test.cpp"]

The next thing on the docket before I start off on creating all of the system blocks (basically, trying to clone the functionality of the blocks listed for Simulink) and making the GUI is to create a set of interfaces for describing the model in files. This is so that I can create an interface to a generic loader allowing for multiple file formats to be loaded (XML, JSON, BSON, something binary, etc) for describing simulations.

Simulink clone…now in C++

I took the plunge and decided to re-implement what I had in Python using C++. I had to change up my structure a bit, but I made the switch because of the following reasons:

  • The Qt Framework. While there are bindings for Python, I really liked Qt-Creator. Also, Qt is extremely cross platform (at least that is how it seems) and has a large amount of libraries. I’ve been messing around with it now for a bit trying to get a few things to work.
  • This is redundant of the above, but I really like the Qt Plugin system. After struggling with it for a bit, I finally was able to get a plugin to load. I will explain a little bit below exactly what I plan on doing with these.
  • As awesome as Python is, it doesn’t support true multithreading (it does multiprocessing…and to do what I wanted to do using multiprocessing would have required me to jump through some hula hoops)
  • C++ should have the potential to run faster than Python for mathematical things, which in this situation is a good trade off for ease of programming.
  • Writing the application entirely in C++ with Qt lowers the number of dependencies that would have to be installed on a client machine.

Now, the biggest advantages I see are: Speed and Extensibility. Python is extremely extensible, but it doesn’t have the greatest speed. C++ has the potential to run faster and then by using Qt, the extensibility part was brought in. I also prefer strongly typed systems since they keep me from stepping on my toes programmatically.

By far the coolest part of all this is the Plugins. After discovering that ALL communication between Plugins and the application must be done using interfaces, I realized that if I were to implement the entire thing using interfaces it could be extended to do many awesome things. So far, however, I have only really added interfaces to allow for adding computational “blocks” to the system for use in schematics. The system itself will define no blocks since I have decided to separate the engine from the actual blocks.

I will be posting later a bit about Qt plugins since that is what I have spent the most time on. Google was definitely my friend on that one. Most people it seems just use Qt Plugins for extending Qt itself rather than doing the “low level” extending the application stuff.

In terms of development time, C++ is quite a bit slower for me than Python. However, my potential to write good code is much higher since I am much more familiar with C++ coding conventions and I am more able to clean code while being confident nothing is being broken since in Python, there are no compile-time errors to tell you that you switched the arguments to a function.

Cloning Simulink…in Python

For a while now I have been working on a bench supply. As part of this I have been trying to get a PID controller to work. At first it was simple, but after asking my Dad about it (he does power electronics), he suggested that I use a cascaded PID loop for controlling the voltage and current using the voltage alone. I have sort of a bench model going, but I don’t really want to start construction until I have everything finalized since blowing things up and making mistakes is kind of expensive for my meager college student budget. Tweaking that without a working bench model that I am willing to blow up is kind of hard, so I started trying to figure out how to simulate it. Being partial to simulink (I’ve used it before with some nice pre-built blocks), I wanted to be able to lay it out graphically like control system diagrams usually show and I also wanted to be able to view plots over time. So thus was born my latest project: SimuPy.

Python seemed like an ideal language for this since I wanted it to look nice, be extensible, and be almost universally cross platform. I am relying heavily on the Qt library because it runs on almost anything and it has the ability to use slots and signals on pretty much any object as well. I guess another option would have been Java, but seeing as I don’t like Java that much, Python was what I went with. In addition, I am weighing a couple other options:

  • At the sacrifice of portability, I could make the interface half in C++ and half Python so that I still keep the extensibility without having the requirement of installing python on the person’s computer to get it to work. The simulation part would then turn into a python library that the program would load.
  • Write the entire thing in C++ for speed and true multithreading and use Python solely for extensions. This would be a little more difficult since I kind of leverage the dynamic typing thing that Python has going on.

So far, my current structure has everything based on a Model which contains Blocks. In addition, there is a simulation Context which holds information about each Block and where the simulation is in terms of the current step (simulations are stepped over time (dt)). Contexts are also where a Block will store all of its information that it needs to retain during the current step and in the next step. A Block is an operation over time in the flow of the simulation: it could be a simple addition, maybe a derivative or integral, or it could be a full PID controller. Blocks declare themselves to have a number of Input objects and Output objects. Inputs/Outputs are named and have a slot/function called set which sets the value of the input or output. Outputs have a signal called ‘ready’ which inputs connect their ‘set’ slot to. When an output’s ‘set’ method is called, it emits its signal. When an input is set and it sees that all inputs attached to its block are set, it performs a “step” on the block. In addition, there are 3 special blocks: An EntryBlock, ExitBlock, and ModelBlock. Entry and Exit blocks are used in models since a model can have “Entry” and “Exit” points. These points can be used to loop a value from an Exit to an Entry (if they have the same name) or can be used as Input and Output objects if the Model is placed inside a ModelBlock. ModelBlocks are blocks which contain a model which they execute in a child simulation Context to their context. In this way, blocks can be nested. If one creates a Model with 2 Entries and 2 Exits with a pair of those Entries and Exits having the same name and then the Model is attached to a ModelBlock, the ModelBlock will have 1 input and one output to corrispond to the free Entry and Exit on the Model. Models can’t be recursive, but they can be nested so as long as a higher level block doesn’t contain a block which at some child level contains the same higher level block, there can be some sense of re-usability and modularity to a simulation.

Blocks are subclassed into a package called model. The __init__.py file in the model package defines the basic form for a block and then the individual modules in the package define more specific blocks. The blocks then have their constructors cached by reflection so that a block can be constructed by simply naming its name. To extend the blocks available in a simulation, all that must be done is to drop the new module python file into the model folder. I am considering changing this a bit to separate out user-added modules from the “system” modules in kind of the same fashion as I did with the WebSocketServer where I had the files in a folder be loaded into the context of another package.

Simulations are to be stored in an XML format which is going to be more or less human readable and should preserve the look and feel of the simulation. I am still working on the exact format at the moment, but that is the next step.

As for the GUI, I plan on using Qt since it seems the most cross-platform (sorry GTK…Windows needs too much help to load you and PyDev in eclipse doesn’t like the whole introspection thing). I plan on releasing the project under the Apache License (but don’t yet quote me on that or hold me to it…I may choose a different license later once I get more of a feel for how the project would be used). Either way, I plan on publishing the source code on github since it looks like nothing like this really exists in a simple form. Sure, there are clones of Simulink to work with Octave and things like that, but it doesn’t look like there are few, if any, stand-alone applications that do this (except perhaps a paid program called logic.ly, but this should be able to duplicate the functionality of that program as well). I guess it is kind of a niche market since the only people who do this kind of thing usually can afford Simulink and Matlab.

For the record, I do have access to Simulink and Matlab through the University I am attending, but where would the fun be in that?