Drive dual displays from a single STM32F400 series MCU

[luke23]

Posted on January 09, 2018 at 07:07

We are designing for an application having front and back-facing 7' displays.  I am keen to hear suggestions for running both displays from the same processor using using LTDC or display peripheral?

Both displays will have different images.

Resolution will be somewhere around 800 x 480 in each display, so relatively lo-res.

[Andrew Neil]

Posted on January 09, 2018 at 16:45

Please don't put the entire question into the summary!

[Tesla DeLorean]

Posted on January 09, 2018 at 17:35

Displaying the same content?

Physical dimensions are less relevant than the resolution.

I'd probably use displays with their own controllers, and map those at different addresses within the FSMC/FMC memory space.

[luke23]

Posted on January 09, 2018 at 20:32

Thanks, Clive. Trying to keep display costs down by removing the controller from them, I tinkered with the idea of muxing and manipulating the display drive signals from the LTDC.

In this scheme, logically I would have a single display, 2xW X H - ie. side-by-side display buffers - a single double width display.

Then I would feed the HSYNC, CLK and DE (data enable) signals (VSYNC would stay the same, since number of rows has not grown) through the SMT32 timer/counter peripheral to generate proper versions for each display. The HSYNC and front porch for the 2nd display is effectively delayed, and the CLK is muted appropriately such that each display sees the correct signalling. (I hashed together a quick diagram (attached) which may represent the idea, although not all details are properly portrayed. The red areas show where the clock would be muted as seen by each display, by the timer peripheral. Similar treatment for DE signal (not shown) too. Here is an example display:

http://www.koe.j-display.com/upload/product/TX18D205VM0BAA.pdf

, timing diagrams page 9, 10)

I understand that the effective maximum screen update rate is halved with this method, and this is of no concern in this application.

My concern is that the signal 'pausing' for 2nd display while 1st display is having RGB clocked in, and signal 'pausing' for 2nd display while 1st display is having RGB clocked in, may affect image stability.

Has anyone tried such an approach before?

________________ Attachments : Muxed Dual Displays.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyCW&d=%2Fa%2F0X0000000b4W%2FxX3guxugaJvLyTlgzJDdZhWf0O_D9kn2CLzYt2a5Xas&asPdf=false

[waclawek.jan]

Posted on January 09, 2018 at 22:22

Trying to keep display costs down by removing the controller from them

How much do you expect to spare? Is it worth the hassle? Even if you device a scheme, it may fail short of expectations in performance, and you may end up fighting for bandwidth. But it's your leg to be shot into.

My concern is that the signal 'pausing' for 2nd display while 1st display is having RGB clocked in, and signal 'pausing' for 2nd display while 1st display is having RGB clocked in, may affect image stability.

I'm not sure the display would like it at all; and I'd expect great variation between displays in this respect.

It would be easier to use half the data for each display, i.e. give up some color depth, and the rest of signals would go in parallel to both displays. That would require no glue logic and result in 'normal' timing. Drawing on it will be lot's of fun, though.

JW

[luke23]

Posted on January 09, 2018 at 22:31

Excellent suggestion - thanks.  I had dismissed this idea because of the requisite and worrisome customisation of a graphics library.  For a 24bit logical RGB, I would end up with 2 displays at 16 colours, or else if my displays shared colour depth asymmetrically, I could have black/white and 7-bit colour in the extreme case.  Perhaps I'll revisit this.

Does anyone know of a graphics library which natively supports this kind of colour-depth buffer sharing?

Regards

[luke23]

Posted on January 09, 2018 at 23:11

I guess it is fairly easy to use an existing graphics library to maintain two logical display buffers with the independent screen contents.  Another process can perform a bitwise amalgamation of the two buffers in some order (perhaps line-by line on a HSYNC pulse, or by buffer entirety on a VSYNC pulse) to compose the buffer operated upon by the LTDC.  This sounds just as processor intensive as a graphics library operating directly into a display buffer shared on some bit scheme, but definitely easier programmatically.

[luke23]

Posted on January 17, 2018 at 00:48

For anyone interested, I found this app note:

http://www.st.com/content/ccc/resource/technical/document/application_note/05/4b/32/22/50/1d/42/02/CD00278141.pdf/files/CD00278141.pdf/jcr:content/translations/en.CD00278141.pdf

It utilises the FSMC (flexible static memory controller) on an MCU that may not have a display peripheral, along with some GPIO pins to generate the sync signals through a manual setup.  I imagine that with this kind of approach, multiple less expensive displays could be supported with enough GPIOs.  Perhaps even one display could reside on the FSMC/GPIO and the other on the LTDC (display peripheral).

For my solution, I have considered that the selection of an 'MCU interface' (ie. 8080/6800) display will suffice despite the additional cost of the controller in the displays, which inconvenience is judged to attract some other design simplifications and reductions in development risk.

[T J]

Posted on January 17, 2018 at 01:14

You should consider an external drive chip.

like Ra8876 $5 each + memory + pcb, connectors etc,  maybe $20 each board.

that would offload the processor overhead. 4 displays would be ok.

if you use the RA8877, you can have 18.5' LCD 1366 x 768,

as an extension to that, the 10 point touch USB screen can be added.

[T J]

Posted on January 17, 2018 at 01:26

I think you will need to continue clocking the display to keep it refreshing the panel.

I think if you try to pause the display, the colours will change to some extent and blocks of the display will shimmer