I do a lot of electronics projects in my spare time, and I tend to try to make
reusable parts to save myself effort in the future. Because I have to order
ingredients in certain quantities, I often wind up with more than I need for my
project.
So I’ve opened a Tindie store, called Overengineered Widget
Laboratories. Right now there’s one product in the store, called
Keypad:GO. See, I built a sculpture last summer that needed to interact
with people through a phone-style keypad. The keypad interface part of it seemed
like something other people could use, so I made a few extras. This is a very
easy way to interface a keypad or small keyboard to an embedded electronics
project, because it handles all the basics for you — matrix scanning,
debouncing, key matrix collisions, etc.
It will also help you reverse engineer the keypad’s circuit, because often
cheap keypads arrive without good documentation. In the tiny flash of the
embedded microcontroller, I’ve packed a setup wizard that will walk you through
the process of setting up the keypad of your choice. All you need is a terminal
program. This is honestly my favorite part, and I demonstrate it in the video
below.
I really like the STM32 series of microcontrollers in general. They’re generally
quite reliable, the peripherals are well tested, and more often than not I can
just grab one off the shelf and not think about it too much.
However, like every microcontroller, they do contain implementation bugs, so
it’s always important to read the “Errata Sheet” (or in ST’s language, “Device
Limitations”) when you’re using a part.
I appear to have hit an implementation bug in certain STM32 lines that is not
listed in the errata sheet. I can’t find any specific description of this bug on
the internet, so I’ve attempted to nail one down. Hopefully this will come up in
the search results for someone who hits this in the future and save them some
time.
This post is the third in a series looking at the
design and implementation of my Glitch demo and the
m4vgalib code that powers it.
In part two, I showed a fast way to push pixels out of an STM32F407 by getting
the DMA controller to run at top speed. I described the mode as follows:
It just runs full-tilt, restricted only by the speed of the “memory” [or
memory-mapped peripheral] at either side…
But there’s a weakness in this approach, which can introduce jitter and hurt your video quality. I hinted at it in a footnote:
…and traffic on the AHB matrix, which is very important — I’ll come back
to this.
Quite a bit of m4vgalib’s design is dedicated to coordinating matrix traffic,
while imposing few restrictions on the application. In this article, with a
minimum of movie puns, I’ll explain what that that means and how I achieved it.
This post is the second in a series looking at the
design and implementation of my Glitch demo and the
m4vgalib code that powers it.
Updated 2015-06-10: clarifications from reader feedback.
For the first technical part in the series, I’d like to start from the very
end: getting the finished pixels out of the microprocessor and off to a display.
Why start from the end? Because it’s where I started in my initial experiments,
and because my decisions here had significant effects on the shape of the rest
of the system.