as i talked about in my psuedocode interpreter post, i was an ib computer science student. part of this class was an IA, an internal assessment graded by ib markers. my original project was an interpreter for the ib's own flavor of syntactical shit, what they called pseudocode, but this was a bit too much. i ended up pivoting to instead write a program for my school's pinewood derby system. in case you don't know what pinewood derby is, it is just a 20 foot track that you can race cars carved out of wood blocks on. a lot of scouts groups and some schools like to run races. it uses a fairly common timer and track, but the software available is bad for testing cars - it typically requires a bunch of setup and there are annoying contingencies such as requiring you to use all the lanes. i wanted to write a program that would allow for easier testing, not trying to replace the existing software but just make it easier for kids to test their cars.

the project became difficult when i couldn't get ahold of the timer documentation. the site claims to list a programmers manual, which simply doesn't exist. however, i can't even be that mad because when eventually (after them being unresponsive to my emails) i searched up the document it came up... however, it was not all for nothing. in the pursuit of my attempt to finish the project without documentation, i created a rig to try to reverse engineer the signals that existing software sent by using breadboard jumper wires to plug into the serial adapter (the track uses an RS-232 port for communication with the computer) which ran into my arduino. because RS-232 does not have include a clock, timing was very important so i taught myself AVR assembly. this exercise, although slightly successful for what i was trying to do and successful in teaching me some AVR assembly, was not enough for my project and soon afterwards i discovered the documentation online.

now that i had documentation in hand, i could begin actually programming. i wasted hours because i assumed the serial adapter worked by converting usb traffic to serial instead of converting serial traffic to usb which is then re-encoded as serial traffic when leaving the adapter, which led me to nearly lose my mind over libusb simply not working. when i figured out that i needed to only send serial data, i landed on teuniz' RS-232 implementation, which works great. however, this was my first experience touching a peripheral with code, which caused me to take a minute to figure it out. i can't include any of my code here, because it could end up ruining me academically, but long story short a combination of learning curves caused a less than relaxing development process for this program.

along with being my first peripheral programming exercise, it was also my first time making a GUI. initially, this project was supposed to be python (another recommendation of my teacher). i was so revolted by the design paradigm of python GUI libraries that i fully left the ecosystem. after looking briefly into qt, i landed on gtk with the gtkmm c++ binding. this was actually a really pleasant experience. GUI code is not something i enjoy, per se, but the design paradigm of gtk feels good, makes sense, and provided tools that let me do what i was trying to do without too much fighting.

this project taught me a lot and it feels like i've completed a real project instead of just another command line toy. the development process was very stressful due to a fast-approaching due date and things like needing to be physically with the track to test half of the stuff. i wrote a lot of code really late at night for this and i ended up deleting all of it at one point or another because i didn't understand the timer system when i wrote it.

i would regret saying i can't upload the code, but some of it is still probably so bad that if anyone looked at it i'd be shamed off the internet. maybe one day i will rewrite the shitty portions of it and upload that. don't hold your breath; the world already has enough awful pinewood derby software. thinking back to when i was way younger and competed in some pinewood derby races myself, i definitely remember the adults fighting the software at every turn. the most frustrating part of pinewood derby stuff is that there are like 15 commercially available timers that all have completely different communcation protocols. they all implement their own command system, which leads to things like this where you have to configure the program for what kind of track you have. i get it's a hobby kind of thing and theres no official pinewood derby standard but if all the tracks can agree to run one size of car then i feel like there should be some kind of agreed on standard for how the damn tracks talk to the software. the software would be so much more reliable that way.