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 [email protected]. For more options, visit https://groups.google.com/d/optout.
