On 1/29/2015 3:05 PM, Phil Schmidt wrote: > I just got a BeagleBone Black, and I've been fumbling around the > documentation for almost 3 days, and still don't feel I know how to get > started doing what I want to do.... > > Goal: I want to create some hard-real-time PRU functionality, create a > less-hard-real-time executive running under Linux, and link the two > together, so that I can control/monitor the functionality at the PRU level > via ethernet. > > My background: I have many years of down-to-the-metal embedded systems > development, using no RTOS or an embedded RTOS. I use Windows, and I use > desktop Linux and use the terminal when I need to, but I don't have deep > knowledge of how Linux works.
Given your background, your first decision should probably be Linux or no-Linux. There are various options to make Linux real-time, but they start with the Linux knowledge you don't have, and generally add a layer of complexity above that. If you need non-real-time access to lots of resources (like USB and Ethernet) or software stacks (Python, Ruby, web servers, node-js, and *LOTS* more), you probably want to use Linux. If you have a well bounded problem, don't need portability, and are comfortable talking directly to the hardware, use CCS and run bare-metal (or spend some $$$ and use an embedded RTOS that supports the AM335x). > Where I've landed thus far: I have installed the TI Code Composer Studio on > Windows - and it looks reasonable enough. I have a TI AM335x SDK installed > on a Linux PC, and have a micro-SD with the SDK on it, but have not > installed it on the BBB. I have read tons of documentation, but nothing > that walks a newbie through the development and deployment process. > > Sticking points and questions: > > - I have a gaping hole in my knowledge about embedded Linux, and how to > develop and deploy applications to it. Are there any good online resources > to help me along with this? Books? Other suggestions? There's embedded Linux and real-time Linux. They aren't the same. It sounds like you want real-time Linux, which for the ARM means you're looking at either the Xenomai or the PREEMPT_RT patch sets. The Xenomai patches take control of hardware interrupts and defer Linux IRQ processing to maintain hard-real-time. The PREEMPT_RT patches rely on the SMP support built into the Linux kernel to provide good real-time performance. PREEMPT_RT works well for chips with quality SMP capable drivers (ie: x86), but falls a bit flat in the ARM world with a *LOT* of vendor-provided drivers that are not even SMP safe, much less SMP optimized. > - I am going down the path of installing the TI SDK, but I don't even > know if this is the right thing to do. How do I evaluate my options in the > context of my objectives? Provide some more details about what you're trying to do and we can probably make some specific recommendations. There are prepackaged Xenomai kernels available if you want to go that route. I personally work with Machinekit, which uses the Xenomai kernel running on the ARM for decent real-time performance, and code running in the PRUs to generate step/dir and PWM outputs for controlling 3D printers or similar CNC machines. There is a hard real-time HAL layer provided with Machinekit that might make it easy to code what you're wanting to do, and pre-built images available with the kernel and everything already installed: http://www.machinekit.io/ http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29_Machinekit > - Can I do PRU development and make it run on and with the Debian distro > that is factory installed on the BBB? Absolutely. There are lots of PRU examples floating around. The default BeagleBone image provides device-tree support for the PRU as well as the PRU assembler (pasm), a C compiler, and a PRU Forth. -- Charles Steinkuehler [email protected] -- 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.
