Monotron at Rust Belt Rust

So now is over, I thought it was worth writing down a few details about what Monotron can do. It's had a few upgrades since Paris! I tried to keep them under wraps to avoid spoilers but I can share them now. This is an un-roll and re-edit of my Twitter thread, and the features listed here are in no particular order:

1. You can upload binary apps into RAM over serial. 24 KiB is reserved for apps, leaving 8 KiB for stack and character RAM. The ROM passes a structure full of function pointers so that apps can access useful functionality, including a vsync function for smooth gameplay.

2. You can write apps in C and in Rust! Example apps include Tiny Basic, a little slideshow about the system, Snake and even a 6502 emulator running an unmodified copy of 6502 Enhanced BASIC.

3. There is a three channel 8-bit wavetable synthesiser running at 37 kHz (the scan-line frequency). It has four 256 byte samples - square, sawtooth, sine and noise. Snake has multi-t…

Where next for the Monotron

It's a couple of months on from my talk at RustFest on Monotron, so I thought it was worth a quick catch up on where we're going next.
Graphics and Text As a recap, Monotron currently generates an 800 x 600 VGA signal at 60 Hz (with a pixel clock of 40 MHz). It does this using three synchronised SPI peripherals, a timer generating the horizontal-sync pulse and a GPIO pin for the vertical-sync. With the CPU running at a clock speed of 80 MHz, the SPI peripherals are clocked at 20 MHz producing 400 horizontal pixels per line. This is half the nominal 800 pixels, but we needed to sacrifice resolution to double the amount of CPU time we have to 4 clocks per pixel (i.e. 32 clocks per 8-bit character column).

The pixels are generated from a 48 x 36 character buffer. Each cell can store one 8-bit character (in MS-DOS CodePage 850) and one 8-bit attribute value. Currently the attribute value stores a 3-bit (1 red bit, 1 green bit, 1 blue bit) background colour and a 3-bit foreground c…

Talking about Monotron at RustFest

So, today I did a talk about Monotron at RustFest Paris. You can find the code on my Github and/or on
The top-level crateThe generic embedded VGA Framebuffer Driver, with callbacks for hardware specific bitsThe command-line menu systemThe PS/2 keyboard driver (unfinished)The tm4c123x-hal and tm4c123x chip support cratesThe excellent Cortex-M and Cortex-M-RT crates from japaric. If you want to buy a Tiva-C Launchpad (it's the same as a Stellaris Launchpad) of your very own, try RS Components, or Farnell or Digi-Key. Just add a VGA connector and three resistors. The Github README tells you where to put them but I take no responsibility if you blow something up - double-check your working with an oscilloscope before risking your monitor!

You can find the slides here. There's a quick video of the closing animation here. The video of the talk will be on the RustFest Paris website soon!

If you want to ask a question, catch me on IRC (try #rust-embedded) or as @therealjpst…

I decided to make an 1980's Home Computer in Rust - Part 1

I've had a few projects over the past few years using the TI Stellaris Launchpad. It's nothing particularly special - just a Cortex-M4 based LM4F120 MCU at up to 80 MHz with 256 KiB of Flash and 32 KiB of SRAM, an RGB LED and an on-board USB programmer - but it's pretty cheap and I've gotten to know it quite well.

The provided StellarisWare software was a 300 MiB installer, so I threw that out and wrote all of the drivers from scratch. I started out in C, and managed to get a simple car dashboard module working, using an LCD TFT with on-board framebuffer and 8-bit 6800/8080 bus interface (despite the chip not having such a bus - I cheated and used GPIO pins instead). My first attempt at Rust programming was the stellaris-launchpad crate. This has a few demos that either blink the LED or roll it through an RGB rainbow using the PWM timers. From this, I then decided to move the chip support package into a separate crate, in case anyone wanted to use the chip on a differe…

Supporting the new Embedded HAL

Recently, @japaric posted a about a new approach to an Embedded HAL in Rust. This is something that's been kicked around on #rust-embedded for a while, but it was great to see it get to a point it could be pushed out to the wider world.

I run the Cambridge Rust Meetup and the post coincided with our next Hack-n-Learn evening. The purpose of these evenings is to work through problems together and I decided it would be fun to try and implement the Embedded HAL on my LM4F120 chip crate, and then fix the Stellaris Launchpad examples to use the new HAL. To engage some of the attendees new to Rust, I thought it would help if I did it live on the big projector and talked through the changes as I made them.

Well, despite a quick 10 minute break for pizza (thanks Cambridge Consultants) I managed to get the changes completed to the UART driver in under two hours. Here's what I had to do.

The old UART driver in the LM4F120 crate used my earlier Embedded Serial HAL. That looked like this:

Embedded Rust in 2018

I recently picked up an embedded project that I hadn't touched for a few months, so I could add some new features. I was disappointed to note that it no longer compiled - nothing in the code had changed, but it only compiles with Nightly Rust and that had recently had a bunch of changes that completely broke my build. This is then a tale about what I'd like to see from Rust in 2018.

I know there's been a lot of interest in WASM and other 'high level' applications, but Rust also lends itself very well to embedded development. I have a demonstration project for the Texas Instruments Stellaris Launchpad (now rebadged the Tiva-C Launchpad). This project comprises approximately three Assembler instructions (to bounce into the hardfault handler), and the rest is Rust - no C required! Exception handlers, setting the stack pointer and initialising the .data and .bss segments can all be done in pure Rust. Thanks to brilliant work by the likes of @japaric, with the Xargo cro…

Advent of Code

Over the past weeks, I've been working through Advent of Code. If you haven't seen it, it's basically a daily programming challenge - one a day for the 25 days running up to Christmas. Each challenge has two parts, and you get points for being in the first 100 people to submit a correct answer (usually a number, or a short string). There's nothing for coming 101st! The challenges open at 00:00 EST (so, 05:00 GMT) so if you want to have a crack at the leaderboard, it's a very early start. The best I've managed so far is about 162nd, but there's a few days left.

Most people tackle the problems in Python, and arguably that's a very good choice. It's a very expressive language, and as the winners produce short, dense code - it needs to be fast to type after all - the lack of static type checking isn't as much of a problem as it might be in a larger application.

I'm doing it in Rust, and it's been very educational.

I thought my Rust was OK go…