The PRU's do not run Linux on them . . . So Linux is a moot point in this context.
Think of the PRU's as something akin to a 200Mhz Cortex M4. With many single cycle instructions. Or even if we expand the acronym . . . Programmable Realtime Unit . . . everything becomes clear maybe ? @kyle Well 8k memory may not be a lot, but I think you'd have to write *a lot* of code to use it all. Unless you get silly and start making obscenely large arrays or something. Remember that bare metal compilers differ largely from compilers for OSes using larger code bases for API's / ABI's. Generated code is or can be very compact. So long as you do not use obscenely large library functions, on top of not using an obnoxious amount of memory for things that are not required. Also if you know the compiler used well enough, technically it should not produce code much, if any larger than pure ASM. In fact it is probably possible to produce code that is larger in ASM than in C - If you do not know ASM well enough. The reverse is definitely possible. Every compiler / language has it's gotcha's / quirks . . . On Fri, Aug 21, 2015 at 3:25 PM, Harvey White <ma...@dragonworks.info> wrote: > On Fri, 21 Aug 2015 14:15:52 -0700 (PDT), you wrote: > > From what I understand from the comments of CNC writers, even Linux > (unless the kernel has been tweaked to allow this) does not allow real > time response. > > Windows certainly not, Linux has to be specially engineered (IIRC) to > give you *accurate* real time response and freedom from extraneous > events. > > What you need is hardware doing this, with software in control. I > might suggest an FPGA or a CPLD, You could also put another > processor in the mix, be it internal or external on a cape, and let it > do the work. It would have to be specifically programmed to do this > particular task within the timing requirements you have. > > Otherwise, the OS does what it wants to do, when it wants to do it, > and your request is in a queue....... somewhere...... > > Harvey > > > > > > > >On Wednesday, August 19, 2015 at 12:06:08 PM UTC-5, Carlos Novaes wrote: > >> > >> > >> I tend to agree with that most of the time. Maybe I am biasing my > question > >> on a limited experience with PRU applications. > >> From my point of view PRU are good for relatively simple tasks, that > >> should be fast and kept independent from ARM and the OS load. C seems > to be > >> a logic choice for the majority of the cases, but if (and here I beg to > my > >> only experience with PRU), there are some critical timing involved, like > >> ensuring some actions are performed periodically. Is it possible and > simple > >> to keep track of the execution time (the number of pru clock cycles) a > >> piece of code written in C takes to execute? > >> > > > >I think there are a couple of standard things people tend to need from > >micros like this: > > > >1.) I need something to happen quickly and regularly below the threshold > of > >_____Hz / KHz / MHz. They may not need the timing of anything within that > >to be perfectly predictable, it just needs to happen fast enough. That > is > >something I prefer to do in C if I can. I simply need the activity to > >take place more regularly than Linux can get it done. 8K is not much > >memory to do a ton of stuff in so the program needs to be relatively > >simple. C can do simple pretty well. ASM makes the simple complex on > >it's own. > > > >2.) I need this to happen exactly 200ns after that happens and then I need > >to repeat that again in 30ns. This is where ASM starts to win. You can > >mess with C to get that to happen but then it starts to look easier to > just > >write the thing in ASM since the timing is straight-forward. Stuffing > ASM > >inline with the C code is possible too if the rest of the program makes > >writing it all in ASM daunting. But there I see ASM as an easy way to > get > >the timing needed as long as you can stand the tedious nature of getting > >anything done in ASM. > > -- > 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. > -- 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.
