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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
