A pet project to program SPI communication protocol from the scratch to control a LCD module with Raspberry Pi.
So it uses a bit banging with GPIO instead of the standard SPI driver. GPIO is manipulated by mapping the memory and controlling directly the register at the address specified by /dev/gpiomem.

The module number of the LCD screen is COG-C144MVGI-08, whose driving IC is Samsung S6B3306 .
In order to manipulate the hardware registers and know their address, I referred to BCM2835 ARM peripheral documentation. At some point, I used wiringPi(http://wiringpi.com/) library to compare the GPIO switching time, etc.

While a sleep function like "nanosleep" is provided for Raspberry Pi, the time measurement showed a huge discrepancy between the desired sleep duration and the actual duration at. This was measured by using oscilloscope and switching GPIO on and off. I recall that the switching time of GPIO measured by the oscilloscope was about 36 - 40 nanoseconds, but this is to be verified.

Anyway, in order to implement a sleep function with correct duration, I used the timer of BCM2835 by mapping the memory at /dev/mem + 0x2000B000.
While this seemed to increase the precision, it didn't work well below 400us, according to the delay_fnc_result.txt (Some part of this text file seems rather cryptic, and I do not know what I was thinking, but what really matters is fortunately intelligible).

The problem seems that we don't have a control over the OS scheduling and resource allocation. To increase the precision and avoid sudden spikes in sleep duration, I probably should use a Real Time OS.

https://youtu.be/34jqGsdNCsc

The video used for the demo is not actually a video but rather a GIF animation (but not exactly. Refer to the PixToMx.m, the matlab file.) It's just a series of bitmap images drawn at a high speed.