cancel
Showing results for 
Search instead for 
Did you mean: 

NeoChrom/GPU2D registers documentation

robvos
Associate

Will this peripheral ever be documented in detail? i.e. registers, interrupts, etc.

Or even a lightweight/low level library would be acceptable.

We may choose STM32U5 for a product but not if we are forced to use TouchGFX for good performance.

 

15 REPLIES 15

@DmitryR No doubt new ST MCUs are very strong products. That is why I am still here. However, I start to see a pattern of misleading customers and hiding critical information about product limitations. GPU2D is not the only example. Recently I discovered that USB (OTG_HS) always required external clock or crystal, even when high speed was not used (see this discussion). It is nowhere mentioned in docs but I am quite certain engineering was aware of it. I actually suspected it because NUCLEO-U5A9, unlike other NUCLEO boards, contained two crystals (32.768kHz and 16MHz) - which was not standard. STM32U5xx FDCAN functionality detailed in AN5348 for the large part does not apply to STM32U5xx and it is nowhere clearly stated, especially not in AN5348. On new STM32U5 MCUs FDCAN functionality is substantially limited (details here).
Clearly, software engineering, as a support function generating no income, can hardly follow hardware engineering and marketing. As the result, ST is not a company known for excellent customer support. STM32U5G9 and two boards containing it are already available for purchase (I already received 4 pieces) but still no CubeMX support. I do not even mention HAL quality. Did anyone ever see HAL test suite? Ofc, this question is rhetorical.

Hi Gaetan,

Some follow-up questions:

  • Why is this documentation being withheld from us?
  • Who are these partners?
  • When will we have access to their libraries that use the full extents of NeoChrom abilities?

@mrrobot Best to my knowledge, ST believes that GPU2D is too complex for you (and myself) to handle.
But the true may be that they are still working on docs or MPUs with GPU2D were released prematurely or ST just wanted to give TouchGFX team a head start - who knows for certain? These days not telling customers the truth is a standard business practice.

Hi all,

 

I have mentioned that all other chips from ST use GPUs from VeriSilicon, so it is very likely that U5 uses it too. And those for MCUs from VeriSilicon use VGLite API. It is not at all simple but LVGL implements VGLite starting from version 9.0, so if you play with hardware configuration you may be successful engaging GPU from U5 with LVGL. 

 

Regards,

Dmitry

mrrobot
Associate

Based on all the nema_XXX calls & symbols inside the TouchGFX HAL, it looks like this GPU might be from Think SIlicon: https://www.think-silicon.com/nema-gfx-api

It looks like the NemaGFX API matches the headers in what gets put in Middlewares/ST/touchgfx_components/gpu2d/NemaGFX .  I'm having touble finding documentation for the Nema VG extensions, though.

@DmitryR IC, so probably as long as possible ST wants to maintain impression that GPU2D is ST's invention. It may be another true reason why docs are not released - this is how detached from the reality top mgmt can be.
As a matter of fact, I implemented STM32 DMA2D support for LVGL and was already asked if I could do GPU2D as well but I am still too busy with other projects. Not to mention I truly believe this is something ST could and should engage with although it is clearly against the current ST's philosophy of self-supporting communities providing free product support for badges and kudos and little/no official support but lots of savings. I swear, once TI has comparable product I change vendor. With them it is completely different experience.