Assembly On The cRIo

[davidthefat]

Ok I first started reading up on Assembly (Not to know what it is but to learn it seriously). So I am just learning up on Assembly for the x86 systems, the usual computer. Now since x86 systems are CISC, most microcontrollers are RISC, so they have 2 totally different Assembly languages from what I understand. I heard from my friend that the cRio has a PowerPC core, is that true? Second question, the cRio having a FPGA, is that a whole different ball park? Is it on the same playing field as CISC an RISC? Apparently all this talk makes me want to get into computer engineering. So does that mean that I can't write an Assembly program for the cRio, but that does not make any sense. Since it can be programmed with C++ and Java, which are then assembled into machine code. So that concludes that I can in fact write in Assembly for the cRio.


So can I just use the

asm 
(
//Assembly code here
);

Then do I have to use the PowerPC assembly?


Why I would want to use Assembly on the robot is a whole 'nother discussion



edit: a bit of research led to conclude that FPGAs use Hardware Description Languages, and I assume those are the equivalent of Assembly for FPGAs? So does that mean I can not use Assembly for the cRio? Vertigo is one of those HDLs

[flameout]

I'll answer as many of these questions as I can.

Originally Posted by davidthefat

Now since x86 systems are CISC, most microcontrollers are RISC, so they have 2 totally different Assembly languages from what I understand.

Every different processor architecture has its own assembly language. x86 is one. MIPS has another. ARM has another. PowerPC has another. Even within x86, different processors support different instruction sets.

I heard from my friend that the cRio has a PowerPC core, is that true?

Yes.

Second question, the cRio having a FPGA, is that a whole different ball park?

Here's where my knowledge becomes thin. I'll answer "yes," as they are programmed with hardware description languages.

Is it on the same playing field as CISC an RISC?

I'm not entirely sure of the question, but I think that hardware description languages are more high-level than assembly (the FPGA equivalent of which would be something like a "logic circuit").


You should be able to program the cRIO in assembly, given compiler support for it (which almost all modern compilers have). The FPGA, however, is not a processor and therefore has no instruction set (and thus no assembly language exists for it).

Then do I have to use the PowerPC assembly?

Yes, you would, since the cRIO is PowerPC.

I hope this answers some of your questions.

[davidthefat]

Originally Posted by flameout

I'll answer as many of these questions as I can.

Every different processor architecture has its own assembly language. x86 is one. MIPS has another. ARM has another. PowerPC has another. Even within x86, different processors support different instruction sets.


Yes.


Here's where my knowledge becomes thin. I'll answer "yes," as they are programmed with hardware description languages.


I'm not entirely sure of the question, but I think that hardware description languages are more high-level than assembly (the FPGA equivalent of which would be something like a "logic circuit").


You should be able to program the cRIO in assembly, given compiler support for it (which almost all modern compilers have). The FPGA, however, is not a processor and therefore has no instruction set (and thus no assembly language exists for it).


Yes, you would, since the cRIO is PowerPC.

I hope this answers some of your questions.

Thank you very much for clearing a lot of thing up for me, now would the PowerPC book from the 90s be obsolete? From what I read the PowerPC cores have gotten a complete overhaul

[AustinSchuh]

Originally Posted by davidthefat

Second question, the cRio having a FPGA, is that a whole different ball park?

edit: a bit of research led to conclude that FPGAs use Hardware Description Languages, and I assume those are the equivalent of Assembly for FPGAs? So does that mean I can not use Assembly for the cRio? Vertigo is one of those HDLs

As a first approximation, FPGA programming is completely different from what you think of as programming. It's an entirely different mindset, and leads some very subtle bugs that are hard to find. (At least when I programmed one in Verilog, but my understanding is that these class of bugs are common to the architecture, not the language) It also takes a while, because of this. You can think of an FPGA as a bunch of logic blocks and a huge matrix of patch cords that you programatically connect up. So, in effect, you are really wiring up logic gates to do what you want. Which is really cool, since all the logic gates do computations in parallel, which leads to some tremendous speedups from code.

The equivalent of Assembly on an FPGA would be to hand configure the LUTS and do the routing by hand. Nobody really does that, since it is so tedious and error prone. Another equivalent might be invoking the actual simple logic gates in Verilog and wiring those up directly, rather than using the faster syntaxes that exist for inferring logic. After trying each of those once, you quickly realize that just using the higher level features of the languages save a heck of a lot of time, and you can get them to generate code that is either better than what you could do by hand, or the same.

Keeping that in mind, if you really want to get into FPGA programming, I recommend starting out by simulating everything. Since it is so hard to debug on the real device, it is best to catch everything in simulation through unit tests. I don't know how to download to the FPGA on the cRIO though, so that might not get you too far. There are plenty of smart people here on CD though who can help with that and answer questions on how to go about hardware design.

[virtuald]

You not only need to use PowerPC assembly, but you need to use the flavor of assembly favored by gcc/gas (at&t syntax, which is just terrible IMHO). If you're doing stuff inline, you also have to make sure to respect the gcc's ABI for the platform, and don't clobber any registers that it isn't expecting you to clobber.

This is mildly useful, just google "gcc powerpc inline assembly"l: http://dslab.lzu.edu.cn:8080/members...rogramming.pdf

Keep in mind that really, there are *very* *very* few cases where you would actually want to use assembly language. Most of the time it's not worth it.

[Robototes2412]

Assembly on the CRIO?

+9000 man points

[Greg McKaskle]

The processor instruction set used by the cRIO was called the 603e when I was familiar with it. It is a very basic RISC and predates the Altivec extensions for vector math and such. Any book on PPC will get you going, and IIRC, unless you are disabling interrupts or messing with the MMU, they are quite similar.

As for the FPGA. it is a very different approach. Normal micro-controllers and computer CPUs use their basic circuits to construct a higher-order but flexible Von-Neumann machine that retrieves some memory (an instruction such as add). This activates and deactivates portions of the circuit to carry out the add operation on the contents of other fetched memory or registers. By supporting the most basic operations, the circuits enable a sequence of instructions and initial data to specify a higher level and super-flexible machine that can compute almost anything.

The FPGA circuits, as the name implies, is an array of low-level logic gates and other resources that can be used to build up a micro-controller, ad-hoc micro-controller components, or pretty much any other special-purpose circuit. Traditionally, they were used to prototype, and when the prototype functioned correctly, they would spend the time and money to produce the special purpose ASIC chip -- a silicon level single-purpose device which could operate faster and was cheaper to produce. It was used instead of a micro-controller either due to speed or cost issues.

As capabilities of FPGAs grew, they were not only used for prototypes, but also for HW flexibility. In the nineties, NI started using them on high speed boards to be patched to resolve bus control issues between platforms or between OSes or OS versions.

cRIO stands for "compact, Reconfigurable, Input and Output". The R represents the FPGA's ability to construct highly flexible custom circuits that allow the customer to design their own high speed circuit as part of their monitoring or control application. One day, they can route digital values from a prototype communications board and monitor for circuit glitches. The next day, the same HW has a new FPGA image that produces the signals for an automotive ECU. The following day, it might be used to synchronize clocks on various cards to enable a sensitive measurement within a prototype MRI machine. And on its days off, it can implement the PWM generation, encoders, and accumulators to allow a FIRST robot to be able to do all of those things in parallel with HW timing.

I'd suggest reading about FPGAs as future computing architectures will, I believe, become somewhat more like the RIO, with circuits that reconfigure for special tasks, but aren't limited to the I/O speeds of micros and aren't purpose limited like ASICs. If you have a project and want to program them, you can use Xilinx tools or NI tools to program the cRIO FPGA -- for offseason nonrobotics projects of course.

Greg McKaskle

[davidthefat]

So in theory I can, with the use of Vertigo or some other HDL, make the cRio "multi core". The FPGA can be split into seperate "modules" that can be used to do some pseudo parallel processing. Now I think that probably is a waste of time since I can put together custom cuircuts and use in on the robot. Im looking into PS3 homebrew, may be its a bit of a stretch, to use it on the robot to handle the image processing. Might seem redundent since a small micro controller like the CMUs can handle images fine, the Cell Processor might be an over kill. I was thinking that since I would be killing 2 birds with one stone, or more like killing a stone with 2 birds. Since the cRio and the PS3 are both PowerPC based, they both use the same assembly language and I can program both in C++ fine. I been poking at the idea for programming on the PS3 for the longest time ever since I gotten it like 3 years ago, I had the chance to but never really took the chance because the Linux on the PS3 was too slow for my liking. But now it has homebrew, and Im still running linux on that baby. I think the challenge this year is going to put a fire under my butt and force me to explore things out of my comfort zone, like Assembly, programming the Cell Processor on the PS3, Cocurrent Programming.

I just started viewing thelectures from Programming Pardigms class at Stanford posted on youtube. It coverd from the ideas of procedural (C), Assembly, Object Oriented (C++), then into cocurrent programming, scheme and python. I think this will greatly benefit me with my "quest".

[Greg McKaskle]

So in theory I can, with the use of Vertigo or some other HDL, make the cRio "multi core". The FPGA can be split into seperate "modules" that can be used to do some pseudo parallel processing.

Pretty much any task the FPGA performs is true parallelism, not pseudo. In the FIRST usage, it generates PWMs, counts encoder transitions, accumulates gyro deltas, and performs all of its duties in parallel and independent of the PPC. Can you generate a core to have an additional full-fledged CPU? Yes, but that takes lots of gates, and this wouldn't be a cost-effective way to build a PS3.

Might seem redundent since a small micro controller like the CMUs can handle images fine, the Cell Processor might be an over kill.

Image processing on a small micro is impressive when it works, but image processing has the ability to absorb as much processing as you can throw at it. For a good example, the PR2 from Willow Garage has numerous cameras in its head and others in its arms. It has 2 quad-core Xeon processors in each server, and two servers on the robot, each with 24GB of memory. With all that , you can see some pretty cool algorithms that enable it to do what a four or five year old child can do. I'm not knocking it, but just pointing out that image processing is in its infancy, and today, will easily consume as much CPU as you can throw at it.

If you decide to program a PS3, write fully auto for the robot, or any other project, I encourage you to focus on the follow through. Starting projects is fun, easy, and exposes you to new things, but finishing them shows true character.

Greg McKaskle

[taichichuan]

If you're really interested in assembly on the cRIO, then any of the PPC "green" books on the 603e instruction sets would work. Even though the architecture has been expanding, the basics (including the instruction set) are the same. The WRS tools include gas (the GNU assembler) that can be used to assemble files into machine code.

Of course, if you open the host shell in Workbench (the button that looks like an "i" with an arrow pointing to it) you'll be able to interact with the cRIO in assembly. The commands "s, so, l, and b" all work at the assembly level. And, the GNU debugger is capable of showing mixed C/C++ and assembly. It can be really interesting to look at the C/C++ source and the assembly that was produced by the compiler.

However, I'd suggest that the GNU inline capability is likely all you'll need (if you even need that). The better investment of your time would be to look at the underlying O/S and its capabilities. VxWorks is a powerful O/S that's been used for hard real-time systems for over 20 years. You can do a lot to speed up your robots by taking advantage of the services that VxWorks provides.

HTH,

Mike

[davidthefat]

Thank you all of you.

I found what I need all online I LOVE MIT and Stanford for their lectures for free on iTunes. Who would have thought, a class on multicore programming with the PS3, and a Machine learning course in Stanford and a programming Paradigm course. Now I just need like extra 78 hours of my life just dedicated to watching those lectures and taking notes... Which I do not have.