So recently I had to design a relatively convoluted system with a database that communicates with a hardware controller board and a RFID reader. Among other things, the system has to respond to several commands issued from a web frontend over HTTP, and report the status of each sub-system, sensor, etc hopefully in JSON or similar web-friendly format.
For this task I picked a Raspberry Pi as the platform, and made a program in C that talks directly to the hardware and handles everything including the HTTP requests. Now, this is definitely not the first time that I need to write a program that has to listen for requests and reply with simple data over HTTP, so I thought that perhaps it would be useful to encapsulate this functionality in a small module that I could later re-use in other projects.
So I ended up doing exactly that, and uploaded the code to my GIT-Hub Repository, so you’ll find the result from that here: https://github.com/battlecoder/httpdpi.
Before you dive into the code, please bear in mind that it’s an extremely simple service that will only respond to GET requests, but has all it needs to reply with different status codes, text, and binary data. It only uses sockets and POSIX threads, so it’s very fast, doesn’t depend on a huge framework, and can run in parallel with your code. It’s also really easy to expand if you want to support other types of requests.
Since it doesn’t have obscure dependencies, it should also compile on most linux boxes including other small computers like C.H.I.P, Beaglebone, etc.
Cutting PCBs down to size for each project has always been a problem for me. I don’t have a bench saw, so I’ve been doing this by hand until now. Despite the number of boards I’ve made, I still lack the dexterity to do perfectly straight cuts with a regular hacksaw, and my success with other manual methods has been equally limited. Like a year ago I stumbled upon a small a table saw on dealXtreme which I was tempted to buy but was kinda too expensive for me. My search continued until a few months ago, when I realized that I could make one myself, using a small motor I salvaged from a cheap $10 dremel-like tool that I once had. I wasn’t sure this was going to work, but decided to give it a go nonetheless.
At least looks like a table saw. That’s always a good sign.
A while ago -and after a couple of trips to our local “flea market”- I managed to get my hands on a fully working vintage Atari 800XL. It took some tests and soldering work, but I ended up with a fully working 800XL with a XC12 cassette deck (I even got a defective cassette deck that it’s mostly working now after some repairs). I also built a video cable to have the “vastly superior” RCA video output instead of the noisy “TV” RF signal.
The tape deck loads and saves to cassette perfectly, but every read/write operation takes ages. Not that I mind waiting, to be fair, but since there seems to be better alternatives (like the floppy disk drive) it makes no sense to just stick to this, especially since I intend to do some development on the device.
Yes, this picture was taken with a potato.
You may remember the small soldering fume extractor I designed a while ago. It has worked really well since I built it, and it’s made my soldering work a much more pleasant experience.
However, during the time I’ve been using it, I’ve discovered a small aspect that could definitely be improved. Because of the way it works, when the fan start working it “sucks” the carbon filter a bit towards the blades. As the distance between the filter and the fan blades is no more than 2mm and the filter itself is not rigid, the carbon surface “bends” and touches the spinning fan, which causes the blades to pull and cut fibers from the filter. You can actually hear this happening when you turn the unit on with a reasonably new filter.
This stops after some uses, as the filter becomes thinner and less dense from all the fibers it has lost. This doesn’t prevent the extractor from working, but it certainly reduces both the efficiency and the lifespan of the filter.
To solve this I designed a small plastic “grill” that would hold the carbon filter in place, separating it from the fan.
Carbon filter holder for my soldering fume extractor.
Continuing from my previous post on randomness, I’d like to talk about non-uniform distributions, which certainly don’t get all the love they deserve. When people talk or think about randomness in games, they commonly think about fair distributions. And I know we spent a lot of time in Part 1 actually trying to achieve perfect uniformity because it brings “fairness” to games, but in reality, there are cases where you don’t want your random events to be ruled by a “fair” distribution at all.
Reality Check #4: Sometimes uniformity is bad
Fun fact: For a lot of “random” events in nature, every possible outcome rarely has the same chance of occurring, so perhaps trying to achieve that uniformity in games could be a mistake to begin with.
Let’s take rabbits for instance.
If you observe the population of rabbits of a given area, you’ll notice that they’ll have a”typical average size”. Let’s call that size X. You’ll find that most rabbits in the area will be around that size. There will be a rare few that are either considerably smaller than X or considerable bigger (outliers), but for the most of it, rabbits will be “just around” X in size. Same goes for any other quantifiable trait that depends on enough factors to be considered random.
They will most-likely follow what is called a Normal (or Gaussian) distribution, which is said to appear in nature all the time. The function that defines this distribution is also called the Gaussian Bell, due to the shape of the curve.
DISCLAIMER: This is a rather long post on the topic of random numbers, so …uh, sorry for that.
I want to talk about a couple of interesting things related to randomness and its many nuisances especially when applied to games. But before we get to that I guess I’ll introduce the basic notions for those of you who are not familiar with this whole thing. You can skip the first two sections if you know what a PRNG is, and how it works.
What is Random
Random is commonly defined as “unpredictable“. In general, when we are unable to find a pattern that would allow us to anticipate the outcome or occurrence of an event, we call it “unpredictable” and there’s a chance we will consider the event “random”.
You’ll also hear of “true randomness”, and things like natural atmospheric noise, lightning bolts, or particles falling from the space being used as sources and examples of it. But while we can’t currently predict when and where lightning will hit, events in the universe like electric discharges in clouds are most likely just a massively complicated function of a number of different factors, and not really something that happens with no rhyme or reason. It’s quite possible that if we were able to simulate each particle and sub-particle inside a group of storm clouds and their relevant vicinity, lightning would be trivial to anticipate with accuracy. This makes its “unpredictability” debatable, I guess.
Having said that, let’s not forget that “predictable” and “unpredictable” are relative to an “observer”. What we consider true random events could totally have a logic behind, but what matters is that from our -and our system’s- point of view, they are impossible to predict, and if the machine (or person) is unable to anticipate the occurrence of an event, the definition applies, regardless of the event’s “actual” predictability.
Not long ago I purchased a few 320×240 touchscreen displays from ebay that looked pretty decent and were also fairly cheap. They conform to the Arduino shield form-factor, so they snap directly onto any standard Arduino board, making them really easy to test and use. They also have an integrated microSD slot (connected to the same bus used by the display controller) which is a nice touch and widens the number of possible applications for these modules.
As seen on literally every eBay listing that sells them.
Of course the displays didn’t come with any code, and the most reasonable thing you’ll find online to make them work is Adafruit’s TFT-LCD Library, which includes support for a number of different controllers, and is fully compatible with their very own and versatile GFX framework.
I wanted to add a temperature sensor to a project I’m working on, and while I already had selected the perfect IC for the job, I decided to test a couple of other options I had, to see how they fare in comparison. I was originally going to compare only 3 sensors; the popular LM35, the not-so-popular LM335 and the kinda obscure TMP75, but as I started writing this post I remembered I got a Dallas DS18B20 as part of kit of sensors, so I added it to the mix to balance the digital-to-analog ratio of this comparison.
The original 3 sensors I was going to test.
Ok, so this is probably the last post I’ll make about my Brainfuck-on-Arduino project, basically because it has reached a point where I’ve already tried all the things I wanted to try and I’ve decided that there’s no point in taking it out of the breadboard and build a board for it. At least not for Brainfuck. And I’ll explain why.
The Performance Issue
I previously said that I was expecting the performance to “drop” a bit when reading directly from a SD card instead of the internal RAM, but I was hoping to mitigate that with a sector/block cache similar to the one I wrote for the SPI RAM.
And that’s completely reasonable and actually true. Where I made a mistake however, was in also assuming that doubling the SPI clock would result in a noticeable performance boost. That’s definitely false. Reading a whole 512bytes sector currently takes between 1 and 2 milliseconds at 4Mhz, and RAM access is done at the same speed, so being the RAM pages half the size of the SD sectors it probably takes half that much to get a whole RAM page.
Since we are caching so many bytes in advance, the number of page reads (both from RAM and SD) is not really that high, so even if we were to double the SPI bus speed we will only cut around 1ms from each access. Most programs I’ve tested don’t normally cross the RAM page boundaries nor require more than one SD sector to be stored, so the speedup won’t even be noticeable for most cases. It will be barely 1 or 2 ms, so if we run into performance issues, they are somewhere else. They are NOT in the SPI Bus speed.
DISCLAIMER: Over the course of this post I’ll be dealing with parsing, programming practices, code refactoring, SPI bus oddities, caching techniques,etc. It’s a mixed bag of things and it’s far from being serious analysis on the topic of optimization. Please don’t expect anything particularly smart in this post like branch prediction, overlapping cache windows, partial block reads, etc. This is just a chronicle of sorts, of the things I’ve done over the past few hours to improve the performance of my Brainfuck-on-Arduino interpreter, which was being painfully slow.
So in my previous post you hopefully got a glimpse of my current project: a Brainfuck interpreter running completely on Arduino. Something that I forgot to mention is that all the input/output (for testing purposes) currently happens through a serial connection. I’m using the “Serial Monitor” console that’s part of the Arduino IDE to “talk” with the board and run the code.
I’d also like to point out that I’m using an external 23K256 chip for the Brainfuck data space, This is basically a 32KB RAM IC that is accessed via SPI (Serial Peripheral Interface). This is relevant for some of the optimizations I’ll do next.