4-Wire SPI color local brush screen offset solution
--I was already on the side of success.
Recently in the study of low-speed, lower RAM MCU to drive small LCD or TFT color display to achieve animation effect
First I use a 16MHz crystal M0 core of the 8-bit microcontroller nRF51822 try to drive a 1.77-inch 4-wire SPI screen (128X160),
Found, brush a screen about about 0.8s of time,
Specifically included in the "1, a simple nRF51822-driven Tianma 4-line SPI-1.77 inch LCD color Display Demo"
Think that if you use a 72MHz STM32 maybe the effect will be much better
so A similar version was made on the Stm32,
Specifically included in the "a simple stm32vet6-driven Tianma 4-line SPI-1.77 inch LCD color Display Demo"
Found brush a screen of about 0.2s,
The effect is there, but can not reach the effect of playing smooth animation!
later, using Stm32 to drive a 2.4-inch 240x320 8-bit TFT screen
Specifically included in the "a simple Stm32vet6 drive 2.4 inch 240x320 8-bit LCD TFT screen Demo"
This size is 4 times times larger than the previous 1.77,
So even the use of 8-bit speed or not too much change!
then, accidentally found that the use of single-chip hardware SPI speed back much faster (3-8 times)
This is mainly because the hardware SPI uses the following software simulation of the process of unnecessary shift, replication, level reversal using hardware to do the ~ (guessing)
1 voidSENDDATASPI (unsignedChardat)2 {3UnsignedChari;4 for(i =0; I <8; i++)5 {6 if(Dat &0x80) !=0) Sda_set;7 Elsesda_clear;8 9DAT <<=1;Ten One scl_clear; A Scl_set; - } -}
Nevertheless! Still can't realize the animation refresh effect of big chunk picture ~
So Brainwave, perhaps using 16-bit parallel port + simultaneous data transmission using hardware brush screen speed will fly up!
Oh, in fact, it is long known this method, but also the last killer
If it is not in the DSP, FPGA has to move out ~
In fact , the above idea has a very domineering (clumsy) address--FSMC (Flexible static memory controller, variable static storage controllers)
So, I bought a local tyrants gold screen--
Just look at the introduction of the screen to know people are not simple--( Speed earthquake quartet !!!) )
haha, it's far away. ! (Start talking about the content of this section ha ~)
In fact, the focus of this section is not to show the local tyrants screen of this fast-shaking quartet,
Instead of a sudden bug , I had to drop the local tyrants screen and concentrate on the bug.
The bug is this--
I got a 4-wire SPI 220x176 screen that wanted to write a drive
It was supposed to be a matter of minutes, but there was a problem with a pit for a few days:
Get the screen and its information as follows: where GC9201 for its drive ic,qtb2d0052 and 60 is the specification of the above screen, just slightly different appearance size, compressed file is a project containing a simple demo
Http://pan.baidu.com/s/1eQRuP4u
① find the corresponding PIN in QT---52 and set it up well:
② Reference compressed file driver, in the driver file implementation of the brush screen, draw strips, display frames, draw a gradient strip, draw black and white lattice, in the middle of the screen to display a black, draw a little, draw a line, draw a net LCD screen driver function ~
1 intMainvoid)2 {3 intx, y;4 gpio_init ();5 lcd_init ();6 7 //Drawgird (RED);8 9 while(1<2)Ten { OneDispcolor (GREEN);//Brush Screen ADispband ();//Show Bands -Dispframe ();//Display window -Dispscalever ();//Gradient Color theDispscalever_red ();//Red Gradient -Dispsnow ();//black and white lattice -Dispblock ();//show a black block in the middle, but full screen refresh - + for(x=0, y=0;x<149; x++,y+=2) - { + Putpixel (x,y,blue); A } at -DrawLine ( -, -,5,6, RED); - Drawgird (RED); - } -}
At that time the package drive in: http://pan.baidu.com/s/1bnX69Mf
③ is supposed to refer to the manufacturer of the demo should be one go, but the most pit Dad's problem is not possible problems in the place "" " God Pit " "
When the smooth test finished dispblock (), Putpixel (x,y,blue) function can not always draw the corresponding points, and then I tried DrawLine, DrawGrid, there are a lot of problems
::: The problem- is the full screen refresh can be successful, the location is also right; local refresh either offsets or causes itself and subsequent brush screen errors (specific to the next and last brush)
Step on the pit-- All process: Actually first found this reason before doing a lot of work-originally is directly divided into minutes to write a drive integration into the total project from Flash to read pictures and refresh in the center of the screen, the results always appear offset! So
1, carefully take the manufacturers to check the demo, found that there is no difference, dbug failure
2, and then a translation of the LCD driver writecom command, and did not find anything unusual
3, re-look at the LCD driver IC document, painstakingly found that the command 20h and 21h seems to affect the offset can work
The two commands are found to be related to AC, and the screen may be offset by only a window is specified in the WriteBlock, but the AC value is not modified!
Also found in the table above g1~g220, because of the data is more sensitive, I think these two commands are bound to control the y direction of AC,
Also refer to the 38, 39 to the Y-direction of the window settings,
So conveniently in the Blockwrite added two sentences:
1 voidBlockwrite (unsignedintxstart,unsignedintxend,unsignedintystart,unsignedintyend)2 {3 //ili9163c4Writecomm (0x0037); 5 WriteData (xstart);6 7Writecomm (0x0036); 8 WriteData (Xend);9 TenWritecomm (0x0039); One WriteData (ystart); A -Writecomm (0x0038); - WriteData (yend); the - Writecomm (0x0021); WriteData (Ystart); Writecomm (0x0020); WriteData (yend); + AWritecomm (0x0022); at}
It really has effect!!!
It was very exciting at that time ~
But I was using a drawrectange test, a solid color brush.
integration into the general engineering began to brush the picture problem again ~
-- Although the Y-direction ac is fixed, there is an offset in the x direction, resulting in the translation of the entire image
4, re-turn several times the description of the IC, the target locked in the initialization part of the problem may exist!
Until the comments are all commented out (only two left), although it is found that some of the functions of the command but still did not solve the fundamental problem
5, try to use the calculated offset, pre-filled gram to offset the offset
Find the deviation regularity is not obvious, always fill not completely ~
6, this afternoon really can not endure (I decided that the screen manufacturers gave me a product!) )
So, a divorce found behind the screen--screen driver IC chip factory technician:
Later, the technology pulled me into a discussion group, the content is omitted .... And then come out a bull
See the last sentence of Stax suddenly suddenly enlightened ~ heart there are countless grass mud horse in the Pentium ~
"D-bug poem"
Once I was only a step away from success,
Around a big circle,
Back to the original point ~
The original 20, 21 command is the value of the AC indicating the x direction, a value indicating the Y-direction of AC!
It was a dead end.
Hard to bind start and end in the 20, 21, and Y directions,
Struggling to find the x direction of start and end how to put it!
thus
Understand why the law is always not obvious in the X-direction offset,
In fact, COMMAND-20 will yend as a xstart,
resulting in an unresolved offset ~
Sometimes
You're just a dime from what you want,
Momentary carelessness, momentary negligence, momentary complacency,
Let you know with appearances!
There is no hole in the world, think more, there is a pit!
Bug abolished, the world has returned to calm ~
Test project source code (a transplant demo, a center drawing): Http://pan.baidu.com/s/1c1vlgPy
Note: Thank the IC technical team for their warm help ~
@beautifulzzzz
2015-12-7 Continuous Update in ~
[nRF51822] 2, D-bug's poems