Sponsored By
Efika 5200B Project
Embedded Systems Portabilityin category Embedded
proposed by charlestonchoo on 1st March 2008 (accepted on 1st May 2008)
Developers: Charles Jarvis, Kevin Nickels, Matt Sealey
Project Summary
I. IntroductionIn a design-intensive environment such as Trinity University’s Engineering Science program, students are exposed to a variety of embedded control solutions. Invariably, the solutions that they are exposed to show up in later design projects at Trinity and are also likely to show up in former students’ professional work. Dr. Nickels is continually looking for ways to expose students to easy to use embedded controllers.
In the late 1990s, there were many projects based on the M.I.T. handy-board. After Dr. Nickels introduced the OOPIC micro-controller in several classes, projects started utilizing these. Similarly, the use of the Altera UP1 and UP2 boards in Junior Design and Digital Logic Design likely resulted in their use in projects. Students’ familiarity with LabVIEW from Control Systems, Fluid Dynamics, and Heat Transfer classes coupled with its ease of use, leads many students to use a PC with LabVIEW in projects where an embedded controller or even PLC would be more appropriate.
From Trinity’s point of view, these projects represent an opportunity to increase this exposure and to show students one of the trends in modern embedded computing – that of modular programming and functional portability. From Genesi’s point of view, these projects illustrate the power of the AURA firmware to allow the developer to develop on a fully instrumented system.
An EFIKA/LabVIEW configuration, in particular, may be very appealing to those Trinity Engineering students that are uncomfortable programming. The ability to develop embedded controllers outside an assembly or C programming environment would be extremely beneficial to Trinity’s program. At the same time, students proficient in C could see the more lightweight alternatives.
II. Goals
The AURA firmware interface should allow development of an embedded system with a well-defined interface to be developed on an EFIKA, and then ported to another AURA-enabled development board with little to no changes. Genesi would like to develop some example systems to demonstrate this functionality.
An Altera-based PCI card (with embedded PCI core) would make an excellent project to demonstrate IP-Cores and interfacing for Digital Logic Design. Utilizing the FPGA (Altera Chip) for glue-logic and interfacing, an AURA-aware application running in Linux would serve as an excellent modern application for embedded microcomputer systems.
An EFIKA and LabVIEW combination, such as that offered by National Instruments, could be used in Mechatronics. This would also serve as a wonderful way to introduce this embedded configuration to the students, some of whom would likely utilize the EFIKA/PowerPC for their Senior Design projects.
III. Projects
Project Blog Entries
I have successfully integrated the PWM controller code and am fixing up counters now. Had a little scare with the usage of LCs on the MAXII but removing the LCD controller gives plenty of room. I may re-implement the LCD controller without the huge init sequence such that it is entirely software controlled, just so there's an ability to display on the board, that is still if it can be done in a small enough way along with the rest.
.. with a little rework of how different modules talk to each other and moving LCD initialization into the PCI reset logic, thus simplifying the design (so it blinks the cursor at boot now) but reducing functionality (if I screw the display up with some errant commands, I have to reboot to get the thing back).
Writing a test message worked perfectly. I only wish I could get the image off my phone to upload it here!
I will have to take some photos next week anyway so I can show the status of the case modifications, the board in action, etc.
I need a little extra software to control the LCD (i.e. submit command data) which will allow me to update fonts (i.e. draw images) and clear the display and all that fancy nonsense.
In the end I decided not to go into making the PCI design delay for slow peripherals; none of the projects (the V8 Model Motor and the Mechanical Arm) require it and it just makes the target control more confusing than it needs to be.
I already started plugging Charles' design into a stripped down version of the New Trinity Reference Design (i.e. just LEDs, Switches and Interrupts) and added counters for the rotary/line encoders. We will need some kind of buffer between the encoders and the MAXII since it's a 3.3V board and would fry with a 5V input from these little modules. I have to look at the spec sheet and see whether the one we found actually does what we think..
We now have a working interrupt controller driver which can take interrupt events from multiple sources, assert an interrupt signal (INTAn, through the PCI MegaCore) and give their status in an interrupt status register (ISR), on reading of which the interrupt signal is deasserted.
The simplest test was to flick a switch, and now we have the software driver reporting (on unload, which is odd..) when a switch was pressed or depressed (or just a little bit sad :) with an interrupt. Pressing switches 12 times gives 24 interrupts, as expected. The interrupt signal turns off when the ISR is read. I'd say pretty successful :)
The next step will be to debug the LCD controller which is acting rather strangely. It's not absolutely essential to the project but it would be nice if we could control it (and it is a good example of a peripheral which requires the PCI core to wait for it..) and display the status on the panel of the controller. The kernel driver (through /proc) would still have to set the panel data but it could also set informational messages (we have 16 characters on 2 lines).
After some blood, sweat and tears were put into it (Christmas break notwithstanding) and a lot of cutting down example code meant for cards with PCI Master cores available (like the Cyclone II), I finally got a working PCI target control state machine running.
Now, we have a MAXII PCI board in an Efika (with a 90-degree riser and a modified Open Client case so that the board is exposed) which implements a very simple, student-understandable PCI concept - i.e. it's simple, concise and is written in VHDL rather than Verilog. Right now, all you can do is read and write some LED status, and check the status of 4 pushbutton switches, but these are exposed through a Linux kernel driver and a /proc filesystem interface such that they can be read by userspace.
The next step is to enable a more advanced peripheral such as the onboard VFD LCD controller, which will allow some text output from designs (or be controlled from the driver/proc interface). This requires a more complex state machine which can handle PCI retries and insert wait states, since the bus on the VFD controller is far, far slower than the PCI clock. There is also some cleanup and documentation in the VHDL core to be done, to make sure the entire thing is as transparent as possible.
I think we will put the code up on the web for everyone to see in the very near future.
So, a few more days down the line. I've found that the easy way out - Altera's SOPC Builder - is a complete waste of energy. While it simplifies a lot of the PCI goo between the target controller and the logic, it actually looks like it will make everything far more difficult in terms of bringing up any VHDL that connects to it all. The most basic example generated a massive, sprawling, unmaintainable top level. The quickest test of a working "system" would have been the MAXII PCI card devices (LEDs, temperature sensor, LCD controller, switches) however the temperature sensor (which is on i2c) is not in the IP core library, and bringing in too much external technology while simplifying what I have to write, just seems like it would get in the way of teaching students what it does. There has to be just the right amount of black box magic.
Therefore the definite direction is to build on top of the PCI Compiler MegaWizard flow, generate a target core, and interface it manually. As a "quick" test I'm working on a very simple PCI target which contains a few simple, hardcoded registers (perhaps with some clever hexadecimal words in it) - read only and writable to make sure I have the logic down. It took a long while to scour through the Altera documentation and my trusty PCI book (PCI System Architecture 4th Edition) to match up any concepts and work out what the PCI core does in addition.
I think I have that down now.
Further projects are getting line sensors on the arm so we can turn it into a closed loop design, making a set of labels for the arm joints to let the line sensors count and measure movement. This is more difficult than it looked, at least with the yellow arm (see previous posts and pictures), as there are very few places to put them.
In other news we noticed this today - a robot arm controller powered by an MPC5200B.
It can't be said that the MPC5200B isn't a great little chip for robotics applications. I am curious as to why it costs $24,000 USD though. That's certainly not for the MPC5200B board, but perhaps it's a really really good robot arm (picking up a Tux plushie seems, then, to be understating it's usefulness, but it would make for a great first test here :)
Well, now I'm at Trinity and have been for the past couple of months, I've been trying to get my head around building PCI cores for the Altera MAXII and interfacing Charles' original design for the robot arm controller onto a PCI bus.
Work on the Altera PCI "Reference Design" went okay, despite having to re-learn PCI management on Linux since large parts of the API changed, I managed to build a small Linux kernel module which tweaks the on-board LEDs and reads a sensor - something that Altera only saw fit to provide a Windows binary driver to do on the development CD.
However the large part of the reference design and all the examples are coded in Verilog which adds that extra step in learning what to do, and that little bit harder since we want to do everything in VHDL (as this is generally what the students here learn and the language I have had the "most" experience with anyway).
Things are progressing slower than I would like, but I'm getting there. This week I will take a break from poking at the PCI Megacore and attempting to glue things together, and take a stab at the Motor, which is a simpler version of the arm controller (only one motor required, not 5, and it needs to be closed loop so there is far less requirement on the "software side" to do anything) on the standalone MAXII or CycloneII board. Once this is tested and working it may be much easier to glue this simpler logic into the PCI target, as the entire functionality of the motor can be exposed in a single 8-bit register and we can control the entire functionality of the motor with very little glue logic. By comparison getting the arm to do anything useful for testing with 5 motors, and getting any logic wrong, just seems like jumping too far ahead.
KMN Note - I just moved the images to my webspace, the work is all Charles'.
[quote="CJarvis"]This will probably be my last update to this project. The summer program at Trinity has ended, and as I have graduated, I've found a job in Houston and start later in the fall. So for this blog, I'll give an overview of what we've accomplished this summer in the lab at Trinity.
The robot arm controller is in a stable, finished-for-now state. It can control 5 motor independently, all 5 at once or one at a time.
Shown above is the block diagram in Quartus that runs the motors. It's main components are an address decoder/memory controller, a PWM generator, a logic module, and an 8-bit register for memory. If you want to read the manual/report on the arm controller, it can be found here.
Above is the interface board hooked up to the arm and the DE2-70. We used wire wrapping for prototyping, so that it would be easier to rearrange things if necessary (and it was).
One thing we didn't get finished however, was a P controller of position for the arm. We have the sensors (one of them is shown below), but we weren't able to get around to mounting them, so we couldn't test the code we developed for the P controller. However, later in the fall/spring, Dr. Nickels will probably be hiring a current student to do some more work on the project(s).
The other project that was (mostly) finished this summer was the update of our Instron 4201 machine, which has been mentioned in earlier posts. The operating manual for the Instron and its VI can be found here. However, we did not get to where we wanted to on this project due to never being able to obtain the Efika/QNX/LabView machine from National Instruments.
You may have also noticed that there hasn't been much in this blog actually dealing with the Efika. That's because my strong point was working with digital logic, and not the Linux/hardware side of things. We are also bringing in someone during the fall to help us with finishing up the labs as well as help us get the interface between the Efika and the CPLD/FPGA PCI cards working.
original posted by Charles Jarvis on 25th August 2008.
Since the last update, we've made a good deal of progress. Last time, we had the motor driver hooked up to a couple of switches and a few logic gates as a simple prototype. Now, the system is controlled completely digitally, save for the motor driver which can't be implemented in VHDL (we don't want to release the magic gray smoke inside the Cyclone II chip). The first picture below shows our current setup.
As can be seen in this picture, we have the breadboard with the SN754410 on it, now connected to one of the expansion ports on the DE2-70. The ports on the expansion slot are controlled by the program shown below. Right now, the program only controls one motor but that can be easily expanded by simply copying, pasting, and changing a few numbers and letters. In the background of the photo, next to the breadboard, is an upside-down prototyping board, generally used for soldering. Instead, we are using wire-wrapping so that we have a semi-permanent prototype. The only problem is easily locating connectors made for wire-wrapping since the technology has mostly been phased out, but electronics surplus stores generally have them. The reason we are using wire-wrapping is because way too often, many senior design projects at Trinity come to an end with their final prototype still on a breadboard. Not everyone knows how to solder, or is good at soldering. I didn't learn how to solder until this past school year, when I needed to make a sturdy prototype for my senior design project. I'm mediocre at it, but I'm a lot better than I was a year and a half ago when I was so inept with a soldering iron that I burned my right pinkie pretty good and nearly dropped the iron right into my lap. But that said, wire-wrapping is a good middle ground since it's more permanent than a breadboard but doesn't have the learning curve that soldering has.
This is the "program" that controls the motor. The program has four modules it uses to operate (it should evident which one is which): A clock divider that takes the 50MHz system clock and divides it down into decades starting at 1MHz, a RAM module for memory, a PWM generator which uses a 20ms cycle and allows pulse widths from 0ms to 20ms, and the logic circuit used to turn braking and direction signals into signals that the SN754410 can use. The PWM generator uses the toggle switches on the DE2 for input. Since we wanted to have the full range of 0ms to 20ms available to us for use, we had to use 5 bits for data. Since this allows for numbers up to 31 (11111 in binary), there is a line of VHDL code in the PWM module that caps the high-time value at 20ms, even if it is being given a value greater than 20 (confusing enough? :) ).The big accomplishment this week was adding addressable memory to the system. Its data input is the 5 bits for pulse width high-time, 1 bit for braking, and 1 bit for direction. Different presets can be applied to different addresses in memory, thus allowing for fast switching between low and high speeds in different directions. Currently, the input method used, as mentioned before, is the toggle switches and push-buttons on the DE2. The first 8 switches (7 to 0) are used for PWM-Brake-Direction input, the next 4 (11 to 8) are used for the address, the leftmost push-button is used as the write-enable for the RAM, and the rightmost push-button is used as the enable for the PWM generator. Eventually, this will be controlled via PCI, which is the supreme goal for both the robot arm and the visible motor. The nice thing about controlling everything this way is that the code is very easily ported between mechanical systems. Since we're using DC motors in both instances, I can use this exact same software to control the DC motor mounted to the model motor. Of course, in that case, a single MOSFET will be used as opposed to a full-fledged H-Bridge IC, since the model motor will be using only one DC motor and will have unidirectional rotation.
The other good thing is that we now have both of our PCI Dev Kits in. Seen above is the MAX II PCI development kit mounted and operating with the Efika. Now we just need to write some code on the Efika end and we should be up and running. The Cyclone II PCI Dev Kit doens't fit inside the OpenClient case so we're going to work on fixing that by getting a PCI riser and mounting the Cyclone II Dev Kit on top of the case.
original posted by Charles Jarvis on 25th August 2008
We got the Altera PCI dev kit in today, so work will start on that soon. So that said, here are some pictures of our projects in progress.
First is our new standalone development board. Across the top, you can see that it has USB input, Firewire input, Mic/Line IN/OUT, 2 RCA Video inputs, VGA output, an Ethernet connection, an RS-232 connection, and an SD Card input on the bottom of the board (not in picture). Most of these features won't be used in the courses here at Trinity, but if I have some downtime anytime soon, I plan to play around with alot of the fancier features, get them working, and document them.
Second is the model motor we will be using. As soon as our machine shop technician gets back from vacation next week, we will have a mount built so that a DC motor can be mounted to drive the crankshaft.
Third is the robot arm we have built. It has 5 DC motors to control it's movement: One at the base which allows almost 360 degrees of rotation, three at each joint on the arm, and one to control the clamp at the top. Sometime this week, we will begin to place sensors on there so that we can grab position measurements. On the bottom right is the logic and driver for one of the motors. The plan is to implement that logic in VHDL and put that on to our DE2, and put two more SN754410 chips on there so that we can control 5 motors easily.
Fourth is the Altera PCI Development kit we just got in today. One immediate hurdle we have to overcome is fitting this thing inside one of the OpenClient cases. It's physically too big to fit in the cases we have. Also, there is an extra set of "pins" (or whatever the proper name for the PCI connectors are) on the bottom right side of the board. This may be for PCI Express, but we'll have to research that before taking a saw to our equipment (These PCI dev kits are about $1000 each).
It's been a month and we've made quite a bit of progress with our projects.
I. Instron Strength Tester
This was one of the first projects to be worked on this summer. For the past 25 years, the Instron 4201 in the Trinity Machine Shop was run by an IBM PC XT, which ran a $10,000 software package made by Instrong specifically for the 4201. Because of the high cost, it was never updated (nor did it need to be, since the only upgrade would be a prettier interface). Our aim is to replace the old system with a LabVIEW VI run on an Efika OpenClient/QNX package available from National Instruments. Most of the LabVIEW work was done this past spring semester by one of this years graduating seniors, Alexandra Miller. Now all of the kinks are worked out and a few more features--such as raw data formatting, plotting, and important material property calculations--have been added, so the VI is nearly ready for student use come August. However, progress has somewhat stalled with the OpenClient/QNX package, so the system is temporarily running on a Dell PC. Alot of the QNX work was done by an NI intern who we're trying to get in on the project.
II. Controls Projects
One of our other projects is to use a PCI-capable FPGA to interface with/control a set of "plants." However, the PCI-capable FPGAs are on backorder from Altera until August, so in the meantime, we will develop the control systems and interfacing with a standalone Altera development board. Two of the plants have been constructed. The V8 Model Engine was completed last week. Now it needs a DC motor mounted to it so that we can control speed via a MOSFET. The robot arm was finished a couple of weeks ago and we have made interfacing for it. We used an SN754410 Quadruple Half H-Bridge (it's a mouthful) as the motor driver and built a logic circuit that provides a layer of abstraction for the student. The system has three easy inputs: PWM, Brake, Direction, which can be easily controlled from an FPGA.
We also have a brand new Altera DE2-70 FPGA development board which will replace the old Altera UP2 development boards that we've used in the past. Most of this past week has been spent getting accustomed to the new board, since it is far more powerful and has many more features than the previous boards.
Pictues of everything will be up in a couple of days.