Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29387 > unrolled thread

Missing volatile qualifiers in MCU vendor header files?

Back to article view | Back to comp.arch.embedded

Contents

  Missing volatile qualifiers in MCU vendor header files? Dave Nadler <drn@nadler.com> - 2020-04-05 15:00 -0700
    Re: Missing volatile qualifiers in MCU vendor header files? Tilmann Reh <usenet2007nospam@autometer.de> - 2020-04-06 08:29 +0200
      Re: Missing volatile qualifiers in MCU vendor header files? Dave Nadler <drn@nadler.com> - 2020-04-06 06:54 -0700
        Re: Missing volatile qualifiers in MCU vendor header files? Dave Nadler <drn@nadler.com> - 2020-04-06 14:36 -0700
          Re: Missing volatile qualifiers in MCU vendor header files? David Brown <david.brown@hesbynett.no> - 2020-04-07 00:09 +0200
            Re: Missing volatile qualifiers in MCU vendor header files? Dave Nadler <drn@nadler.com> - 2020-04-06 15:18 -0700
              Re: Missing volatile qualifiers in MCU vendor header files? David Brown <david.brown@hesbynett.no> - 2020-04-07 10:36 +0200
                Re: Missing volatile qualifiers in MCU vendor header files? Phil Martel <pomartel@comcast.net> - 2020-04-07 12:30 -0400
                  Re: Missing volatile qualifiers in MCU vendor header files? Dave Nadler <drn@nadler.com> - 2020-04-07 09:36 -0700
                Re: Missing volatile qualifiers in MCU vendor header files? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-04-07 21:38 +0300
                  Re: Missing volatile qualifiers in MCU vendor header files? Phil Martel <pomartel@comcast.net> - 2020-04-08 11:20 -0400
                    Re: Missing volatile qualifiers in MCU vendor header files? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-04-08 20:15 +0300
    Re: Missing volatile qualifiers in MCU vendor header files? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-04-06 10:05 +0300
      Re: Missing volatile qualifiers in MCU vendor header files? Grant Edwards <invalid@invalid.invalid> - 2020-04-06 13:21 +0000
        Re: Missing volatile qualifiers in MCU vendor header files? upsidedown@downunder.com - 2020-04-06 16:31 +0300
      Re: Missing volatile qualifiers in MCU vendor header files? Dave Nadler <drn@nadler.com> - 2020-04-06 07:14 -0700
        Re: Missing volatile qualifiers in MCU vendor header files? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-04-08 14:58 +0100
          Re: Missing volatile qualifiers in MCU vendor header files? Grant Edwards <invalid@invalid.invalid> - 2020-04-08 14:10 +0000
          Re: Missing volatile qualifiers in MCU vendor header files? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-04-08 20:19 +0300
            Re: Missing volatile qualifiers in MCU vendor header files? Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-04-10 16:27 +0200
          Re: Missing volatile qualifiers in MCU vendor header files? stephen@mpeforth.com (Stephen Pelc) - 2020-04-08 20:49 +0000
            Re: Missing volatile qualifiers in MCU vendor header files? Clifford Heath <no.spam@please.net> - 2020-04-09 09:39 +1000
              Re: Missing volatile qualifiers in MCU vendor header files? Dave Nadler <drn@nadler.com> - 2020-04-08 17:59 -0700
                Re: Missing volatile qualifiers in MCU vendor header files? Clifford Heath <no.spam@please.net> - 2020-04-09 11:40 +1000
              Re: Missing volatile qualifiers in MCU vendor header files? stephen@mpeforth.com (Stephen Pelc) - 2020-04-09 12:31 +0000
                Re: Missing volatile qualifiers in MCU vendor header files? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-04-09 17:36 +0300
                Re: Missing volatile qualifiers in MCU vendor header files? Clifford Heath <no.spam@please.net> - 2020-04-10 10:23 +1000
                Re: Missing volatile qualifiers in MCU vendor header files? stephen@mpeforth.com (Stephen Pelc) - 2020-04-12 13:41 +0000

Page 1 of 2  [1] 2  Next page →

#29387 — Missing volatile qualifiers in MCU vendor header files?

Whilst trying to track down an obscure bug, I noticed that ST
header files do not specify volatile for peripheral registers.
In contrast ARM stuff (looking at CMSIS) is religious about volatile.

For example, in stm32f413xx.h there's lots of stuff like
#define TIM2_BASE (APB1PERIPH_BASE + 0x0000UL) // nice hex address
#define TIM2      ((TIM_TypeDef *) TIM2_BASE)  // TIM2-> used throughout

No volatile on the pointer declaration (nor structures wouldn't work for typedef?)

I checked some headers from Freescale/NXP (OK, a few years old), same thing.

Am I missing something, or is this omission completely nuts?
A lot of register access will be intolerant of 'optimization', right?
David B. ?

Thanks in advance,
Best Regards, Dave

[toc] | [next] | [standalone]

#29389

Dave Nadler schrieb:

> Whilst trying to track down an obscure bug, I noticed that ST
> header files do not specify volatile for peripheral registers.
> In contrast ARM stuff (looking at CMSIS) is religious about volatile.
> 
> For example, in stm32f413xx.h there's lots of stuff like
> #define TIM2_BASE (APB1PERIPH_BASE + 0x0000UL) // nice hex address
> #define TIM2      ((TIM_TypeDef *) TIM2_BASE)  // TIM2-> used throughout
> 
> No volatile on the pointer declaration (nor structures wouldn't work for typedef?)
> 
> I checked some headers from Freescale/NXP (OK, a few years old), same thing.
> 
> Am I missing something, or is this omission completely nuts?
> A lot of register access will be intolerant of 'optimization', right?

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

[toc] | [prev] | [next] | [standalone]

#29393

On Monday, April 6, 2020 at 2:29:39 AM UTC-4, Tilmann Reh wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#29395

On Monday, April 6, 2020 at 9:54:58 AM UTC-4, Dave Nadler wrote:
> On Monday, April 6, 2020 at 2:29:39 AM UTC-4, Tilmann Reh wrote:
> > 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.
> 
> Thanks Tilman! I missed that, from core_cm4 in both these instances...

PS: Really not where I expected! Better if ptr is volatile, not struct or fields.
Explained well by David Brown here:
https://embeddedgurus.com/barr-code/2012/11/how-to-combine-volatile-with-struct/

[toc] | [prev] | [next] | [standalone]

#29396

On 06/04/2020 23:36, Dave Nadler wrote:
> On Monday, April 6, 2020 at 9:54:58 AM UTC-4, Dave Nadler wrote:
>> On Monday, April 6, 2020 at 2:29:39 AM UTC-4, Tilmann Reh wrote:
>>> 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.
>>
>> Thanks Tilman! I missed that, from core_cm4 in both these instances...
> 
> PS: Really not where I expected! Better if ptr is volatile, not struct or fields.
> Explained well by David Brown here:
> https://embeddedgurus.com/barr-code/2012/11/how-to-combine-volatile-with-struct/
> 

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.

[toc] | [prev] | [next] | [standalone]

#29397

On Monday, April 6, 2020 at 6:09:56 PM UTC-4, David Brown wrote:
> Hey!  A cite!  I'm famous :-)

We already knew that ;-)

[toc] | [prev] | [next] | [standalone]

#29398

On 07/04/2020 00:18, Dave Nadler wrote:
> On Monday, April 6, 2020 at 6:09:56 PM UTC-4, David Brown wrote:
>> Hey!  A cite!  I'm famous :-)
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#29399

On 4/7/2020 04:36, David Brown wrote:
> On 07/04/2020 00:18, Dave Nadler wrote:
>> On Monday, April 6, 2020 at 6:09:56 PM UTC-4, David Brown wrote:
>>> Hey!  A cite!  I'm famous :-)
>>
>> 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.

-- 
Best wishes,
--Phil
pomartel At Comcast(ignore_this) dot net

[toc] | [prev] | [next] | [standalone]

#29400

On Tuesday, April 7, 2020 at 12:30:56 PM UTC-4, Phil Martel wrote:
> Remember that fame is volatile.

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

[toc] | [prev] | [next] | [standalone]

#29401

On 7.4.20 11:36, David Brown wrote:
> On 07/04/2020 00:18, Dave Nadler wrote:
>> On Monday, April 6, 2020 at 6:09:56 PM UTC-4, David Brown wrote:
>>> Hey!  A cite!  I'm famous :-)
>>
>> 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 :-)
> 

And the 'DB' in Aston Martins.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#29404

On 4/7/2020 14:38, Tauno Voipio wrote:
> On 7.4.20 11:36, David Brown wrote:
>> On 07/04/2020 00:18, Dave Nadler wrote:
>>> On Monday, April 6, 2020 at 6:09:56 PM UTC-4, David Brown wrote:
>>>> Hey!  A cite!  I'm famous :-)
>>>
>>> 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 :-)
>>
> 
> And the 'DB' in Aston Martins.
> 
and the ubiquitous dB

-- 
Best wishes,
--Phil
pomartel At Comcast(ignore_this) dot net

[toc] | [prev] | [next] | [standalone]

#29405

On 8.4.20 18:20, Phil Martel wrote:
> On 4/7/2020 14:38, Tauno Voipio wrote:
>> On 7.4.20 11:36, David Brown wrote:
>>> On 07/04/2020 00:18, Dave Nadler wrote:
>>>> On Monday, April 6, 2020 at 6:09:56 PM UTC-4, David Brown wrote:
>>>>> Hey!  A cite!  I'm famous :-)
>>>>
>>>> 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 :-)
>>>
>>
>> And the 'DB' in Aston Martins.
>>
> and the ubiquitous dB
> 

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

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#29390

On 6.4.20 01:00, Dave Nadler wrote:
> Whilst trying to track down an obscure bug, I noticed that ST
> header files do not specify volatile for peripheral registers.
> In contrast ARM stuff (looking at CMSIS) is religious about volatile.
> 
> For example, in stm32f413xx.h there's lots of stuff like
> #define TIM2_BASE (APB1PERIPH_BASE + 0x0000UL) // nice hex address
> #define TIM2      ((TIM_TypeDef *) TIM2_BASE)  // TIM2-> used throughout
> 
> No volatile on the pointer declaration (nor structures wouldn't work for typedef?)
> 
> I checked some headers from Freescale/NXP (OK, a few years old), same thing.
> 
> Am I missing something, or is this omission completely nuts?
> A lot of register access will be intolerant of 'optimization', right?
> David B. ?
> 
> Thanks in advance,
> Best Regards, Dave


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.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#29391

On 2020-04-06, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:

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

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.

--
Grant

[toc] | [prev] | [next] | [standalone]

#29392

On Mon, 6 Apr 2020 13:21:07 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>On 2020-04-06, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
>
>> Just stay away from the hardware guys' software, write your own.
>
>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.

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 :-).

>
>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.

[toc] | [prev] | [next] | [standalone]

#29394

On Monday, April 6, 2020 at 3:05:47 AM UTC-4, Tauno Voipio wrote:
> Just stay away from the hardware guys' software, write your own.

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!

[toc] | [prev] | [next] | [standalone]

#29402

On 04/06/20 15:14, Dave Nadler wrote:
> On Monday, April 6, 2020 at 3:05:47 AM UTC-4, Tauno Voipio wrote:
>> Just stay away from the hardware guys' software, write your own.
>
> 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!

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...

[toc] | [prev] | [next] | [standalone]

#29403

On 2020-04-08, Chris <xxx.syseng.yyy@gfsys.co.uk> wrote:

> 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.

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.

> May be better now,

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...

--
Grant

[toc] | [prev] | [next] | [standalone]

#29406

On 8.4.20 16:58, Chris wrote:
> On 04/06/20 15:14, Dave Nadler wrote:
>> On Monday, April 6, 2020 at 3:05:47 AM UTC-4, Tauno Voipio wrote:
>>> Just stay away from the hardware guys' software, write your own.
>>
>> 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!
> 
> 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...


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).

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#29414

On 2020-04-08 Tauno Voipio wrote in comp.arch.embedded:
>
> 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).

Does anyone have experience with Renesas and their Synergy
stuff? Did a workshop a while ago and this all seemed to
work quite good. But ofcourse this was a prepared workshop
example that was bound to work. Did not have a chance to
try it on a project of our own. We nowadays mostly use ST,
so using something else must have huge advantages before we
give it a try. ;-)


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

FORCE YOURSELF TO RELAX!

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web