Debian updates, etc.

Hi all,

Please excuse my ignorant questions… I’m reeeeealy new at this stuff, but coming up to speed quickly…

I am the proud new owner of a BeagleBone Black Rev C, and followed the advice to update to the latest linux build.

Anyway, I discovered the Debian Jessie 8.2 eMMC flasher at http://elinux.org/Beagleboard:BeagleBoneBlack_Debian (build from 9/13/2015), and followed what instructions I could find on the web. Everything seems to be in working order following installation. Cool!

Following installation, I was a bit surprised to discover that all of the modifications I made to my linux install prior to flashing the eMMC (environments, user accounts, software installs) were gone! On reflection, it wasn’t that surprising but a bit of a warning to back up important data prior to the upgrade would have been helpful. Oh well…

So now, my questions:

  1. In the future, how should I upgrade without losing all of my files? How do the pros do it? I notice there is now a 9/20/2015 eMMC flasher update and would be interested in updating as long as I don’t lose my files. Will a simple apt-get update command do the job, or is there something more subtle I should do? Sorry for the ignorant question, but I’ve been unsuccessful in my internet googling so far…

  2. Completely different topic. I am interested in a realtime Kernel. I will be using the BBB for a 200 Hz closed-loop control application, and need reasonable assurance of a 5 msec time step. I noticed that the 9/13/2015 build I grabbed has PREEMPT enabled. Maybe this is good enough?? (An occational missed frame isn’t the end of the world…) If PREEMPT isn’t good enough, I notice plenty of instructions on the web about compiling the RT-PREEMPT Kernel, which seems like a dangerous prospect to a newcomer such as myself. Will I really need to compile the Kernel to get this functionality, or is there an easier way?

Looking for tips from more experienced users. Thanks in advance for your help!!!

Larry

1) In the future, how should I upgrade without losing all of my files? How do the pros do it? I notice there is now a 9/20/2015 eMMC flasher update and would be interested in updating as long as I don't lose my files. Will a simple apt-get update command do the job, or is there something more subtle I should do? Sorry for the ignorant question, but I've been unsuccessful in my internet googling so far...

I don't have a good answer here, as I'm not well-versed in Linux distros in general. However, I routinely see people apt-getting the kernel to update that.

2) Completely different topic. I am interested in a realtime Kernel. I will be using the BBB for a 200 Hz closed-loop control application, and need reasonable assurance of a 5 msec time step. I noticed that the 9/13/2015 build I grabbed has PREEMPT enabled. Maybe this is good enough?? (An occational missed frame isn't the end of the world...) If PREEMPT isn't good enough, I notice plenty of instructions on the web about compiling the RT-PREEMPT Kernel, which seems like a dangerous prospect to a newcomer such as myself. Will I really need to compile the Kernel to get this functionality, or is there an easier way?

I can try to answer the second question for you. I don't know enough about real-time kernels to suggest that route, but you should consider the BBB's two PRU cores (programmable real-time units). On the AM335x Sitara processor on the BBB are two additional, independent 200 MHz 32-bit CPU RISC cores. You can write C or assembler code and program them "bare-metal." They have access to shared memory with each other and the ARM core, can send and receive interrupts, and access all the peripherals and GPIOs (some GPIOs are "fast").

There's a bit of a learning curve in setting them up, and while I had them working on a 3.8 kernel, I have not been able to get them working on 4.1 (I'm sure I've just overlooked something stupid). But they're extremely versatile and really elevate the BBB's capability.

There are numerous bits of documentation floating about. Here are some:

  http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
  https://github.com/beagleboard/am335x_pru_package
  http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2
  http://elinux.org/BeagleBone_PRU_Notes

Robert C Nelson produces all the distros, and has apt-get repos that provide the am335x-pru-package you can install via apt. Oh wait, the Debian distro already has them configured.

  sudo apt-get install am335x-pru-package

Hope that helps.

Rick, thanks for the great resources, that is a big help! I will definitely be checking them out. In fact, I decided to go with the BBB specifically because of the PRUs. I understand the learning curve is steep, so want to see what I can do on the main CPU first and transition what I can to the PRUs.

Anyone else with tips on my questions? I definitely appreciate what help I can get.

I forgot to mention a big one:

  http://beagleboard.org/project/libpruio/

That may already have direct support for sampling your signal. It's a library you can call from C (don't let the FreeBASIC references throw you) to handle a lot of I/O via the PRUs.

Hi Larry!

I made performance tests with libpruio, toggling a GPIO pin in open and closed loop control from the ARM CPU (measuring the output by an eCAP pin). On a vanilla system (kernel 3.8) the typical speed is between 120 and 600 kHz, depending on the way how to control the IO. (In rare cases the speed goes down to 25 kHz, when the CPU is heavily loaded by other software, ie. an interrupt.)

So it shouldn’t be an issue to realize a 200 Hz closed-loop control application. (Of course, it depends on the number of outputs you want to control and the mathematics/computations.)

As a rule of thumb, I use for controller frequencies

  • up to 10 kHz the ARM CPU and
  • above (or for hard-realtime requirements) PRU-0.

Once I configured the IO part with libpruio on PRU-1, I can use it either way. I just port the controller software later from ARM to PRU-0, when necessary.

BR

Hi BR, that's very useful information, thanks! My interest is ensuring I get a reliable 5 ms time step. A few ms lost here and there wouldn't be the end of the world, but a large delay, even of only occasionally, would really affect performance or worse. I wouldn't think the vanilla Karnel would come with any guarantees, but guessing the PREEMPT flag helps. If that's enough, and I can avoid having to recompile the Kernel to get a RT version (or grab a compiled one from somewhere, who knows where) I would be very happy.