stm32f4xx_hal_rcc_ex.c invalid non shifted comparison

[PCamp.2]

STM32F411.

Line 2693:

   srcclk = __HAL_RCC_GET_I2S_SOURCE();

That macro calls "READ_BIT" on the I2SSRC register bit.

It does NOT shift it right 23U.

The function then compares this to 0 or 1.

FAIL.

Result. I2S cannot be configured to use an external clock source in HAL.

While you are in there there is a bug with the library always initing that register to PLL clocks, regardless of config.

Did someone do a merge fart?

[gbm]

One of the biggest problems with HAL is the lack of use of bool/_Bool type, present in C language since 1999. Unfortunately there are many more equally serious problems making the HAL practically unusable for anything serious and real-time.

[PCamp.2]

I can put a foot in either camp. HAL versus DIY low level coding.

It's basically just allowing multiple "levels" to program at. A high level API / Façade for when you just want to rapidly prototype things without having to study session the datasheet to say, blink an LED or fire up a quick debug UART port.

Having a working HAL library is pretty much a concrete requirement if the platform is to be open and facilitative to rapid application development and rapid prototyping. If it isn't or the library is unstable, usable, then people will migrate to other platforms for rapid development and prototyping. Based solely on the easy of development. They may, or may not return to STM for the final product though.

On the other side, you are hiring a whole catering company, along with all of the equipment to make a banquet and the logicists that come with it catering to 1000s of different tastes and requirements... and using it to make a cheese and ham sandwich. If you follow my analogy.

I did a "Turbo Blinky" test on an F4. HAL toggle was about 800Khz. HAL set/reset about 1400Khz. Hard resister setting was 8Mhz. It was the same on the arduino framework. The amount of checks, translations and "corner cases for bespoke and rare use cases", also the ifdef soup of supporting multiple platforms, it all adds up to an insane amount of unnecessary code.

Thus, I feel the way forward is to decouple my code from the HAL/Generated main.c/h and immedaitely move into custom modules, such that code gen is not an issue if I need it. Then I can start writing my own much more bespoke and project focused setup and handler routines. Using HAL where I don't care (and it's currently working) and using my own custom register HAL library when I need to care or HAL is broken.

STM just need to watch the competitors and what they are doing. They did at least seem interested in the IoT/NoT and maker market with the Nucleo range and the latest efforts with CubeIDE/HAL/MX etc.

That market space is opening as higher tech makes it down to the hobbiest. 50Mhz TFTs approaching HD, HD audio etc. etc. are all now appearing on markers boards. The arduino is dead as a maker platform. I feel that STM32 have failed to jump on this market enough and the Nucleo efforts will be invain, because of one critical decision they made around Wifi. It seems they choose NOT to directly compete against the ESP32 in that space. I think that was the mistake that will mean the STM32 will not make a massive impact into the maker / IoT / Not space. It might get somewhere with the profressional IoT market based on prior brand exposure in that space, but without presenting a viable platofrm in direct competition to the ESP32 they have already lost the race.

There is still market there, but they will need a working and bullet proof HAL library with proper documentation to corner the non-wifi part of that market.

There is still a slight option for the Zigbee / non-Wifi RF market in IoT/Not. But I feel the high end protocols like Wifi, MQTT, HTTP will steer people towards teh ESP32 and not the STM.

[PCamp.2]

Of course, the amateur market and makers space is probably a tiny like slither of the main profressional and industrial embedded systems which make up most of the MCU market.

[KDJEM.1]

Hello @PCamp.2​,

Thank you for reporting the issue.

I confirm this issue and I reported internally.

Internal ticket number: 139649 (This is an internal tracking number and is not accessible or usable by customers).

Kaouthar

[KDJEM.1]

Hi @PCamp.2 ,

This issue is already fixed in Github.

Thank you for your contribution :).

Kaouthar