STM32F429 and AMOLED screen

[megahercas6]

Posted on October 26, 2013 at 23:51

Hello,

for my project i need to connect HTC Desire screen to STM32F429. it has 800x480x16b resolution, RGB565 standart. To get best peformance, should i use original SDRAM (like in SDTM32F429i_DISCO board), or it would be faster to use SRAM like IS61WV102416BLL-10TLI? And if yes, how much different programming would be, to be able run original STM32F429i-disco programs (Segger UI)? (i only should do config, and rest is fine ?, address looks like will be the same for FMC controller ) Also will i fit into this memory my design ? 800x480 use 384k*16, so with 1M*16 i should be fine ? Many thanks for any help on this question

[megahercas6]

Posted on October 30, 2013 at 15:52 ok, i write all values from amoled.pdf, screen turns on after init, but i get only rubbish data. By probing phone i found that this configuration matched phones rgb565 interface (polarity at least)

/* Initialize the horizontal synchronization polarity as active low */
LTDC_InitStruct.LTDC_HSPolarity = LTDC_HSPolarity_AL; 
/* Initialize the vertical synchronization polarity as active low */ 
LTDC_InitStruct.LTDC_VSPolarity = LTDC_VSPolarity_AL; 
/* Initialize the data enable polarity as active low */
LTDC_InitStruct.LTDC_DEPolarity =LTDC_DEPolarity_AH; 
/* Initialize the pixel clock polarity as input pixel clock */ 
LTDC_InitStruct.LTDC_PCPolarity = LTDC_PCPolarity_IPC;

and init looks like this (via spi)

void spi_wint(uint16_t comand,uint16_t data)
{
//----------------------------------------------------------------------------
LCD_ChipSelect(DISABLE);
SPI_I2S_SendData(LCD_SPI, 112);//114
while(SPI_I2S_GetFlagStatus(LCD_SPI, SPI_I2S_FLAG_BSY) != RESET);
delay(10);
SPI_I2S_SendData(LCD_SPI, comand);
while(SPI_I2S_GetFlagStatus(LCD_SPI, SPI_I2S_FLAG_BSY) != RESET);
delay(10);
LCD_ChipSelect(ENABLE);
delay(10);
LCD_ChipSelect(DISABLE);
SPI_I2S_SendData(LCD_SPI, 114);
while(SPI_I2S_GetFlagStatus(LCD_SPI, SPI_I2S_FLAG_BSY) != RESET);
delay(10);
SPI_I2S_SendData(LCD_SPI, data);
while(SPI_I2S_GetFlagStatus(LCD_SPI, SPI_I2S_FLAG_BSY) != RESET);
delay(10);
LCD_ChipSelect(ENABLE);
delay(10);
/*
LCD_ChipSelect(DISABLE);
SPI_I2S_SendData(LCD_SPI, 114);
while(SPI_I2S_GetFlagStatus(LCD_SPI, SPI_I2S_FLAG_BSY) != RESET);
delay(10);
SPI_I2S_SendData(LCD_SPI, data);
while(SPI_I2S_GetFlagStatus(LCD_SPI, SPI_I2S_FLAG_BSY) != RESET);
delay(10);
LCD_ChipSelect(ENABLE);
delay(10);*/
//----------------------------------------------------------------------------
}
void LCD_PowerOn(void)
{
spi_wint(0x31,0x08);
spi_wint(0x32,0x14);
spi_wint(0x30,0x02);
spi_wint(0x27,0x01);
spi_wint(0x12,0x08);
spi_wint(0x13,0x08);
spi_wint(0x15,0x00);
spi_wint(0x16,0x00);
spi_wint(0xEF,0xD0);
spi_wint(0x30,0x44);
spi_wint(0x40,0x12);
spi_wint(0x60,0xFF);
spi_wint(0x17,0x22);
spi_wint(0x18,0x33);
spi_wint(0x19,0x03);
spi_wint(0x1A,0x01);
spi_wint(0x22,0xA4);
spi_wint(0x23,0x00);
spi_wint(0x26,0xA0);
delay(100);
spi_wint(0x1D,0xA0);
delay(0xFFFFF);
spi_wint(0x14,0x03);
}

now i am stuck and i need some help, for LTCD config, and also config for amoled controller www.youtube.com/embed/ynxbtpwEDu0

[jj2]

Posted on October 31, 2013 at 21:05

I especially like & subscribe fully to Clive's recent advice, ''Remember, something that doesn't work, doesn't impress anyone!''

From our distant perspective - operating w/facts in evidence - it appears that your project has multiple, ''issues'' - both, ''known unknowns'' and ''unknown unknowns.''  (credit past Sec'ty D. Rumsfeld.)  And it is those ''unknown'' which can bite hardest - send your project flying, ''off the rails.'' To my mind - you have too many ''unknowns'' in play - thus may well be driving toward Clive's quoted remark.  Of course you seek to ''win high prize'' - but there may be safer means to that objective - and your adoption will likely raise your odds of project success! Here are major concerns: a) cell-phone display - tres elegant but you have zero operating experience.  And - too often these are not designed to withstand the ''normal'' slings & arrows of ''probing - multiple power-up/down - and your ''semi-skilled'' mounting.  Flex cables are thin - not intended for the added stress of your (necessary) data discovery & extraction.  From what I've witnessed - and read - that display is unlikely to ''survive'' your handling. b) mated, ''Tomato'' controller - had never seen/heard - it is unlikely that you'll get any needed tech support - unless some advanced ''user group exists'' - I hear this device, ''ticking.'' c) M4 running such a pixel-intensive display.  Can you say/spell... S     L    O    W?   How impressive will that be?   As Clive said - other, far more advanced ARM MCUs are the ''normal/customary'' means of pushing this volume of pixels - not anyone's M4... Negative - negative - negative - what is then proposed?   Suggest perhaps a ''bigger display'' - with great contrast - and one readily available w/extensive, real-time, tech-support.  (i.e. someone's current, very well supported Dev Board w/mated/tested color display)  This immediately frees you from all ''digging'' procurement issues - and the likelihood of ''breaking'' an especially fragile screen - not intended for your,  ''novice,'' experimental, ''probing/handling.'' Always favor ''KISS'' and proceed by refinement.  Get the basics of your system working - one element at a time.  When (and if) complete - then you can turn your attention to adding appeal.  Speak w/some experience in this area - have won competitive grants from US NSF & NIH - and in each case, ''pie in the sky'' ran second to, ''make the damn thing ''sorta'' work - then tweak/optimize...'' The fact that you now report, ''being stuck'' is entirely predictable - how many more of these, ''stoppages'' can your design tolerate? The time to develop w/so many things new/unknown - should not be now...

[megahercas6]

Posted on October 31, 2013 at 23:36

Well, when i get pcb adapter for probing, i will findout exact serial lcd init values and registers, and also going to mimic HSYNC VSYNC DCLK and D_ENABLE signals with arm cortex m4.

http://youtu.be/ynxbtpwEDu0

. This is hardest part in this project, backup plan is to use lcd with integrated controller/frame buffer, but i really want to use AMOLED screen, since it is the same size as touchscreen which is already working with STM32F429 in multi - touch mode

[jj2]

Posted on November 01, 2013 at 01:27

Realize that when you state, ''working'' that is very much subjective - a screen w/that many pixels - driven from M4 - will be noticeably slower than any phone...  And - unfortunately - that is one of the first things your contest judges (and important, others) will note!

Suggest that you pay greater attention to the ''known deal-breakers'' in your project - there is good reason that no M4 can be found in modern smart-phone.  Displaying essentially ''text only'' (as I bet you'll be forced to do) and working so hard to ''unlock display secrets'' - seems not the best use of your time/energy. Clive and I are on the same page when it comes to, ''making something work'' - and your Risk-Reward proposition appears less than well considered...

[megahercas6]

Posted on November 01, 2013 at 07:32

Well, LTDC controller can refresh screen at 60Hz, and even my phone has ARM Cortex M4 (Tegra 3). Note that if i optimize painting functions, i can get high fps. As example with stm32f407 i can get 300FPS at 480x272 , so i should get 100FPS (That was set all screen area inside GRAM of SSD1963  and just transmit data memory to memory, without DMA)

[frankmeyer9]

Posted on November 01, 2013 at 14:01

... , and even my phone has ARM Cortex M4 (Tegra 3).

I don't think so. Tegra 3 is Cortex A9 quadcore, i.e. at least 100 times the performance of an M4.Note that if i optimize painting functions, i can get high fps. As example with stm32f407 i can get 300FPS at 480x272 , so i should get 100FPS (That was set all screen area inside GRAM of SSD1963  and just transmit data memory to memory, without DMA) That is actually nothing useful. As soon as you do something more complex than a straight copy loop, you will see the frame rates drop by an order of magnitude. What about double-buffering to avoid flicker ?

[megahercas6]

Posted on November 01, 2013 at 16:37

FIY Tegra 3 has 4x Cortex A9 and 1x cortex M4 for low power mode (yes, not screen, but background android stuff ).

I must connect this AMOLED to STM32F429i. Right now i am trying to get all data regarding timings , so lot of probing with scope phones connector and counting PCLK rising edges in between various  pulses . And after that i will try to mimic same timings with STM32F429. If some one has better idea, please speak up When i get it working, i could switch to S1D13517 to get simple interface to screen, but for now, i will stick with STM32F429i

[frankmeyer9]

Posted on November 01, 2013 at 19:04

... (yes, not screen, ...

Exactly, and not even the A9 cores do the heavy gfx works,

http://en.wikipedia.org/wiki/Tegra#Tegra_3

. It says: ''12-core GeForce ULP GPU (8

http://en.wikipedia.org/wiki/Pixel_shader

, 4

http://en.wikipedia.org/wiki/Vertex_shader

)

http://en.wikipedia.org/wiki/Tegra#cite_note-AnandTech_Tegra_4-16

'' If you use the core to fill the graphics buffer with useful content, the frame rate drops quickly with complexity. I bet you will no achieve 25fps (TV rate) when rendering more than a third of the screen - not even half of that. The second issue I see - your solution is very hardware specific, i.e. in all likelyhood not portable, and represents ''the end of the flagpole''. There are hardly any performance reserves for scaling upward. Perhaps this might not be a problem.

[megahercas6]

Posted on November 01, 2013 at 19:52

Ok, i mapped all timings related to horizontal coordinate, problem is, one pixel is out. :(

So horizontal is stable now, only vertical is ''rolling'' . If i share all timings PCLK count and pulse count relation with one another, can some one point me right LTDC controller register values ? I tried to figure out whem, but no luck so far

[jj2]

Posted on November 01, 2013 at 21:13

''If some one has better idea, please speak up.''

Did not first Clive, then I, and now fm all do that?  We have spoken - you have remained resistant - and multiple, ''unknown unknowns'' still lurk - awaiting your slightest mis-step... Would it not be sufficient to find the best performing color screen available with full vendor support - and pre-mated/engineered to a specific MCU and board?  I've advised you to get ''something'' working - only then - if you must - charge full bore into this ill-fated, cell-phone display reclamation project. As fm & I've stated - if extremely  S    L    O    W   screen updates will really impress your judges - and you do not fear, ''missing'' any/all deadlines - continue your current course... Risk - reward analysis has been sacrificed at the altar of ''hope/dreams'' - that is not terribly unusual - but neither is it wise...