STM32F4 discovery with LCD

It's been pretty busy lately and I haven't had time to post lately. Hopefully I'll be writing the next chapter on serial protocols soon (I've got new test board where I plan to actually use the improved routines), but for now there's something else.

After finishing with more urgent tasks I've been playing with STM32F439i discovery board. Whenever I've started with new processor earlier the rule of thumb has been that it will take a week to get basics going - you know, development environment set up, programming interface made, clocks set up, timers running, LED flashing. This it only took maybe a day to get to that point since it seems most ARM-based devices are very similar today and there's a plenty of examples around. And of course board can be programmed through USB too so no need to tweak with programming setup.

The bad thing is that in my experience the examples and libraries provided by chip manufacturer are utter crap. This wasn't exception either. While I understand why they exist - to get things running quickly for beginners - they make things unnecessarily difficult for us that prefer to program the hardware registers directly (and more importantly actually understand what they do - libraries tend to hide the ugly details so when something goes wrong you're out of luck.)

Libraries also come with lot of extra cruft so picking the parts I need for the job gets difficult - like USART, I mostly need just simple 8N1 serial with no flow control -- everything else is noise I have to filter out.

But the main topic here, the nice LCD-TFT display the board has... The thing I hate with these displays is that before you can see anything they require lots of settings programmed in (typically by using SPI-like 3- or 4-wire bus), and even single bit error in middle will easily result just blank screen. When dealing with some random display from somewhere you are lucky if you find datasheet that tells you next to nothing, or some snippet or datasheet written in russian or chinese (don't read this as an insult towards either; I just can't read either so such things don't really help me much.) 

In this case most examples use the libraries mentioned above, which of course gets annoying since that's exactly what I don't want. Trying to find and read the library sources may or may not get you anywhere. Most examples I found didn't include SPI setup either, or used different display so they weren't of much use. 

Reading board schematic and LCD datasheets, along with LCD controller's (which were not the best I've seen but not worst either) gave me serial pins and operating mode; fairly typical setup of chip select, serial data, serial clock and data/command pins. Since SPI example I managed found somewhere wasn't working I had to resort to hard methods: loading example program to chip and probing it's setup with scope.

One byte shown. Here yellow is serial clock, purple is data, green is chip select and blue command/data selection; it's high so this byte is data. Fortunately since CS is disabled between every byte it's easier to read as there is clear space between bytes.
Deciphering above gives us bits 00010000 (MSB first, data on rising edge of clock) - so byte is 0x10. There were some 100 bytes in total so reading it all out took a while. And this process is very sensitive to interruptions - fortunately I got lucky and no one called so I didn't have to backtrack to see what I just had done. And this obviously requires a scope where entire burst fits in memory at one go, LeCroy I'm using has 500kpoint sample memory which was enough. Higher-end scopes may have routines to decipher serial data build-in but I had to do this the hard way.

Move these bytes to code and whops, display is working! (I had written MCU-side LCD controller setup earlier and it seems to be working already - that part was relatively simple).

(If someone wants I can provide working code example too, end result was surprisingly short, around 200 lines including comments and empty lines for setup part)