W80x the GPIO Slow problem

W80x The main frequency speed is very high, Used to connect the color screen, The screen display should be more than enough, However, the actual test found that the screen brushing speed is very slow. Use 8BIT Parallel mouth brush screen, The actual test is not as good as the main frequency running 48MHz the STM32F030F6 Brush screen speed is fast! ! ! Then began a detailed investigation!
Test hardware as follows:

welded W801 chip, But use W806 s bare computer SDK Engineering test, The aim is to avoid W801SDK engineered RTOS And features such as interrupts affect test accuracy.
Test full screen clearing only, Screen resolution is 240*432, 8080 Parallel port, The screen flushing data is RGB565, Write twice 8bit For a pixel point.

Specially optimized LCD The core code and compiled code are compiled below:
Look out, To avoid error, post-optimization, Every instruction read and write GPIO register! ! ! No redundant operation! !
single for In cycle 8 A closely linked ST. W order, All single-cycle operations GPIO! ! And a loop jump instruction BNEZ! ! Compared to normal GPIO Controls, "read ld. w--change bseti/bclri--write st. w" , Nothing more "read--change" procedure, only "write" procedure, In theory, the slow brush speed caused by the erosion of code writing is eliminated! Also convenient for subsequent speed testing

Theoretical calculation: By the above instruction ST. W All are single period, Skip instruction BNEZ Because to clean the assembly line as 3 cycle, Let's write one pixel 10 a CPU clock, Hereinafter referred to as 10T.
write 240*432 Pixel requirement 1036800T
Run on the main frequency 240MHz Under this circumstance, The time it takes to display a screen is 4. 32ms, That means you can brush 231. 5 frame/seconds (Forget for a moment whether the screen can take it)
Actual measurement, In order to 240MHz Main frequency brush screen, It takes time to write a screen 33. 6ms, An order of magnitude slower, only 30 Frame speed I can't receive, Obvious curtain pulling visible to the naked eye! ! ! The actual measuring master frequency runs in 48MHz the STM32F030F6 The screen speed can be close 50 frame!
The test will W801 The main frequency is reduced to 80MHz, Something fishy was found here, It takes time to write a screen 36. 4ms, Only a slight increase?

The screen is not three times slower. There's something fishy here. It should be GPIO Velocity sum CPU Clock speeds do not match.
Because the logic analyzer on hand is not good enough to measure IO Turnover speed, Borrow on purpose 10Gsps The oscilloscope test.
Measure the waveform of the data bit pin: Write a pixel time bit 360ns, To wit 10T The time it takes to, In theory 10T It should take 41ns around

measure WR The waveform of the pin: The interval between the two clocks is represented in assembly as:
GPIOB-" DATA = gpiob_cache_clr;
8011d6a: dda32000 st. w r13, (r3, 0x0)
GPIOB-" DATA = gpiob_cache_set;
8011d6e: dd832000 st. w
Here's the obvious finding, GPIO Clock only 20MHZ? ? ? ? ? ? ? ?
20MHz The design of some genius international joke? ? ? ? ! ! ! ? This is the main frequency 240MHz The processor of Ah! ! ! ! What do you have to do 50MHz All right? ? ? ? ? ?

Guess from the manual, moreover CPU During the interview GPIO It should be when it's not AHB-AHB2-APB The path of, Write in GPIO After operation similar to bus-busy, CPU Been waiting for death, This is what happens 20MHz The spectacle of this situation.

Swiping a screen to close a curtain is not acceptable, To get some speed, I read and re-read the manual that was written in Chinese but didn't know what it was CLK section, understand APB The clock is controlled by WLAN Root clock management? ? ? inexplicable+1


"If wish WLAN System working properly, WLAN The root clock needs to stay on 160MHz", Secondary bus clock and APB The clock is quartered for this clock, Here again 2 Frequency division is GPIO clocklike 20MHz
will wlan Root clock from the original 480MHz/3=160MHz Adjust to 2 Frequency division 240MHz.

In this way GPIO The speed is up, There are 30MHz the, Figure single cycle execution 33ns:

It's screen time 22. 5ms, This speed has 40 multiframe, Finally, no curtains

Now here's the problem: Such direct overshooting WLAN Root clock, wifi The function is definitely not working.
Do the authorities have a solution? Or open some clock-splitting configuration registers, let APB and AHB2 The quarter clock relationship is not bound.
Retention or not wifi Function supported cases, enhance GPIO The speed of.
Dominant frequency 240MHz How embarrassing it is to talk about it like that. . .
You said that other people write bad brush screen slow can blame users will not use, This problem is if the official does not give a solution or develop a hidden register, You can't optimize it with a fairy user, We can't give you a clock cycle to squeeze one into two operations?

See more