Once the magic smoke comes out, things don't work any more.
John Kasunich
jmkasunich@fastmail.fm
GPG Key
Postings:
Index (titles only):
If you are into RSS, you can Subscribe to a syndicated feed.
Links
Friends
I Support
Powered by
Tue, 17 Apr 2007
A simple user space library for accessing PCI bus hardware.
No posts lately. I've been busy learning VHDL and having fun with the Mesa 5i20. I have the core of a hardware step generator working (and have for several weeks actually). Now I'm working on the utilities needed to configure the very flexible stuff that the 5i20 can do.
I've been working on the utility that loads an FPGA configuration into the part. The original Mesa version isn't bad, but it had minor bug or two (and a bad one that would only show up if you have more than one 5i20 installed). I also need to add some new functionality - loading data into a block of RAM on the FPGA, to tell the HAL driver how you want to use the hardware. In my typical fashion, instead of grafting my new functionality into the existing code, I rewrote the whole thing.
One of the benefits of the rewrite is that I pulled out and genericized the code that searches the PCI bus for a card, and enables direct access from user space to the memory and I/O locations on that card. The result is a handy (I think) little library that might be of use to others, so I'm posting it here. It's called 'upci' for 'User space PCI'.
Like libpci (part of pciutils), upci can let you read the configuration data for a device, or find a particular device. But the programming interface for upci is a lot simpler. And it is actually documented! Comments in upci.h cover the entire API. On the other hand, if you just want to see that data from the command line, lspci (also part of pciutils) is a far better tool.
The real difference between libpci and upci is that upci has a very simple API for "opening" and accessing the real memory and I/O on a card, not just the PCI configuration registers. If you are using a card like the Mesa 5i20, you might want a simple user space program to be able to write to some registers that are part of your FPGA configuration. If you are just doing some experimenting with FPGAs, you don't need (or want) a full blown PCI driver, just simple access. Thats what upci gives you.
Disclaimer: as with anything that can access arbitrary hardware, you can crash your system if you go poking in the wrong places. The library tries to be safe - you have to be root (or setuid root) to use the upci "open" command, and it won't let you accidentally write outside the specific region on the specific card that you opened. But by its very nature it can't be foolproof. If you open a region on your disk controller and start writing to registers, don't blame me for the lost data!
Update: May 14
I committed upci to the EMC CVS server a week or two ago. The version originally posted here is out of date, for the most current version follow these links:
(posted: 17 Apr 2007 23:45) (permalink)
Sun, 04 Feb 2007
Open GL "Simulated Machines" for EMC2/HAL
I've wanted to be able to render a "simulated machine" on screen for quite a while. In addition to the coolness factor, it would be very handy for testing non-trivial kinematics code. Very few developers have access to any hardware with non-trivial kins. Such machines tend to be very expensive, and more vulnerable to damage than a conventional machine if something goes wrong. In the past, we've discussied the idea of a simulator a bit on IRC, but the work involved always seemed like too much, and I've always dropped the subject.
Yesterday Alex Joni was doing work on Puma robot kinematics, and the subject came up again. We talked about it for a while, and again, it seemingly got dropped. But a little later, Jeff Epler posted army.py and army.hal. ("army" has nothing to do with the military. Its called "arm - y" because it draws a representation of a robot arm.) The Python program uses the Open GL infrastructure that Chris and Jeff developed for Axis, which really cuts down the amount of coding needed to get an image on the screen. "army" draws a simple three segment robot arm, controlled by HAL pins, and animated as the values of the pins change. Below is a screenshot:
When I saw that it kicked my enthusiasm into high gear. I asked Jeff lots of questions before he went to sleep, then I start hacking on the code. Chris also joined in, writing a box primitive to go along with the cylinder/cone one that Jeff wrote. I tweaked both primitives to make them a little more convenient to use, then started writing a definition for the Puma robot arm. The finished files are puma.py and puma.hal. Copy them to the top level directory of your EMC2 CVS checkout, and run them like so:
. scripts/emc-environment halrun -f puma.hal
The result is a 6 DOF (seven if you count the gripper) Puma style robot, doing its dignified dance under the influence of seven HAL siggen blocks.
|
|
I'd like to split puma.py into two pieces, one of which handles all the dirty work (graphics setup, implementation of primitives and transforms, etc) and another that defines the machine you are simulating. That would allow easy conversion to other types of machines. But I need to talk to the Python experts to do that. (I also need to ask Jeff why the background turned pink!)
(posted: 04 Feb 2007 06:23) (permalink)