nomel.org

Beaglebone: PRU Debug Scripts

Fri, 26 Apr 2013 21:08:00 -0400

Beaglebone: PRU Debug Scripts:

PRU debug bash scripts

Compile pasm with -l to generate a line-by-line list of the generated code.

disable - disabled execution

enable - enables execution

init - resets and starts pru execution

mem - does a memory dump of the first memory addresses

regs - dumps the register contents (pru must be paused)

pc - shows program counter

step - steps the code. “step 5” to step 5 asm lines.

reset - resets the pru

Beaglebone: I2C Reserved Address List

Fri, 19 Apr 2013 21:48:40 -0400

This isn’t documented. Why would it be? But, running Angstrom, as the Beaglebone comes out of the box, the following i2c addresses are reserved:

i2c-1: 0x24, 0x35, 0x50, 0x51

i2c-3: 0x1B, 0x54, 0x55, 0x56, 0x57

There are only two ic’s connected to the i2c busses: power management (i2c-1 0x24) and an eeprom (i2c-1 0x50). The others are reserved by some kernel drivers. Who knows!

Beaglebone Tutorial: UART? Gotta isolate!

Fri, 22 Mar 2013 18:34:44 -0400

LCD_DATA[15:0] are sysboot pins. This means that the levels on these pins, during boot, are used to configure the system.

Looking at the Beaglebone reference manual, you’ll notice that UART 2 to 5, have inputs on these pins. This means you MUST use something to isolate the pins until after the system has booted.

You’ll also notice that UART1 shares pins with I2C2, the cape eeprom pins. So, if you have a proper cape that uses I2C2, you can’t use UART1.

So…the only way to use uart on the Beaglebone is to use external circuitry to isolate the pins during boot.

Awesome.

Best part is, by moving the UART output signals to the sysboot, they could have completely prevented this requirement. :-|

New Beaglebone Preview

Tue, 12 Mar 2013 19:17:00 -0400

http://beagleboard.org/unzipped/

Uses the AM3358 chip (comparison with AM3359 in current Beaglebone).

Beaglebone SxSW 2013 Slideshow, with a few details on the new board.

Beaglebone Tutorial: PRU Custom Communication Interface, Part 1

Fri, 01 Mar 2013 19:19:00 -0500

Part 1: Triggering the ARM interrupts using PRU events.

Part 2: Interfacing with the PRU memory.

Part 3: Interfacing with the PRU interrupts using the pruss_uio userspace i/o.

Ugh: oncrpc-windows library with C++ and "undefined reference to" errors

Thu, 28 Feb 2013 06:46:00 -0500

oncrpc-windows on Sourceforge.

The rpc/rpc.h header that comes with this library doesn’t have the

extern “C” {}

switches around it, so you’ll get errors like

undefined reference to `clnt_perrno(clnt_stat)’

If you’re using the library in a c++ project, you’ll need to put the “extern” switch in the rpc.h header, or wrap it around the

#include “rpc/rpc.h”

wherever it’s declared.

Ugh: ONC+/TI-RPC using Cygwin dll - Unknown Protocol error

Fri, 01 Feb 2013 16:59:00 -0500

So, you compiled your RPC client and it runs great in the Cygwin console. You use cygcheck to get the required dll’s and move it else where, so you can run it outside the Cygwin console.

If you’re using TI-RPC, you missed a file: /etc/netconfig

The TI-RPC library uses the NETPATH environment variable or this hard coded value to look up the protocols this machine supports.

This file is, literally, only used by TI-RPC on most systems. What purpose does it serve? If you’re just using TCP or UDP, absolutely none. It simply redefines standard socket constants, stuff that every other socket based server/client in existence does just fine, but you still need it. TI-RPC is based off of SUN RPC, which was made in the long-long ago, back when things besides tcp and udp, ipv4 and ipv6, weren’t universally used. Some examples of supported protocol families include: appletalk, nit, decnet, ccitt, datakit, chaos, pup. I don’t even.

Solution:

Scrap it all like I did and use oncrpc-windows.

Idea: Line-unfollower painter

Mon, 21 Jan 2013 23:51:00 -0500

Maybe with an optical mouse for an eye, generate a “decision” from the image of the paper fibers and paint under the “head” of the line follower that would select the next direction and color to put down (or change in direction and color). Maybe stack a few standard image processing algorithms to come up with the “decision”. Might end up with some interesting, organic looking, artwork.

Maybe even have the rules of the “decision” change based on the image underneath. Seeing enough blue could trigger some color and some sharp direction change.

Probably wouldn’t be too interesting on a small canvas, but something like a mural might be.

Maybe have the color influenced by absolute position so things like logos or big faces could be subtly hidden in.

Lame Idea: Sound pens

Mon, 21 Jan 2013 23:43:00 -0500

Sound pens for kids. You run your thumb nail along the length of the mechanical pencil/pen and it plays back some resemblance of a word or recording by vibrating your thumbnail with some groves cut/molded onto the surface.

I loved “something generated from something else” type things when I was a kid.

To market it, could automate a cutter to do custom sounds.

Better yet, have this as a “customization” option for electronic devices. Is that your phone? Rub a stick on it and hear your sound byte.

Interesting thing: Light collection from shadow living plant

Mon, 21 Jan 2013 23:36:37 -0500

I found some shadow living plants under a redwood tree. They had rubbery leaves that nearly felt sticky. From what I could tell from the way the light sparkled off of the leaves, they felt this way because the surface of every leaf was covered with thousands of micro-facet surfaces. This plant only lived exactly in the redwoods shadow. I can’t imagine soil conditions would be that much different across such a fine line (1/4 inch between bushy plant and nothing), so I’m assuming it “actively” refused to grow if too much light.

I’m assuming this guy took an opposite approach to light loving plants. Rather than competing for bright light and dealing with its variability and problems moving between the two types of chloroplast, these guys probably maximize their low-light chloroplast year round while they chill, alone, in the shade, possibly unable to make any real amount of high-light chloroplast. I’m guessing the texture on the surface of the leafs has to do with maximizing the ambient light collected from the sky.

It would be *very* interesting to see if any of the tricks used by the plant could be used on the surface of low-light photovoltaic cells.

I’m guessing the texture, chloroplast placement, and things like the gradient of the index of refraction near the surface would all be interesting.

Photo

Sat, 01 Dec 2012 01:20:28 -0500

Ugh: How to specify network interface for boost::asio::ip::udp multicast receive

Fri, 30 Nov 2012 22:57:00 -0500

With some funky formatting so it’ll fit better….

I have the socket_ as a private variable in a class, that’s why scoped_ptr is used.

I use the Sigar API for a cross platform way to get a list of interface addresses. You’ll see people trying to use boost, but that does not give a list of interface addresses. It uses hostname resolution, which only works if you have a DNS or something to look up the hostname.

boost::scoped_ptr<boost::asio::ip::udp::socket> socket_;

#ifdef _linux
// for linux, use the multicast address as the bind

boost::asio::ip::udp::endpoint listen_endpoint(
multicast_address,
multicast_port
);

#else
// for windows, use the interface address

boost::asio::ip::udp::endpoint listen_endpoint(
interface_address,
multicast_port
);

#endif

socket_.reset(
new boost::asio::ip::udp::socket(
io_service,
listen_endpoint.protocol()
)
);

socket_->bind(listen_endpoint);

if( interface_address.is_v4() ){
socket_->set_option(
boost::asio::ip::multicast::join_group(
multicast_address.to_v4(),
interface_address.to_v4()
)
);

}else{

// need to find cross platform way to get interface number

socket_->set_option(
boost::asio::ip::multicast::join_group(
multicast_address.to_v6(),
<ipv6 interface index int here>
)
);
}

Binding to “0.0.0.0” only seems to listen on one interface.

Art Installation: Yesterday Machine

Thu, 06 Sep 2012 03:35:28 -0400

Time delay of analog tape loop with video and audio, delayed by one day. Digital for a cheap version.

Art Installation: Street corner video chat

Thu, 06 Sep 2012 03:34:32 -0400

With kiosks at major intersections of major cities around the world.

BeagleBone Tutorial: BeagleBone Expansion Header PRU-ICSS GPIO Pin List

Mon, 27 Aug 2012 22:56:00 -0400

BeagleBone Expansion Header PRU GPIO

This is a list of the PRU-ICSS high speed GPIO pins available on the BeagleBone expansion header.

BeagleBone Tutorial: How to compile kernel modules and "hello world" on the BeagleBone

Mon, 27 Aug 2012 21:44:00 -0400

This tutorial shows the commands to compile and install the “hello world” of kernel module compilation using the stock Angstrom distribution that comes on the BeagleBone.

This only requires a few opkg commands. I didn’t see this anywhere on the newsgroups or forums…no idea why.

References

Linux Device Drivers, Third Edition (Chapter 2)

Introduction to Linux Kernel Programming, Lesson 4, Configuring and building your first kernel

Get to the latest version of everything

~# opkg update
~# opkg upgrade

Update refreshes the package list. Upgrade upgrades all packages to the latest versions, including the kernel.

Get the kernel source files and make stuff

~# opkg install kernel-headers
~# opkg install kernel-dev

If you screw something up later on, you can do a

~# opkg install kernel-headers —force-reinstall
~# opkg install kernel-dev —force-reinstall

The kernel source is now in /usr/src/kernel. I don’t know if it’s all there…but it’ll compile modules.

~# cd /usr/src/kernel
/usr/src/kernel# make scripts

“make scripts” compiles a few things used for the kernel module building.

Compile hello.c kernel module

/usr/src/kernel# cd test
/usr/src/kernel/test# make CROSS_COMPILE=”“

The ‘CROSS_COMPILE=”“’ is needed since it’s a native build.

You’ll get an error like this:

make: *** /lib/modules/3.2.28/build: No such file or directory. Stop.

Make this path a symbolic link to the kernel source directory with

ln -s /usr/src/kernel /lib/modules/3.2.28/build

Now, make the test again

/usr/src/kernel/test# make CROSS_COMPILE=”“

and install your first compiled kernel module

insmod kernel.ko

WOOOHOO!

Oh…wait…where’s the message that’s it’s supposed to print? Check the kernel messages…

/usr/src/kernel/test# dmesg
…
[ 6376.390960] Hello, world

WOOOOOOOOOHOOOOOOOOO!

Happy kernel module writing (if there is such a thing)! :D

I have written a full kernel module, interrupts and all, using only this source.

BeagleBone Tutorial: Accessing Main Memory From the PRU (and visa versa)

Wed, 22 Aug 2012 22:03:00 -0400

This tutorial shows how to access any part of the main memory from within the PRU, and reasons you shouldn’t.

References

PRU Reference:
AM335X PRU Reference Guide from the AM335X PRU Package (usage tutorial)

Technical Reference Manual:
AM335xARM Cortex-A8Microprocessors (MPUs) Technical Reference Manual

PRU Local Memory

Each PRU-ICSS has local memory that, from the perspective of the PRU, spans from address 0x00000000 to 0x0007FFFF, with the memory mapping found in table 5 of the PRU Reference.

Reads and writes to this memory, including the 12kB of memory shared between the two PRUs, are only 1 clock tick (clock runs at 200MHz).

Memory Outside the PRU

All memory available to the CPU (including the PRU memory) can be accessed by the PRU through an interconnect, the L3. For details on the L3, see the Interconnects chapter in the Technical Reference Manual.

For quick summary, the L3 performs data reads and writes to other blocks of the chip using a network-on-a-chip protocol (handles the “send this to” and “get this from” type addressing and handshaking) that’s physically connected with an Open Core Protocol (OCP) socket (a standard way to physically connect subsystems of a chip).

Another way to read that is “There’s lots of overhead”. Where local reads and writes were instant, within one clock tick, reads and writes though the L3 take many cycles. How many? Well, that depends on if the L3 is busy passing data around for some other part of the chip.

Accessing Memory External To The PRU

For the PRU, all addresses from 0x00000000 to 0x0007FFFF are local data. By enabling the OCP socket, the PRU gets to the L3. Connected to the L3, any memory read or write to addresses from 0x00080000 and beyond are routed through the L3 to the main memory, with the main memory address equal to what was requested. For example, reading address 0x0008005 will return the value from main memory address 0x00080005.

To access main memory addresses below 0x00080000, a global memory shit of -0x00080000 can be enabled. With the shift enabled, reading address 0x00080005 with the PRU will return the value from main memory address 0x00000005.

Setting Up The PRU To Access Main Memory

Enable the OCP socket to connect the PRU to the L3

To enable the OCP port so the PRU can access main memory, set the STANDBY_INIT bit to 0 in the PRUs SYSCFG register, disabling the standby mode, and enabling the port.
Set the address offset field

To read main from 0x00080000 and up, set the address offset bit PMAS_PRU<n> in the PMAS PRU register to 0 to disable the offset. The main memory address is the same as what was specified in the PRU code. Reading PRU address 0x00090200 return the contents from main memory address 0x00090200.

To read main memory addresses 0x00000000 to 0x0007FFFF, set the PMAS_PRU<n> bit to 1, enabling the offset. The main memory address is now 0x00080000 less than that requested by the PRU, so reading PRU memory address 0x00080150 return the value in main memory address 0x00080150 - 0x00080000 = 0x00000150.

GPIO pins can be accessed through the global memory, but they shouldn’t (tutorial on its way).

Accessing PRU Memory From The CPU

There’s nothing special here. The CPU accessing the PRU memory through an L4 interconnect, which is always enabled, so there’s nothing special to do beforehand: the memory is always accessible.

Find the base address for the PRU that you want to access, and look up the offset for the PRU memory you’re interest in using Table 6 in the PRU Reference. Notice that the memory offsets match the PRU local memory, with a few of the “reserved” fields populated.

What NOT To Do

I think these are fairly obvious, but should be stated anyways.

If you need to poll memory, poll local memory

Any pru <—> main memory communication (with the exception of the PRU GPIO) has to go through a memory bus. Be aware that doing something like using the PRU to quickly poll some main memory, rather than a local memory, will flood the memory bus and most likely slow down whatever else interesting you’re doing with the CPU. If you need to poll memory to wait for some rare value, always poll local memory.

If your CPU is the one polling, poll main memory, and have the PRU set that main memory address.

If your PRU is needs to poll, have the CPU set the PRU memory (it has full access to all PRU memory, including registers).

Poll GPIO or use an interrupt! PRU interrupts basically poll some of the PRU GPIO lines. They don’t come through the L3 or L4 interconnect, so will be much quicker. They can also be used to wake up the PRU from a suspended state, if you want to save some power.

From The PRU, Leave Any High Speed GPIO To The PRU GPIO

Don’t toggle the main GPIO pins from the PRU using their host memory addresses. And even worse, don’t toggle the PRU GPIO pins using the host memory address. Use the PRU GPIO pins. They’re one-tick access for reads and writes. That’s what they’re there for! Again, accessing through the main memory will be slow, have unpredictable access/toggle times, and flood the memory bus.

Here’s a list of PRU GPIO pins accessible on the BeagleBone header. See below for a PRU GPIO tutorial.

Related

BeagleBone Tutorial: Configuring GPIO Pins
BeagleBone Tutorial: Toggling GPIO Pins From Within The PRU-ICSS (on its way)

Errors? Something unclear? Leave a comment!

BeagleBone Tutorial: Configuring GPIO Pins

Wed, 22 Aug 2012 22:03:00 -0400

This tutorial explains how to locate and configure the GPIO pins for input, output, pull-up, pull-down, high-z, etc.

I couldn’t find this information clearly stated in any one place, so here’s my attempt. If the TI wiki was actually a wiki that allowed people to edit it, I’m sure something like this would already be there.

References

Technical Reference Manual:
AM335xARM Cortex-A8Microprocessors (MPUs) Technical Reference Manual

Product Preview:
AM335xARM Cortex-A8 Microprocessors(MPUs) Product Preview

Alexanders Fast GPIO Access Tutorial:
BeagleBone IO using Python and mmap

GPIO Pins

There are only a limited number of physical pins to choose from, but many internal signals to put to those physical pins. Due to this limited pin count, most GPIO pins can be multiplexed to many different internal signals. In addition to internal signal selection, some pins can be configured to have pullups or pulldowns, fast or slow rise times, and as input or output pins. All of these settings are contained in a pin configuration register with one register for each pin.

Pad Control / Configuration Register

The configuration register is 32 bits wide and is the same format for all pins and does three things:

Sets up the internal multiplexer to select an internal signal to that gets connected to the pin.
Sets the pin to an input, otherwise it’s an output only pin.
Connects or disconnects an internal pullup or pulldown.

The format of the configuration register is the same for all pins, and can be found in section 9.2.2, “Pad Control Registers” in the Technical Reference Manual, but here’s my version of the table:

Bringing An Internal Signal Out To A Pin

Since each pin can be connected to multiple internal signals, a multiplexer is used to select which internal signal gets brought out. Table 2-7 in the Product Preview lists all signals that can be brought out for each pin, and the MUXMODE value that needs to be placed in the pins configuration register to bring that signal out. For the beaglebone, the pins leading to the headers and the MUXMODE values to bring out all the different signals are listed in Table 9 in the BeagleBone System Reference Manual … OH JUST KIDDING, they only partially filled out the table. Most are there, but a bunch are missing, including all of the PRU-ICSS GPIO signals (which can be found here).

To route an internal signal to a GPIO pin

Find the pin name that the internal signal routes to.

Look up the physical “pin name” that the internal signal can be muxed to in table 2-7 “Ball Characteristics” section of the Product Preview. You’ll find the internal signals listed in the “Signal Name” column, and the pin that this signal can be connected to in the “Pin Name” column. Next to the signal name will be a mode number. This is the MUXMODE value that needs to go into the pins configuration register. Write down the Pin Name and the mode number.
Find the settings that the pin and signal support

In table 2-7, you’ll also see a “Type” and “Pullup/Down Type” column.

The Type column shows if the signal is an input, output, or both. This determines what values can be used for the RXACTIVE field of the configuration register. If I or I/O is listed, RXACTIVE can be enabled and the value will end up in some register location than can be read (see the signals details for where). Otherwise, it shouldn’t be, since the received value wont be accessible.

The pull up and down types show if there is a pull up (PU) or pull down (PD) attached to the pin. If either aren’t listed, then there’s nothing to connect, so enabling wont do anything.

I could only find one mention of slew, used for the DDR pins. I’m assuming the setting is ignored for all other pins.
Find the configuration register to configure the pin.

The configuration registers are contained in the Control Module memory space. Each register is listed as an offset from the Control Modules starting memory address, so the final configuration register memory location will be the Control Module address + the configuration register offset.

Look up the “Control Module” memory address in the processors Memory Map in the Technical Reference Manual. For the BeagleBone with a Cortex-A8, this is 0x44E30000.

Look up the find the configuration register offset for the pin name in table 9-10, “Control_Modules Registers”, in the Technical Reference Manual. The names listed aren’t exactly the pin names, but it should be obvious. For instance, the entry for pin GPMC_A11 is conf_gpmc_a11.

Example: Lets say the signal we’re trying to get out is gpio1_27. The pin name is GPMC_A11. The Control Module start address is 0x44E30000. The configuration register for this pin is listed as conf_gpmc_a11, with an offset value listed as 0x086C. The memory location for the configuration register is 0x44E30000 + 0x086C = 0x44E3086C.
Set the configuration register

Decide what pullup, slew, and input settings desired pull up/down settings and select the mode to the value found in step 1. Write the configuration register…but how?

There’s a command called devmem2 that will let you read and write to any non-protected memory locations. “Unfortunately”, the GPIO configuration bits are in kernel space, so require privileged (kernel) mode (thanks Alexander). This means you’ll have to make a kernel module, or use file system routines to set the registers. As Alexanders tutorial points out, it’ll look something like

echo <value> > /sys/kernel/debug/omap_mux/<pin name>

where <value> is the value to put into the configuration register for the <pin name>.
Bam!

If the pin had output capabilities, it should track your internal signal value. If the pin had input capabilities, and you enabled it, you should be able to read the pins state through the signals read memory address.

High speed toggle rate

If you need something high speed and deterministic (known timing), you can use the PRU GPIO pins. With these, 200MHz is achievable, with the availability of a free 200MHz 28-bit shift register and PWM built in!

Other BeagleBone Tutorials

BeagleBone Tutorial: Accessing Main Memory From The PRU
BeagleBone Tutorial: How to compile kernel module “hello world” on the BeagleBone

Errors? Something unclear? Leave a comment!

Idea: Remote temperature sensing for combustion chambers

Thu, 16 Aug 2012 18:51:00 -0400

Using a few infrared detectors with various wavelengths placed near the intake valve, you could pretty accurately estimate the maximum temperature inside the combustion chamber when the valve opened.

The internals of the combustion chamber would reflect infrared pretty perfectly, allowing it to bounce out of the intake valve while it was opened. The multiple infrared detectors would have overlapping response curves to allow a multi-spectral infrared color estimation. Using the maximum detected color, you could estimate the temperature by comparing it to a blackbody radiator.

The valve-closed levels could be used to cancel any ambient levels, and the signal could be filtered against the changes in intensity from the changes in valve aperture size as the valve opened and closed.

Being near the intake, the sensor might stay clean clean. A window could be placed in the side of the intake pipe to keep the sensor out of harms way, with a light collector of some kind focused on the intake valve.

Maximum temperature is nice to know since it is what would cause any pre-ignition.

Idea: Motion Sickness Surface

Tue, 19 Jun 2012 16:13:00 -0400

To help prevent car sickness while reading, use the “make sure the horizon is in view” approach by back-illuminating the page you’re reading with a pattern that remains, from an inertial perspective, stable.

A notepad holder/device cover (like iPad) with a low res led pattern, a gyro, and an accelerometer. The led matrix would display a pattern that would remain relatively constant in space, held by the gyro and accelerometers.

So, as you bounced your way down the rail line, the page would appear to move around on the pattern, matching the acceleration signals from your semicircular canals.

With a decent graphics card, this could be built into laptops/tablets to move images, text, or the whole screen image, around on the display space.

Fixed patterns would also make an interesting Halloween costume.