NeoChrom/GPU2D registers documentation

[robvos]

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.

[robvos]

I suppose no reply means "No"? That's fine, but an official response would be appreciated.

[GaetanGodart · Accepted solution]

Hello @robvos ,

The NeoChrom GPU documentation will not be made public.
ST partners providing GUI libs supporting STM32 with NeoChrom GPU have access and have already, or are working on, utilizing NeoChrom GPU capabilities to its full extend.

Hope this helps. 😊

[DmitryR]

Hi robvos,

I just want to support you, as I have to complete a relatively complex HMI recently. I was considering TouchGFX, but have found it too rudimental in compare to other libraries. I have instead planned to add a support for NeoChrom to the library I have chosen, but now I will probably need to choose other MCU for HMI.

Regards,

Dmitry

[Jack3]

I really was waiting for ST's GPU2D announcement for a new line of products we are preparing for.

So we purchased the STM32U5G9J-DK2 to see how useful the GPU2D could be for our newest products (maritime industry). The demo shows a few AVIs and some bitmap operations that would improve performance.
And too soon we came to the conclusion that it is of no use for our products! Just because of a let-down on ST's part. The reason is that without any documentation the GPU2D is totally useless.

A new ST strategy deliberately keeps new peripherals undocumented and makes sure developers can't take advantage of them, effectively turning their new GPU2D into useless dust. No support for it! The developer community does seem no longer much important for ST.

It is similar to introducing a new 8 channel single/differential ADC with PGA, and purposely leaving out all the required details from the datasheet while saying it is very accurate. It probably won't sell well.

As a chief engineer I probably went too ST-minded and therefore too short-sighted. I thought we could continue to develop new products with the latest and greatest by sticking to ST. Because ST's GPU2D offering does not benefit its current community of developers, they actually proposed to look at other vendors' offerings.
Is it ST's mistake?

Sometimes it's good to think again and broaden your view. For example, when a product is no longer available, or in this case contains peripherals you are interested in, but on purpose are kept out of reach, so you won't be able to benefit from it.

Because of  ST's new strategy "We have something new, but we make sure you won't be able to use it, so please look elsewhere for it!", we searched the competitors offerings, and with good results! We now (re)discovered a Dutch company - whose three letters I will not mention here - that offers all we look for. And they also have excellent MPUs.

Time to widen our horizon and possibly weaken an STM32 era in our R&D department, one I started myself. As an STM32 minded developer I'm the reason we use them a lot!
As a senior lead engineer I had a meeting with my manager regarding this new ST direction. My manager thought I was joking at first, as I used to be STM32 minded and being the reason we use them a lot! But I quickly convinced him I was not joking, showing both ST's microscopic GPU2D mini-section in the reference guide explaining "we finally have it, but it should not be used by you", and a sheet of an alternative non-ST offering. He asked me to find out more about it and to come up with suggestions. I will spend some more time on it in the coming weeks.

Currently, we use a lot of STM32s in designs because I really liked these MCU's, but deliberately keeping peripherals undocumented is a far different experience for us. We never expected this from ST as it doesn't promote new products and provide weak support to the ST developer community. This tells us how ST rates their customers with declining appreciation.

Of course, this *will* impact our MCU/CPU choices for upcoming products. I have a leading role here, and I'm all set to discover new directions and solutions now.

Since the ST demo kit is not suitable to learn anything new, we have no further purpose for it. When I asked, none of my colleagues were interested in it, perhaps even taking it home. Likely because it offers nothing new to discover.

So after watching a demo where we only saw a few AVIs and a few bitmap operations, I pulled the plug and threw it in the trash bin with a very loud bang. It resulted in very funny reactions from my laughing colleagues and manager, all worth it!!! And complains that I may have damaged the trash bin!

So, if you plan on using this MCU, even though I see no advantage for this one, it is best to leave the GPU2D turned off at all times, in order to reduce power consumption.

Using obscured code in combination with a handful of undocumented graphical features is obviously not an option in critical designs. We have better solutions instead.

I always was STM32-minded, but the new ST strategy changes that quite a bit. It stimulated us to strengthen our knowledge of competing products, and made a new choice for an upcoming line of products. A step to the 1GHz M7 / 400MHz M4 dual-core with their GPU2D from an ST competitor, well described in a 6259-page refence manual. Even their DMA2D operations include image rotation (90, 180, 270 degrees). I think it all looks better. Their IDE is eclipse based too.

Is there any chance that ST will start to care about their developer community a bit more in the future?
I doubt it. For now the community should just pack and leave for the alternative, also called GPU2D.

[TDJ]

@Jack3 It is OK for any company to release a product with or without documentation as long as transparency is maintained and customers are not being misled. I am afraid GPU2D unprecedented case is not an example of such good business practice. Why? An official statement on this subject is nowhere available. It takes lots of search to learn about this new disappointing ST marketing strategy.

[TDJ]

@GaetanGodart', Your response above states that ST's partners already "are working on utilizing NeoChrom GPU capabilities to its full extend". Who are those partners? We do not know, but clearly it is no longer us - mere engineers who once trusted ST Microelectronics. Of course, you have reasons to be happy. Your team's job is guaranteed for years to come but the ending statement "Hope this helps :)" in this thread context I perceive as a bit cynical. Consider that we are very upset here although I do recognize that this decision may be dictated by ST's effort to motivate those who are able to quickly produce high quality software packages and adequate support rather than desire to gain additional profit from license sale and partnership fees.

[DmitryR]

Hi TDJ,

I have just attended the ST´s webinar concerning HMI on the newest MCU´s, and I can say that it is a pure shame. 50% time devoted to reading presentations, 50% time devoted to approve the obvious fact that hardware acceleration works really better that CPU. No study how to build effective HMI with TouchGFX, just loading the predefined example project to U5x9 and H7 boards and comparing results. I see that TouchGFX team has really nothing to promise.

And to your question "who are those partners" is the answer: Microsoft with their Azure GUIX is NOT this partner.

Regards,

Dmitry

[TDJ]

@DmitryR Unfortunately, this is what typically happens when engineering company starts to be dominated by marketing and their clever practices. For some time such strategy seems to work, sales numbers look good, engineering support costs can be reduced, top managers get promotions and bonuses so they keep pretending everything is great. And then one day it begins to collapse. It is sad to see signs ST is heading this direction.

[DmitryR]

Hi TDJ,

I would not say that this happens with STM right as you suppose. In my opinion STM still has some strong advantages in microcontrollers, but the situation with Neochrom and TouchGFX should definitely be corrected. TouchGFX command works not really good and they should be stimulated instead of giving them preferences.

Regards,

Dmitry