Brian, does your uni let you publish your curriculum or course notes? Is this something you've ever considered?
-joe

On Fri, Aug 14, 2015 at 10:49 PM, Brian L. Stuart <blstuart@bellsouth.net> wrote:
> I have tried to email BLS but fear I am being spam filtered... you there?

I did get one message from you, and replied earlier today.  Hopefully
it got through.

A little more update on recent pi playing.  I've been working on a
little toy the last few days, namely one of those small SPI driven
LCD panels:

http://www.adafruit.com/products/2441

As of this evening, I've gotten it sort of running alongside the
HDMI display showing the upper left corner.  Here are a few
pics of it in operation:

The Pi with the display connected to a keyboard and mouse:

http://cs.drexel.edu/~bls96/9pitft1-s.jpg

and a couple of pics of the display showing acme running:

http://cs.drexel.edu/~bls96/9pitft2-s.jpg
http://cs.drexel.edu/~bls96/9pitft3-s.jpg

It's a long way from being usable though.  The fundamental issue
is that there appears to be a very deeply embedded assumption
that a screen must be memory mapped.  I tried hooking into
the hwdraw() routine in screen.c, but it seems that not every
change to the screen memory space gets reflected in a call
to hwdraw().  For the pics, I've got a version that periodically
copies the whole of the appropriate area of the Memimage
to the LCD panel over the SPI port.  Obviously, that's too slow
and too resource-hungry to be practical.  Hopefully, I'm missing
something and there's an elegant way to graft a non-memory
mapped display into the devdraw/memdraw/screen infrastructure.

BLS