Ken Shirriff's articles about BeagleBone

[chicken 630]

I don't have a BeagleBone, but found these two articles from Ken Shirriff very insightful.

 

The BeagleBone's I/O pins: inside the software stack that makes them work

http://www.righto.com/2016/08/the-beaglebones-io-pins-inside-software.html

 

PRU tips: Understanding the BeagleBone's built-in microcontrollers

http://www.righto.com/2016/08/pru-tips-understanding-beaglebones.html

 

Like all his articles, these are long and VERY detailed. Solidly in the "all you ever wanted to know about.."  category.

 

I suspect (hope) there are more BeagleBone articles coming.

[L.R.A 78]

I wonder, the PRU can only be programmed in assembly?
I see here many times a RPI running ROS, connected to an Arduino, in robotic platforms. The Sitara with those MCUs could probably be used to substitute both.

[yyrkoon 250]

I wonder, the PRU can only be programmed in assembly?

I see here many times a RPI running ROS, connected to an Arduino, in robotic platforms. The Sitara with those MCUs could probably be used to substitute both.

No. There is a gcc port for the PRU, and a C compiler from TI called "clpru" I think it's called. There is also a forth compiler I think.

 

EDIT:

 

clpru :

 

http://software-dl.ti.com/codegen/non-esd/downloads/download.htm scroll down towards the bottom. To the PRU Code Generation Tools Downloads heading. You will note there is a Windows, and Linux cross compiler version. As well as a native armhf version. This is a script that will download the files( tools ) on to the executing system. But it is a toolchain. I have personally set this up, and used it to compiler the examples that comes with it. They work, but I have not personally used it other than testing the examples. Many seem to be using it however.

 

gcc port:

 

https://github.com/dinuxbg/gnupru

 

Do read the introduction section of the readme.md. The author makes it sound as though the port is notr exactly reliable. I have not personally tested it, nor will I.

 

Forth compiler:

https://github.com/biocode3D/prufh

 

I know nothing about this except that it exists. The author posted on the google groups about it . . .

[yyrkoon 250]

I don't have a BeagleBone, but found these two articles from Ken Shirriff very insightful.

 

The BeagleBone's I/O pins: inside the software stack that makes them work

http://www.righto.com/2016/08/the-beaglebones-io-pins-inside-software.html

 

PRU tips: Understanding the BeagleBone's built-in microcontrollers

http://www.righto.com/2016/08/pru-tips-understanding-beaglebones.html

 

Like all his articles, these are long and VERY detailed. Solidly in the "all you ever wanted to know about.."  category.

 

I suspect (hope) there are more BeagleBone articles coming.

I'm not sure about the PRU article. But the GPIO article is almost exactly the same as Derek Molloy's article on GPIO. There only difference is I believe Derek's article goes into greater detail with device tree files. I've been seeing this trend with every beaglebone article though. They all talk about poking and proding memory using devmem2.c, and they all talk about

#define OMAP4_GPIO_CLEARDATAOUT 0x0190 and #define OMAP4_GPIO_SETDATAOUT 0x0194. BUt no one ever talks about https://github.com/wphermans/Bonejs/blob/master/examples/devmem-example.js#L16 as I use in my project. Which is similar to how most "real" embedded system toggle a bit.

 

The same information is even in several books with Beaglebone as the main topic. Including Derek's "exploring embedded Linux with the beaglebone"

 

EDIT:

 

It still looks like a good article though. But personally, I'm getting tired of seeing regurgitated information on every beaglebone article out there . . .

[chicken 630]

Re OMAP4_GPIO_CLEARDATAOUT 0x0190 and #define OMAP4_GPIO_SETDATAOUT: This looks like the bit-banding mechanisms in the Cortex-M family. It avoids read/modify/write if you want to just set or clear a single bit.

 

Edit: Actually not bit banding. But separate GPIO registers for SET and CLEAR. Still the same concept: Change a subset of bits without going through the read, logical operation, write cycle.

[yyrkoon 250]

Re OMAP4_GPIO_CLEARDATAOUT 0x0190 and #define OMAP4_GPIO_SETDATAOUT: This looks like the bit-banding mechanisms in the Cortex-M family. It avoids read/modify/write if you want to just set or clear a single bit.

 

Edit: Actually not bit banding. But separate GPIO registers for SET and CLEAR. Still the same concept: Change a subset of bits without going through the read, logical operation, write cycle.

The end result is that CLEARDATAOUT and SETDATAOUT both read / write from DATAOUT. At least that is how the TRM makes it sound. But like i wrote in the comment in my code from that project. Both will work. It's a personal "thing" with me though that I like to keep things consistent, and as much as possible form one platform to another.

 

EDIT:

 

Anyway, I'm not saying the information is bad. But I do think it would be nice to see different discussions about the same hardware. Instead of seeming that everyone is copying one another.

[yyrkoon 250]

By the way, I never checked this with kernels 3.8.x, but with kernels 4.4.x you do not need a device tree file to use GPIO. *UNLESS* you need to have a pin, or pins come up at boot as something other than input. As it is, you need only echo the pin number into the /sys/class/gpio/export file. Change direction if need be. Then finally set the pin hi ( 1 ), or low ( 0 ).

 

The only time you absolutely need a device tree file is if you need to mux the pins for a purpose other than GPIO. For pin that can be configured for multiple peripherals.