NeoChrom GPU

[Jack3]

I read https://blog.st.com/neochrom-gpu/.

Since it was stated that the NeoChrom GPU is incorporated into STM32U5 MCU's, I bought a NUCLEO-U575ZI-Q to learn more about it, because it could be interesting to use it for future projects for my work.

However after I received the board and started reading the datasheets and reference manuals, it turned out there's no mention about the NeoChrom GPU.

Are there any MCU's out there that do contain them? I could not find it.

MCU Finder does not know a category NeoChrom GPU.

Is it just a future plan to add something great like that?

[Tesla DeLorean]

Only described in the context of the STM32U599 (and U5x9 parts)

https://support.touchgfx.com/4.19/docs/development/touchgfx-hal-development/touchgfx-generator

https://support.touchgfx.com/4.20/docs/development/scenarios/touchgfx-on-gpu2d

[Jack3]

OK, I thought the STM32U599 only was mentioned in the context of amount of memory for the NeoChrom.

According to MCU finder, no developments boards exist with STM32U599. which means nothing exist yet to learn about NeoChrom GPU.

Unfortunately, just now I just read about NeoChrom "The problem is that it comes with significant performance penalties.", so maybe I should just forget about it.

https://blog.st.com/neochrom-gpu/

There is a great collection of Nucleo and Discovery boards on my desk, G4, F4, F7, H7, Dual-Core, with Ethernet, Chrome-Art, etc. I like them much! I'm always looking to expand the collection with something new to learn. I thought it was the NeoChrom GPU.

I just need to be patient.

I very much like the STM32 family offerings of peripherals and their features.

UPDATE:

ST does not offer GPU2D for their developer community, and has no plans to do so.
They intentionaly keep it out of reach, so they simply announced some useless dust.
ST's GPU2D should always be left disabled to preserve power consymption, or better, just choose a MCU without this useless peripheral!
This new strategey clearly shows a decline in the support of their products.

So, forced to look further than just ST, we found an Dutch vendor (tree letters, starting with 'N') which has it all, even better, their stuff runs at over 50% higher clock speeds. They also have MPU's. IDE is also eclipse based. For now, we are going to switch for a number of new product developments to a new eco system. A nice addition!

[Tesla DeLorean]

It's going to need a lot of local memory to operate on to do so efficiently, and the IP itself is likely to be quite large. Die size and wafer yield being of particular concern in the current market conditions.

Perhaps discuss with your local sales reps and contact as to the release schedule for the STM32U599-DISCO board, as this looks to be the primary vehicle at this point. I don't see an related RM for more details, but perhaps something a local FAE could provide or discuss.

[Jack3]

Thank you very much!

I also think the IP is quite extensive for an MCU and will grow with each new version of it.

At my work I have been driving all new developed hardware to the STM32 eco system, from another known vendor. It is greatly reducing development time, and the STM tooling (compiler and probe) is fast and reliable.

Even some legacy harware has been converted to the STM32 family of MCU's recently!

As a bonus we got rid of the use of a few very expensive ADC chips as the ADC in the STM32 met our requirements (as oposed to the previous used MCU).

The tooling and compiler of the other vendor was very frustrating slow, buggy and below hobyist level. It even required a license to use the crap. The IDE needed to be restarted every once and again and the probe always required reflashing again and again until it would eventually succeed. I think many readers know the vender by now. Their MCU's are extremely sloooooowwww, in compare with the STM32 MCU's.

[Piranha]

Just a note and warning... STM32 hardware is fine. Nothing is perfect, but still those MCUs are decent and hardware issues are at a reasonable level. CubeMX tool is fine for selecting pins and exploring clock settings. But take a note that the CubeMX generated code and the HAL library are a broken bloatware. The same is true for ST's made USB stack, EEPROM emulation and with some exceptions almost all other firmware components. What that means is - use the nice STM32 hardware, write your own code and use decent libraries, not their junk. Of course, if you care the reliability and performance...

Just as an example - almost all of HAL drivers are full of this stupidity:

https://community.st.com/s/question/0D50X0000C5Tns8SQC/bug-stm32-hal-driver-lock-mechanism-is-not-interrupt-safe

[Jack3]

What are decent libraries apart from HAL?

I'm very interested to learn other and especially better libraries, if exist.

I have been using a lot of HAL for the last 4 years, mostly bare metal (no RTOS), and use STM32CubeIDE. I use CubeMX one time only, and never let it touch (interfere with) my code (it will break things for sure, since I sometimes need to correct, modify or extend HAL libraries), if it comes to Ethernet and EMMC for example. HAL libraries do not appear to be lean, fast and bug-free, by default.​ Still I think it reduces the development time of most of my projects.

[keymaker]

STM32 HAL libraries are mostly fine. What I do is step through their execution and watch what they do - match it up with the reference manual. Myself, I find the libraries simple to understand, and by tracing what the library is doing I in turn understand the MCU more in-depth and can sometimes imagine what the ST employee was doing as the library was written. I don't think the HAL is badly bloated but is rather elegant for the most part.

With any embedded project, don't just assume a library works - trace it.

When I started with the STM32F7, I worried about the HAL supplied by ST - after review accepted it was sufficient and now have multiple products in the world using STM HAL.

[vrbadev]

I am particularly curious about the NeoChrom GPU and its possibilities in acceleration of computer vision algorithms. However, the GPU is only presented in the context of GUI and displays.

Is it possible to use the NeoChrom GPU for custom computations (using the official libraries, for tasks such as convolution with custom kernel) or is it intended only for text manipulation/2D scaling/2D rotation/3D perspective corrections/etc. as currently presented?

[Piranha]

If you cannot see it or do not care, that doesn't make HAL "fine". If my other post is not enough, then look at this:

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32