ronan_rt Posted April 5, 2017 Report Posted April 5, 2017 Hello folks! I was working with SPI communication. As we already talked, the change of the screens and buttons was too slow. Due this reasons and other reasons, We decided to change our hardware to parallel communication with the RA8875 driver. As a matter of fact, the change of the screen speed improved, but still very poor. Is there any chance of getting rid of the white clear screen every time we change our screen???
Joel Bodenmann Posted April 5, 2017 Report Posted April 5, 2017 Can you give more information about this? What kind of hardware are you using? What type of bus? what speeds? Even if you're just using an 8-Bit parallel bus connected to the FSMC interface of an STM32F103 you should easily get a speed improvement of factor 10 to 20. If you still have visible screen updates you're doing something very wrong. Any additional information would help and, if possible, a video showing a screen update.
ronan_rt Posted April 5, 2017 Author Report Posted April 5, 2017 Thats the video. Im even using a better uC: stm32F105 now. I am pasting the write index and write cmd just in case static GFXINLINE void write_index(GDisplay *g, uint16_t index) { (void) g; (void) index; // HAL_GPIO_WritePin(E_RD_GPIO_Port, E_RD_Pin, GPIO_PIN_SET); HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(RS_GPIO_Port, RS_Pin, GPIO_PIN_SET); if(index & 0x80) HAL_GPIO_WritePin(D7_GPIO_Port, D7_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D7_GPIO_Port, D7_Pin, GPIO_PIN_RESET); if(index & 0x40) HAL_GPIO_WritePin(D6_GPIO_Port, D6_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D6_GPIO_Port, D6_Pin, GPIO_PIN_RESET); if(index & 0x20) HAL_GPIO_WritePin(D5_GPIO_Port, D5_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D5_GPIO_Port, D5_Pin, GPIO_PIN_RESET); if(index & 0x10) HAL_GPIO_WritePin(D4_GPIO_Port, D4_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D4_GPIO_Port, D4_Pin, GPIO_PIN_RESET); if(index & 0x08) HAL_GPIO_WritePin(D3_GPIO_Port, D3_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D3_GPIO_Port, D3_Pin, GPIO_PIN_RESET); if(index & 0x04) HAL_GPIO_WritePin(D2_GPIO_Port, D2_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D2_GPIO_Port, D2_Pin, GPIO_PIN_RESET); if(index & 0x02) HAL_GPIO_WritePin(D1_GPIO_Port, D1_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D1_GPIO_Port, D1_Pin, GPIO_PIN_RESET); if(index & 0x01) HAL_GPIO_WritePin(D0_GPIO_Port, D0_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D0_GPIO_Port, D0_Pin, GPIO_PIN_RESET); //index write HAL_GPIO_WritePin(R_WR_GPIO_Port, R_WR_Pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(R_WR_GPIO_Port, R_WR_Pin, GPIO_PIN_SET); HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); //release_bus(g); HAL_GPIO_WritePin(RS_GPIO_Port, RS_Pin, GPIO_PIN_RESET); } static GFXINLINE void write_data(GDisplay *g, uint16_t data) { (void) g; (void) data; //HAL_GPIO_WritePin(E_RD_GPIO_Port, E_RD_Pin, GPIO_PIN_SET); HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(RS_GPIO_Port, RS_Pin, GPIO_PIN_RESET); if(data & 0x80) HAL_GPIO_WritePin(D7_GPIO_Port, D7_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D7_GPIO_Port, D7_Pin, GPIO_PIN_RESET); if(data & 0x40) HAL_GPIO_WritePin(D6_GPIO_Port, D6_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D6_GPIO_Port, D6_Pin, GPIO_PIN_RESET); if(data & 0x20) HAL_GPIO_WritePin(D5_GPIO_Port, D5_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D5_GPIO_Port, D5_Pin, GPIO_PIN_RESET); if(data & 0x10) HAL_GPIO_WritePin(D4_GPIO_Port, D4_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D4_GPIO_Port, D4_Pin, GPIO_PIN_RESET); if(data & 0x08) HAL_GPIO_WritePin(D3_GPIO_Port, D3_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D3_GPIO_Port, D3_Pin, GPIO_PIN_RESET); if(data & 0x04) HAL_GPIO_WritePin(D2_GPIO_Port, D2_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D2_GPIO_Port, D2_Pin, GPIO_PIN_RESET); if(data & 0x02) HAL_GPIO_WritePin(D1_GPIO_Port, D1_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D1_GPIO_Port, D1_Pin, GPIO_PIN_RESET); if(data & 0x01) HAL_GPIO_WritePin(D0_GPIO_Port, D0_Pin, GPIO_PIN_SET); else HAL_GPIO_WritePin(D0_GPIO_Port, D0_Pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(R_WR_GPIO_Port, R_WR_Pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(R_WR_GPIO_Port, R_WR_Pin, GPIO_PIN_SET); HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); //release_bus(g); HAL_GPIO_WritePin(RS_GPIO_Port, RS_Pin, GPIO_PIN_SET); } VID_20170405_121654538.mp4
Joel Bodenmann Posted April 5, 2017 Report Posted April 5, 2017 That is horrible. That is horrible and most likely a lot worse than SPI. The idea of a parallel interface is that you don't have to set every pin separately. Each call to HAL_GPIO_WritePin() results in multiple function calls which all take time (and memory). Connect your display to the FSMC interface of your STM32 microcontroller - it has been built for applications like this and you'll have an amazing boost in performance and tons of more free CPU resources. Using the FSMC interface allow writing to the display using just one write instruction of the processor. That's blazingly fast. Furthermore, it takes care of handling the WR, CS and RS pins correctly as well. What you're doing right now is having 15 functions calls to HAL_GPIO_WritePin() which results to other nested function calls. A function call is a very expensive operation and takes up a lot of time. You should easily get 20 to 30 frames per seconds using the FSMC interface while also freeing a lot of CPU and memory resources at the same time.
ronan_rt Posted April 5, 2017 Author Report Posted April 5, 2017 (edited) Well, Im screwed! Ive already printed my board with separated Pins. Is there any chance that I can use a regular pin to make this happen faster?? I mean: do I have to change my hardware or I can set any regula I/O FSMC?? Edited April 5, 2017 by ronan_rt
Joel Bodenmann Posted April 5, 2017 Report Posted April 5, 2017 Some hardware abstraction layers allow setting an entire port at once which would already speed this up a bit (roughly about 5 times). However, that would require that all data bits are connected to the same port (and in correct order). But as far as I know that isn't supported by CubeHAL anyway. But even if you would still loose tons of performance. There's really no way around this. The FSMC interface has been designed exactly for this. For the future: Feel free to either ask here on the forum or contact us directly as part of our paid support service if you'd like us to look over your hardware design prior to committing to it. We're happy to help wherever we can.
ronan_rt Posted April 5, 2017 Author Report Posted April 5, 2017 I think cubeMX have this feature. Look at this: I The problem is that maybe stm32f105 doesnt have this feature
Joel Bodenmann Posted April 5, 2017 Report Posted April 5, 2017 That is LTDC, that has nothing to do with this. It's basically an internal display controller that allows connecting a bare display panel directly to the microcontroller without an additional dedicated display controller chip. That's not related to the parallel interface or the thing I mentioned above. And if your data bits are not properly connected to the same port you won't have any chance at all anyway. And even then you'd loose a lot of performance.
ronan_rt Posted April 5, 2017 Author Report Posted April 5, 2017 (edited) Maybe the BTE software acceleration of RA8875 will resolve this? What do you think?? Cos im seeing here: not every Stm32 have this FMSC. In fact, stm32F103 have!! But only the high density ones! (above 100-144 pins) Edited April 5, 2017 by ronan_rt
Joel Bodenmann Posted April 5, 2017 Report Posted April 5, 2017 No, it will not. The problem you're having is that you spend ages in writing something to the RA8875. It's a hardware problem. You need to wire the display up to the correct pins - there's no other choice. You could hack your own HAL function to write all the data pins at once if they are on the same port. I do have a system with an STM32F103 and an SSD1289 connected via 8-bit parallel bus and I don't use the FSMC and the performance is still great (probably 10 times faster than SPI). But that requires that you wired all your data pins to the same port and in the correct order (to not have to spend further time shifting the bits around): static GFXINLINE void write_index(GDisplay *g, uint16_t index) { (void) g; writePort(GPIOE, index); CLR_RS; CLR_WR; SET_WR; SET_RS; } static GFXINLINE void write_data(GDisplay *g, uint16_t data) { (void) g; writePort(GPIOE, data); CLR_WR; SET_WR; }
ronan_rt Posted April 5, 2017 Author Report Posted April 5, 2017 Very nice!! I will see if this will work. Unfortunatelly I will have to scratch all my pcb. Thanks my friend! Almost reaching to the end of the project
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now