>From what I understand the PRU's( there are two ) operate at 200Mhz, and run independently from the main processor. Most instructions also from what I understand take one cycle, and a cycle being 5uS ( someone correct me here if I am wrong ).
The main processor on the other hand, running Linux we're to expect latency in the millisecond range. Fast enough for many things but not fast enough for high speed / resolution PWM / ADC etc. It is my understanding that running a real time kernel would tighten things up, perhaps a lot. Assuming we may think running Linux is beneficial ( and it really can be ) we can use something like an SBC to handle much of the work that does not require very low latency. While the tasks that do require very low latency we can either use 1-2 PRU's, *OR* use external MCU specific to the task at hand, that stay in communication ( somehow ) with the main board. This main board can then be used as a communication / control hub internal to the project, and to the outside world. Personally, I struggle with the idea of using Linux myself in several embedded situations. As in "why do i need to add this complexity", etc. Surely you could use some development board, or processor tied to a wireless device with an embedded networking stack. But then you price such devices, and you realize that you can very easily double, or triple the costs of the BBB. While the BBB being a Linux computer, if you need wifi, you buy a $12-$15 USD wifi<->USB dongle, making sure the chipset you chose has good support in your distro of choice. *OR* since the BBB also has UART, and SPI, you could also use a wireless device as mentioned above. But again, you're going to double your costs. Passed this, the BBB having the ability to run Linux and thusly being far more general purpose. It can be used in far more situations. Anyway this is just my own thoughts on this topic, and surely there is more to consider than the tiny bit I covered. On Thu, Jul 3, 2014 at 12:37 PM, Jerry Davis <[email protected]> wrote: > I really haven't done any serious real-time since my DEC days. > I was a software specialist for DEC in Dallas, who specialized in > real-time apps for RT-11 and RSX. > At that time I was handling in excess of 3000 interrupts per second in > assembler on a downloadable RSX-11S image. > This was on old hardware by today's standards, I would think. > > For real-time what is expected interrupt rate on an ARM? BBB specifically? > > > > On Wed, Jul 2, 2014 at 9:56 PM, William Hermans <[email protected]> wrote: > >> The term real time is subjective in this context anyhow. There is always >> going to be latency, it is just a matter of how much you can put up with. >> After all we're not talking about some medical device, or Automobile >> control system. UAV ? >> >> But looking at this from an automobile perspective, you have a main >> computer system with many MCU's Performing sometimes critical tasks, and >> communicating back and forth with this main system via CANBus. >> >> The OP really needs to define "Robot" more clearly. I mean we're not >> talking about an AT-AT walker model with stepper motors, while also having >> the ability to walk around are we ? . . . >> >> >> >> On Wed, Jul 2, 2014 at 5:30 PM, Robert Nelson <[email protected]> >> wrote: >> >>> On Wed, Jul 2, 2014 at 7:28 PM, Jerry Davis <[email protected]> wrote: >>> > I have used BBB, RPi, and arduino. >>> > >>> > arduino is closer to real-time if you need that. However, it does only >>> what >>> > is programmed in C in a loop fashion. There is a setup() function and >>> loop() >>> > function. >>> > just about everything is done in the loop. If you need tight >>> integration >>> > (real-time) with some piece of hardware, then arduino is the way to go. >>> >>> Unless you use the "pru" on the bbb.. ;) >>> >>> Regards, >>> >>> -- >>> Robert Nelson >>> http://www.rcn-ee.com/ >>> >>> -- >>> 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. >> > > > > -- > Extra Ham Operator: K7AZJ > Registered Linux User: 275424 > Raspberry Pi and Arduino developer > > There are 10 kinds of people in the world: > Those who can read binary and those who can't. > > -- > 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.
