What is the best prototyping strategy when using displays?

[Richard Lowe]

I love ST products, but constantly running up against the question of how to prototype various displays.

Discovery Kits, Eval Kits, etc. all have displays, but it seems like the included displays are all to choose from. I am tasked with using a variety of displays but having a hard time matching up the requirements of SRAM and Quad SPI memories for TouchGFX graphics.

Is there a best practice when needing these external memories? Is there daughter boards or breakout boards for these type of peripherals? What is the recommended strategy when you need external memories and displays? Custom PCBs.... Need your recommendations.

[waclawek.jan]

> Is there a best practice when needing these external memories?

There's probably no one single good approach.

If you are okay with the display on given demoboard, go for it; or try to search a ready-made third-party demoboard with a display you intend to use.

You also can try to start with an overkill - a display which is somewhat larger than you need(*), largest possible RAM, widest possible buses, fastest mcu - get familiar with the requirements, try to scale down on that hardware (draw only on a smaller portion of the LCD, use less memory, scale down clocks, estimate effect of narrower buses or emulate it with even more scaling down clocks). One thing to decide early on is, whether you want to use a LCD with a controller, or one without it; that makes the most dramatic differences.

Having a ready-made demoboard which is at least roughly in line with your target, may also give you valuable first-hand experience with what's possible and what's not. Many users are spoiled to expect PC-like or mobile-phone-like dimensions/resolutions/animations etc. Those effects are heavily supported by dedicated hardware, you simply won't have access to (Two decades ago, a graphic designer told me that he wants concentric circular waves to emanate from the point where a touchscreen-enabled display was touched. Our hardware at that time was not capable of a plain clear screen within one frame time. I don't think what he described is possible today on anything but powerful PCs. I can imagine custom-built graphic controller to support this effect in hardware, though. We did custom build the graphic controller, but did not spend effort on this effect... :) ). OTOH, sometimes tricks are available, but which apply only to particular applications, e.g. some LCD controllers feature full-screen scrolls (that's cheap on hardware, the controller simply starts displaying from a different address in RAM), some controllers support hardware sprite(s) (usually only one, for cursor, but even that's way better than to do that in software), etc.

Now TouchGFX and similar tools (look around for options) may bring extra joy to this. I can imagine that using the prechewed examples result in stunningly fast and impressive results; but I'm also not sure how can those be used to estimate the differences a not-that-standard solution entail. But if you intend to use them, it's maybe a good idea to have an early contact with the developers to gauge the amount of support you can expect from them? I don't have experience in this, I'm on the cheap/garage-scale side, trying to avoid external dependencies.

Probably the only way which leads straighforwardly to a result and is not a throwavay learning-and-proof-of-concept experiment, is the painful and expensive prototyping directly the target hardware what you want. Expect iterations.

[What a coincidence! Just this very morning, I've been bitten by having developed some graphics algorithms on a devboard with just a very slightly different LCD than what's in the target... I worked as a contractor in bringing up the platform and now the client got caught by this problem - nothing they could not cope with themselves, and I of course support the needed changes, and they of course understand the reason... but the shame...]

JW

(*) not really an option: the pixel nr thus all requirement grow very rapidly. The perceived "quality" is related to linear number of pixels (higher pixel per inch is better, bigger display is better) - but all requirements (including cost) grow of course with the square of the linear number of pixels.

[Tesla DeLorean]

The bandwidth for higher resolution displays predominate.​

These designs are not capable for FHD or UHD.​

Best to find a good proxy, places like AliExpress are a good place to fish.

QSPI with SOIC16W​ foot print are prolific. Caching on CM7 can hide a lot of the performance issues.

Perhaps look at ART-PI board, has a wide LCD connector.

Look also at DSI base boards and connectors. ST has an adapter from DSI to a 2-Lane RPi ribbon cable.

WaveShare has many boards.

Riverdi has some MCU / Screen combos, as does MikroE.

Should be able to find a suitable proxy to refine your own designs.​