> > *This is one of those C quirks. It's actually a habit from "const" but it > applies to "volatile" as well. Oddly, the qualifiers generally apply to > the *left* except under certain circumstances where they can apply right. > This gets people into trouble when they specify:* > > *volatile uint32_t volatile * blah;* > > *Which is actually a *redundant* specifier as opposed to what they wanted:* > > *volatile uint32_t * volatile blah;* > > *Not every compiler (*especially* embedded ones) will eject a warning on > the duplicate declaration specifier. So, I personally always put them on > the right to avoid the issue.* >
The volatile keyword is often misunderstood. But I do not think the placement of the keyword matters so much as long it is either before or immediately after the type. So like volatile int i or int volatile i would be the same. I think the actual scope matters more. e.g. global versus local scope. But maybe I'm remembering wrongly as I recall reading something to this effect years ago. Anyway, I find this link the best single resource for explaining what volatile *is* - And . . I'm not trying to start an argument or anything, I just like discussing programming in general. http://www.barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword On Mon, Aug 24, 2015 at 3:06 PM, Andrew P. Lentvorski <[email protected]> wrote: > On Monday, August 24, 2015 at 7:27:35 AM UTC-7, Charles Steinkuehler wrote: >> >> >> Optimal would be a sequence of successive stores to the set and clear >> register, with the addresses pre-calculated and sitting in registers >> (or with a base address and use the str instruction with an immediate >> offset). > > > Good point. I can beat the compiler into submission if I want to, but > it's probably not worth the effort as I need to do other logic anyway. > > >> You might also need to >> move the volatile on the variable definitions. I'm not a "C" guru, >> but I think: >> >> uint32_t volatile * gpio_setdataout_addr >> >> ...is different from: >> >> volatile uint32_t * gpio_setdataout_addr >> >> ...you want the uint32_t to be volatile, not the pointer to it. > > > > This is one of those C quirks. It's actually a habit from "const" but it > applies to "volatile" as well. Oddly, the qualifiers generally apply to > the *left* except under certain circumstances where they can apply right. > This gets people into trouble when they specify: > > volatile uint32_t volatile * blah; > > Which is actually a *redundant* specifier as opposed to what they wanted: > > volatile uint32_t * volatile blah; > > Not every compiler (*especially* embedded ones) will eject a warning on > the duplicate declaration specifier. So, I personally always put them on > the right to avoid the issue. > > ...but I write C code like a hardware guy who programs in VHDL. :) >> > > Not a damn thing wrong with that, thank you very much. Software-only > people tend to be amazed that you can write a state machine that is > *readable* in code. A very experienced programmer once told me: "Your code > is the most straightforward code I have ever read." > > Of course, I have to condemn you as a dirty apostate for not using > Verilog. :) (Seriously, though, when is somebody going to produce an > open-source VHDL simulator/compiler so that I can actually use it on > projects?) > > > >> Regardless, note that the maximum toggle rate of a GPIO pin using the >> PRU is about 12.5 MHz, dictated by the ~40 nS required to execute a >> write by the on-chip communication fabric (which means 80 nS period >> for a high/low toggle of the pin). This assumes the CPU and the PRU >> have similar bandwidth to the L4 fabric, which may or may not be the >> case (but I suspect is true). >> > > Do you have a pointer to the reference manual for this (if not, don't > waste a lot of time, I'll dig it out)? Given that this seems to be *very* > fundamental about understanding the architecture, I really probably need to > chase this down exactly. > > Thanks for the advice. I appreciate your taking the time on this. > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
