Sunday, 22 December 2013

LCD success!

I can now blit coloured rectangles to a small 4" LCD. Bloody /RD (pin E1) was stuck as an output, even though I'm clearly telling it to be an input. This broke the LCD self-init. Why will have to wait for another day - for now, I've unplugged it.

In other news:
  • I can't set optimisations to O2 or O3 without my code crashing on startup. O1 is fine.
  • Function calls appear to be very slow on the LM4F. Inlining a bunch of stuff speeded it up no end.
  • Even with heavy inlining, it's still taking a while to draw the screen. We'll see how it goes when I'm rendering glyphs instead of boxes. Plus, 16 bit mode will help - I'm writing 3 bytes per pixel at the moment.

Friday, 20 December 2013

LCD frustration

So, I've been trying to get this Displaytech LCD module to function, as part of the Mazda's TFT dashboard. Without the aid of a scope or logic analyser, it was extremely difficult to debug the 8-bit parallel (8080 style) interface. So, I've managed to lay my hands on a Salea Logic16 - the most amazing logic analyser I've ever used. The software is just gorgeous, even under Linux. Unhooking my board and connecting the analyser instead, very quickly I was able to determine that the Displaytech module's on-board Atmega is sending valid commands at the panel on startup, configuring it as 480x272 as expected. Because when my Stellaris board comes along and reads out those registers I'm getting absurd values (15 x 793), this means my board is probably pulling a line during the critical startup phase. Next stop - connect it all back together and probe with a scope to find out what I'm doing wrong.