Beaglebone tutorial

From Imperial College Robotics Society
Revision as of 23:06, 15 August 2013 by Je310 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This is a work in progress. This is a quick start guide to get the beaglebone black working with opencv, using the c270 webcam from logitech and to drive stepper motors.

Issues that we are tackling

It is known that the openCV library is not fast on this kind of embedded processor due to the fact that it requests a jpeg image then uses its slow floating point unit to convert. We will be using the yuyv capture code provided in this useful discussion!topic/beagleboard/sgCwaP5RVUo

Don't change the password from the blank default unless you want to hassle with strange auto login errors.

Having the camera connected takes the board over its maximum current allowed through the USB connected to the computer. This can be changed in the power management of the BEAGLEBONE (ie not the PC). but for most tasks supplying external power into the jack or battery terminals is easier and better. (power management allows more power from these, this is documented in the user manual).

PRU (Programmable real-time Unit) is critical if you have time sensitive input and outputs, or require high bandwidth( and cannot use one of the built in protocols). In my case I require control of 3 stepper motors and PWM control of a dc motor. I implemented this using the application processor using this kind of method, here. This resulted in lumpy movement, and took significant amount of processor overhead, also the maximum step speed was quite slow.

My PRU implementation results in smooth movement of many motors with zero (or very close) processor overhead. This will be available on git hub when I get round to it ;) .

Important steps to get the pru working

The main issue that needs to be dealt with is the mode of the GPIO pins. The pru can have access to most pins on the headers, though there are some that are very fast and will have one cycle latency, which is pretty cool. To find them look at this table GPIO pin stuff look for "pr1_pru1_pru_r30_6" type statements, pru1 or pru0 refer to the core in question (there are TWO!) and the r30 or r31 refer to either output or input respectively, the _6 refers to the bit withing a special register to change this pin. You need to gather the information in a separate list to avoid getting confused. for each pin you require you will need: The p8/p9 physical header number; the address of the pin; the mode that gives you the correct behavior (input / output); the number of the bit that changes the pin.

The nicest way to then change the pins to the relevant mode is documented here using device tree overlays. In general there is no special mode required for the pru pins just the mode found earlier. the other numbers higher in the mode word control things like pullups, so the mode should normaly be 0x06 or 0x05. Use the method Derek describes to double check your pins are in the right mode, as it is easy to mess something up.

Lastly is to get some code implemented on the pru. I used this example PRU example. You can run this example without changing pin modes as it uses the pre-configured user leds. Adapt the blinker.p file and the .cpp file to your application.

To write to your pin, use "SET r30.t6" where the 6 was derived from the table from before. To clear it us "CLR r30.t6". From here it is all as you would expect (as long as you expect there to be bugs in your assembly).

I will update this page with how to implement the pru in a general c++/c project shortly (and gather all those little red lined that I cannot be bothered to kill at the moment).