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
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!
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. :-|
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.
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.
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.
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.
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.
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.
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.
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 bindboost::asio::ip::udp::endpoint listen_endpoint(
multicast_address,
multicast_port
);#else
// for windows, use the interface addressboost::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.
Time delay of analog tape loop with video and audio, delayed by one day. Digital for a cheap version.
With kiosks at major intersections of major cities around the world.
BeagleBone Expansion Header PRU GPIO
This is a list of the PRU-ICSS high speed GPIO pins available on the BeagleBone expansion header.
