NEW 2009 Control System Released

[lingomaniac88]

Originally Posted by Greg Marra

I've been using cRio's this semester. Compiling FPGA code takes from 5 minutes for a simple (simple!) program, to around 15 for a still-not-that-complex-but-does-more program. It finally made this xkcd comic make sense.

I assume that the robot code will be within the still-not-that-complex-but-does-more category, if not higher. I hope that I won't have to put together autonomous code between matches like I had to do this year. Fifteen minutes from the compiler to the robot. Wow.

[Greg Marra]

Originally Posted by lingomaniac88

I assume that the robot code will be within the still-not-that-complex-but-does-more category, if not higher. I hope that I won't have to put together autonomous code between matches like I had to do this year. Fifteen minutes from the compiler to the robot. Wow.

Note: cRios let you run code in two places. The FPGA handles low-level device communication and any simple integer maths you would like to do. However, you can pass it all up to the PowerPC (which code compilation doesn't take nearly as long on) and have the PowerPC twiddle with it and send commands back down to the FPGA.

So once you get your low-level stuff working on the FPGA, you may not need to tweak the FPGA code, and can just fiddle with your higher level algorithms on the PowerPC.

[Dave Flowerday]

Originally Posted by Adam Y.

I was doing research on FPGAs and found that other people were amazed at the length of time for a simple VHDL example to compile.

The first product I worked on at Motorola took 4 hours for a full build, and 20-30 minutes to recompile if you changed one line of code. It's really not uncommon for lengthy build times in the industry. It makes you a much better programmer because you really need to take the time to understand the changes you're making before you recompile.

A lot of people get spoiled on simple projects in college or for hobby purposes and get themselves into a "change code, compile, test, repeat" loop that just isn't possible on more complex software.

It's quite possible the more complex software that will likely accompany this new controller will come with longer build times than you're used to now with the IFI hardware.

[Tom Line]

Originally Posted by Greg Marra

I've been using cRio's this semester. Compiling FPGA code takes from 5 minutes for a simple (simple!) program, to around 15 for a still-not-that-complex-but-does-more program. It finally made this xkcd comic make sense.

I admit to not being familiar with the acronyms you are using. VHDL? etc.

Is this specific to Labview or are you suggesting that even teams using Eclipse / etc and programming in C will see this kind of compile time?

IF that is the case, and C will take that long to compile for these applications, it may render it completely unusable if you have to do something that requires multiple compiles, like tuning a PID loop, unless you get more fancy and create the ability to adjust the constants with a pot / buttons etc.

[Racer26]

Someone questioned the cRIO's waterproofness... oh dear, let the water game speculation come flying now...

[seanwitte]

Originally Posted by Tom Line

I admit to not being familiar with the acronyms you are using. VHDL? etc.

Is this specific to Labview or are you suggesting that even teams using Eclipse / etc and programming in C will see this kind of compile time?

IF that is the case, and C will take that long to compile for these applications, it may render it completely unusable if you have to do something that requires multiple compiles, like tuning a PID loop, unless you get more fancy and create the ability to adjust the constants with a pot / buttons etc.

VHDL is a hardware description language which is compiled differently than a traditional programming language. Instead of compiling down to machine code it compiles down to the logic level to be burned into a Field Programmable Gate Array (FPGA).

[AustinSchuh]

Originally Posted by Tom Line

I admit to not being familiar with the acronyms you are using. VHDL? etc.

http://en.wikipedia.org/wiki/VHSIC_H...ption_Language

Depending on the rules, teams will either rarely touch the FPGA code, or never touch it. So the long compile times for compiling the VDHL code for the FPGA aren't an issue. Most likely FIRST will implement the disable logic in the FPGA. If that is the case, they won't want us to potentially mess up the disable code and therefore won't let us change it.

Most, if not all, development for our robots will be done for the 400 MHz processor. Which should have a quick compile process and a smokin' fast download.

[slavik262]

I am extremely excited about the ability to finally write code in C++. Other than what I've read on the site, does anybody know any specifics about how this will work? Will we be able to simply compile and transfer the file using the wireless into the controller? Will we have to use a specific IDE or will the compiler be useable across multiple IDEs provided we use the libraries given to us for the processor? My dream would be to write the robot code in the Microsoft Visual C++ IDE, which is better than MPLab by leaps and bounds, mostly due to Intellisense.

[RoXmySoX]

that is crazy!!!!

cant wait to test it out!

[Adam Y.]

Originally Posted by Tom Line

I admit to not being familiar with the acronyms you are using. VHDL? etc.

Uggg. I think I used the wrong acroynm. A hardware description language is completly seperate from C.

Depending on the rules, teams will either rarely touch the FPGA code, or never touch it. So the long compile times for compiling the VDHL code for the FPGA aren't an issue. Most likely FIRST will implement the disable logic in the FPGA. If that is the case, they won't want us to potentially mess up the disable code and therefore won't let us change it.

That renders the point of having an FPGA moot.

[AustinSchuh]

Originally Posted by Adam Y.

That renders the point of having an FPGA moot.

Unless FIRST is open to adding in features that teams request, and provides a basic configuration that supports some nice sensors. I would be quite surprised if that FIRST didn't implement some logic to support quadrature encoders and only slightly less surprised if they didn't implement logic for sensors like Sonar also. Otherwise you are right.

It still would be nice if they let us program the FPGA ourselves.

[NetElemental]

Originally Posted by Adam Y.

That renders the point of having an FPGA moot.

It absolutely does not - depending on what is done inside the FPGA, it could be a great tool - for example, if the WPI libraries were implemented on the FPGA, or the adc/encoder/gyro/competition mode code are on the FPGA, it is considerably faster than a microcontroller AND frees considerable processing room, as well as saves time coding. If the FPGA is designed to automatically do many of the low level functions that we as programmers normally have to wrangle with (like what Kevin Watson's libraries are used for), it would be an incredible help. Imagine never having to write code to interface with the camera, or have the gyro angle automatically calculated for us instead of having to do it ourselves - there are much greater problems that could then be tackled.

[Richard Wallace]

Originally Posted by AustinSchuh

... It still would be nice if they let us program the FPGA ourselves.

Originally Posted by NetElemental

... If the FPGA is designed to automatically do many of the low level functions that we as programmers normally have to wrangle with (like what Kevin Watson's libraries are used for), it would be an incredible help. Imagine never having to write code to interface with the camera, or have the gyro angle automatically calculated for us instead of having to do it ourselves - there are much greater problems that could then be tackled.

Some teams might like to program the FPGA. Other teams might like to design their own custom motors. FIRST wisely limits the degree to which teams can engineer at the component level, for several good reasons. Safety is a big one. Reasonable limits on work during build season are another. Keeping teams focussed on the game challenge, rather than component details, is still another.

I'd favor no team programming of the FPGA. [But of course I'm not a VHDL programmer.]

I also favor keeping the rule against custom motors. [And I am a motor designer.]

[MikeDubreuil]

Originally Posted by Richard

I'd favor no team programming of the FPGA. [But of course I'm not a VHDL programmer.]

As an embedded software engineer I wouldn't want to comment on that until we know more about the architecture of the new system. Specifically where the "safety features" reside. There's some good ideas floating around about FPGA based counters for sensors such as encoders.

[dcbrown]

After reading a lot of the stuff available from FIRST, WPI, NI, and Wind River... and doing some integration/interpretation... and guessing, the following are some random opinions

• . VxWorks is essentially (very!) unix-like operating system.

• it uses a BSP (board specific package) as h/w abstraction layer so it can be targetted to multiple platforms. The BSP exists for the cRIO. The normal VxWorks comes with a bunch of different BSPs, we may end up with a stripped down version of the environment with only the cRIO - that would make sense.
• there is a configuration process whereby you add in or remove components that you want in the RTOS build - standard stuff. Which means you can add rom-based file system, FTP, and other capability that is already available in the VxWorks kit as needed. There will be a standard config for competition, but for prototyping this opens up lots of stuff like application data logging during testing via WiFi. There are separate Broadcom device drivers available, for example, and other 3rd party driver packages.
• The IDE (Workbench) is Eclipse-based. You have the ability to add REAL breakpoints and other stuff for debugging. You'll need to compile with debug flags, otherwise you only get assembler view. Compiling w/debug goes for any libraries you'd use which is why any FIRST provided added-value such as pre-canned drivers for gyro, et.al. would need to be in a controlled source form.
• Both the Wind River C and GNU C compilers will work.
• VxWorks is RTOS, applications are either integrated into the kernel or as application. Multitasking native with 256 priorities and round-robin scheduling within priorities (so essentially unlimited tasking until you run out of main memory).
• a ton of documentation is available (I'm looking at 100mb of stuff), everything from getting started, to writing your own BSP (as if we'd ever need or want to do that!). For software mentors, start reading!
• (ok weird factoid), interrupt latency is slightly better than RTLinux, at around ~70usec (published number was 100us but that was on a MPC8260 @200Mhz processor vs 400Mhz MCP52xx of cRIO... but should give a ball park figure).
• fun stuff like a shell window on the target (cRIO) that you connect to and use from the development host [I guess like a console].
• lots and lots of other good stuff if you're an applications programmer.

Someone (WPI?) will provide the pre-canned "driver" software for the common interface devices; gyro, camera, sonar, and the like similar to the WPILIB today. It will be provided in source form. This combined with a default VxWorks project will provide the default/base code for the robot next year. I haven't read far enough into "Wind River General Purpose Platform, VxWorks Edition - Getting Started" to see how much work it will be to change drivers, but if the pre-canned driver software is open-sourced then you could use that to slightly modify things as needed for your robot - but suspect that shouldn't be needed often.

Custom h/w and/or driver software will likely be discouraged the first year. Both would make it difficult to provide the type of deep generic support needed across all the teams. The programming of the FPGA will be canned and shouldn't be touched by individual teams again for the same reasons. Maybe in later years we'll be able to change this.

LabVIEW is built on top of what VxWorks provides, so C/C++ is actually the native method of building apps.