Surefire PRU - Setup.

GoogleGroups
21

By the way these are my own preffered “pin mux mode” “spread sheet” PDF files for working with various pins: https://github.com/wphermans/bb-info/blob/master/BeagleboneBlackP8HeaderPinMuxModes.pdf

I do not recall who made these, but links in the PDF’s themselves lead back to who created them. Whom also derived the information in these files from Derrek Molloy.

So I do not claim the material at all. I just wanted a location that was easy for me to find, and would never go away. My git seemed to be as good a place as any, for me.

22

oops, https://github.com/wphermans/bb-info is the top most path . . .

23

Ah, OK – it’s confusing though; searching for “beaglebone technical reference manual” took me to this beagleboard.org page that has:

BeagleBone Black System Technical Reference Manual

Hopefully you can see why I was confused… I didn’t realize the presence of the word “system” made that wrong, but apparently that takes one to “the SRM”.

It’s kinda hard to find this TRM when you’re on the outside looking in; I looked elsewhere on the beagleboard.org site under “hardware support”, “software support”, and “Hardware Specs and Materials”, and “FAQ” with no luck searching for “technical reference manual” or “SRM” or “TRM”. I’d think the abbreviations would at least be in the FAQ. Otherwise, how else would one know?

Went back to google, and tried including some extra terms that I know are in the TRM, like “interconnects” and “PWM”. When I did that, I was able to find what I think is the right pdf file(?): http://mythopoeic.org/BBB-PRU/am335x_techref.pdf

I’ll see if I can contact the beagleboard.org folks to see if they can include terms TRM and SRM, and perhaps reword the reference to the “System Technical Reference Manual” to instead be, maybe “System Reference Manual (SRM)”. There’s some email contacts under “About Us”, so I’ll try that.

24

Greg,

You know what. If I were you, I would get a Beaglebone black or green, and make learning about it your favorite hobby. This way, you could experiment with various things, until you’re happy with what you end up using.

It’s certainly been my hobby for the week. It was ok once I got it working, but I got very close a few times to tossing in the towel when the tools weren’t working. Other folks have apparently run into this too and given up, including a friend of mine who turned me on to the BBB before he actually tried it and hit similar walls.

The OP of this thread has been great though – powered me past those road blocks with the flashed OS and latest debian from TI. Started moving much more quickly after that.

If memory is serving me correctly yes, you’re using a blue.

Nope, I have a black only. Didn’t realize there was a blue, actually. Only knew about the green alternative.

Sorry; I’ve been using the term “BBB” assuming that referred exclusively to the black. But I can see where if there’s also a product called “blue”, BBB might refer to that too… gah. Sorry if that confused anyone; all my replies have been only about the black.

So yes, buy a beaglebone, take it home, and start experimenting. Then I would probably not worry about HAVING to have hardware connected up with it. There is a lot you can do by experimenting with software only. How, and where to explore the GPIO subsystem.

Ya, though I was hitting walls with that too (the black, no hardware attached to it other than the board itself); ram demos weren’t running, as they threw up various errors from either the loader tool (open errors) or errors from the echo commands that geneated “write errors” that were trying to trigger device tree files that weren’t loading for some reason. Also I tried the GPIO demos without an LED hooked up just to see it run, but was getting similar errors (prussdrv_open() failed, etc), so I didn’t even bother with hardware until the OP got me past that.

Hoping to be spinning stepper motors tonight via the PRU… looking forward to it!

25

Thanks! Yes, there’s so many of these, some with colors that are kinda hard to read because the colors are a bit too bold.

Great; I’ll likely copy/paste that into a .txt file, as I like to edit code in vi over ssh, and pull lines from tables like this with grep. I prefer to develop locally on devices when possible via the terminal, and avoid IDEs and cross compiling from workstations unless there’s no other choice.

26

I can explain that…

In my case I’m supplying computer software/hardware packages to control old film equipment called optical printers. These are heavy iron monsters with lots of big AC running throughout. They used to be used for special effects, but are now used mainly for film restoration, conversions, and archival. These machines used to be manually run and used mechanical transmissions, and were slowly computerized during the 80’s when stepper motor control became popular.

The situation is my software/hardware combo is a starting point, and local engineers usually wire it all up, as there’s a lot of AC 115 and 220 being controlled by the interface software.

They will be the ones that define whether they need to assign some of the GPIO bits for input or output, assigning them to either monitor motor homing sensors, or outputs to control custom filter wheels, timing lights and film tension motors. Config files on the computer define what are inputs and outputs my software controls. And during shooting, they might need to add a motor. Or a motor might crap out, and so to limp through production they’d need to disable one of the outputs on the fly and use it for some other purpose.

That’s the application, anyway… it has to be field modifiable, it’s not a fixed design, i.e. not a “cape”.

I used to (and still use) DOS machines with ISA GPIO cards (usually 8255 based), and DOS software I wrote back in 1987 (mostly C, some 8086 assembly as the DOS device driver for the stepper motors), some of my company’s custom hardware, and some third party hardware. And the customer often supplies their own hardware that I help them design by supplying recommended wiring diagrams and sometimes have to get in there with a soldering iron if their own folks aren’t available (often hired independent contractors). These are the folks that have to be able to edit files on their own.

I do a lot of other software that pays the bills, but this particular old school project is a bit more hardware oriented, and DOS is showing its age (as are the ISA cards), so I’m hoping to port this whole thing to a beaglebone black, which can replace the DOS machine and 3rd party stepper card which is becoming hard to come by.

27

Sounds like fun. GPIO is super easy on this platform, once you know how the GPIO subsystem works. PWM and ADC is a little more complicated. but not much. PWM can be a bit of a bugger, because some of the examples do not really work( overlays ). With PWM it becomes an exercise of wills, as you the developer find the right example overlay, and have that “aha!” moment. That’s the software side of it anyhow.

So we can not really compare this platform to another. Especially the rPI. As the rPI has limited IO capabilities by comparison. Then no pin muxing that I’m aware of. So overlays are quite different. Once you get the various aspect down, it’ll get really easy for you. In software.

On the hardware side of things, this platform might be a bit picky. But as long as the engineer pays attention to detail, as one should anyhow. There should not be any problems. Luckily for me, I do not have to deal with the hardware. :slight_smile: