Missing volatile qualifiers in MCU vendor header files?

Dave Nadler schrieb:

Have a look at the definition of the structure (i.e. TIM_TypeDef), where all the variables have the attribute __IO which should make them volatile.

Tilmann

Just stay away from the hardware guys' software, write your own.

I lost 6 weeks of debugging using Atmel's driver mess. The ST code is not any better.

The CubeMX is good in handling the pin allocation puzzle, but I'd very careful about the offered software.

Too true. Software provided by silicon vendors is consistenty awful. It tends to be bloated and full of errors. I don't know who they hire to write libraries and demo apps, but they haven't a clue.

Usually the only thing that can be salvaged are header files with register offsets and bitmasks. Even then you have to double-check them for errors.

When a new engineer is hired, the first thing he/she has to familiarize with the company products. Making demo apps is a good way. Unfortunately, these private demo applications are published without checks by a more proficient person :-).

Thanks Tilman! I missed that, from core_cm4 in both these instances...

Yup, I had to write my own drivers for ST DMA, timer, SPI.

But it gets quite impractical to write one's own drivers for every ethernet and USB peripheral set etc... And lots of the vendor stuff absolutely does not work (ST for example).

Now if I could only figure out why my release build works, but not the debug build (reverse of the usual puzzle!)... Off to check the timing on the scope!

PS: Really not where I expected! Better if ptr is volatile, not struct or fields. Explained well by David Brown here:

Hey! A cite! I'm famous :-)

The most important part is to have the volatile /somewhere/. An extra volatile in an access never makes a program incorrect, but a missing volatile in an access can make it subtly incorrect. The "best" place depends on how much control you want, how explicit you want to be, how much you understand things like ordering between volatile accesses and non-volatile accesses (there isn't any), how much you want to fight for the last drops of efficiency, and of course how clear the code is.

We already knew that ;-)

Yes - my name is on tractors around the world, the credits of "Jaws", and several dozen Wikipedia entries. All my work :-)

More realistically, I have made comments about "volatile" in quite a few places over the years.

Remember that fame is volatile.

Very nice Phil! We're breathlessly awaiting David Brown's definitive treatise on memory barriers...

And the 'DB' in Aston Martins.

Always write separate header files for the cpu and each of the on chip peripherals as a first task for every new processor. It's a good way to get a top level overview of the machine and capabilities.

Had a look at the ST code examples and their obscure header file mess for cortex years ago. Our way or the highway and unusable as presented. Code examples were rubbish as well. May be better now, but still useless if you have a house standard for form and function...

I bet they're no worse than NXP. The header files and demo sources for the KL03 family were an utter disaster. The simple "hello world" and LED flash apps were so huge due to the bloated libraries that they wouldn't even fit in the flash memory of the smaller members of the family.

Probably worse. AFAICT, uController demos are all written by people who think a Raspberry Pi 3 is a tiney embedded system and can't do anything unless there's a button for it in the Eclipse toolbar.

You'll have to excuse me now, those darn are kids on my lawn again...

and the ubiquitous dB

Aston Martins are built by David Brown, but dB is named after Alexander Graham Bell.

At least Atmel and ST made the mistake by attempting to cover all the processors types with one set of sources.

This led to a sorry mess of conditional code, which is undecipherable even for a seasoned programmer. (me: over 50 years of embedded code).

We agree. In the end we wrote a (sort of) parser for ARM's SVD file format to produce our header file equivalents. Several others have gone down this route too.

Stephen