Content originally posted in LPCWare by MarcVonWindscooting on Sun Oct 27 12:56:21 MST 2013
I did some display output recently. By I use those simple EA-DOG-modules (128x64px, 400uA power consumption).
I do everything in the most inefficent way by starting with a frame buffer structure and pixel read/write operations.
The frame buffer is simply a char array, but I defined bit-offsets for x and y. That way I can lay out the bits as rows or columns of pixels. This helps adapting the frame buffer to real devices.
Based on the frame buffer structure and read/write pixel I defined bitblt to copy one rectangular area to somewhere else (probably even a different frame buffer, with different pixel/memory mapping). Once I had bitblt, I defined fonts with that. And a font is nothing but a big (e.g. 256*width of character) image containing all characters plus a function that maps from character value (0..255) to the characters image position (and width) in the big image. That even allows variable width of the chars.
One thing I should point out: everything works with signed integer 32bit coordinates and positioning outside a frame-buffers range is doesn't generate an error.
What I did recently was wasting even more CPU power, by NOT using the display chips scrolling capabilities. I use a memory image (frame buffer) and provide a very fast SPI frame update. The SPI transfer is done mostly by hardware, so that doesn't cost too much. I have to confess, I was tempted by the idea of using 64bit shifts for scrolling the frame buffer up by n pixels, but that is the only optimization that does not perform pixel read/write 0:)
The cool news is: even on a LPC2136 at 12MHz such an approach is still feasible and frame rates of about 5Hz possible (besides running I2C LM73, PCA9555 (8buttons, 8LEDs), 2 digital potentiometers, 4 GPIO buttons, generating beeps). I want to add a 3-Phase PWM motor control, that already ran with the I2C-part and the digital potentiometers at 48MHz up to 60kHz sampling rate/PWM frequency.
I focussed on ease of programming and code size, not speed. And no regret so far.
(if you care, my GPL3 project 'mxli' (www.windscooting.com/softy/mxli.html , lib/c-any/gfxmono*) contains that code in the libraries).
tl;dr
Make sure, you don't optimize a part of your program, that doesn't need that.
I believe, text output doesn't need to be that fast, because a human is supposed to understand that output. Humans are very slow in reading text, at least I am. The output of an under-clocked LPC21 overpowers my brain by a factor of 100 at least. I'm not a gamer, though.