explorad

I first used bdf fonts converted to my own proprietary binary format, but why not try something else? So I took an otf font, converted it to ttf, bdf, and then to binary. And that works indeed.

Below is a picture that shows the result quite nicely. I might pick a different font in the future, but that one seems to fit for now. You can also see some small buttons at the upper left and a CPU/RAM usage widget at the bottom of the screen.The small green board is also new, it carries an LSM303D (I²C accelerometer and magnetometer) which I will use to measure (at least) pitch and roll of the device. Yaw information might either come from the magnetometer or from optical encoders attached to the mount, I'm not sure yet.

I tried to convert the contest logo to a single-glyph font, which turned out to be harder than I thought - for two reasons:

• I'm not a gimp expert
• My glyph class was limited to glyphs with a maximum of 256 bytes. My conversion of the contest logo has 95x98 pixels, resulting in a too large glyph and rubbish on the display. After two hours of changing the glyph format and re-converting all fonts, the result is quite pleasing:

Show me the universe!

What do I expect from a widget library for microcontrollers like that small Teensy's Cortex-M4? Current state is "I expect more than I have", and I think the biggest problem is that I'm thinking inside the Qt4 box - Qt4 was the first widget system I ever used. I just hope I'm not going to write layout classes, that would certainly be a mess.

The hardest part so far is focus management. Where do my Button inputs go? I can't just let anything have focus and let it pass ignored inputs to its parent. Why? Because I want to highlight a button when it is selected, not the label which is part of the button composition.

That said, I figure that focus management doesn't need to be "efficient" regarding CPU usage. It doesn't really matter how long it takes to figure out which widgets gets focus, because focus usually only changes when there's some user input. That's a slow thing.

The title might not be that spectacular, but it's very satisfying to see the display and the SD card coexist. While the display is fed via DMA, I can pause the DMA driver and use the SPI to write to/read from the SD card using sdfatlib (https://code.google.com/p/sdfatlib/). Now I can have fluent graphics and read celestial object data from the card in the background. It's time to create widgets for this thing!

Display is working after a major rewrite of old code and uses about 14% CPU to draw the telrad circles at 25 fps. I might get away with a lower update rate, but the remaining power should be enough to implement quite a lot.