cRio external 'co-processor' options
 

What options are there for interfacing other devices with the cRio? From the photos I see two Ethernet ports and a serial port. Obviously there are the Digitial I/O ports, but I'm looking to transfer a significant amount of data.

One of the Ethernet ports has to be used for the access point, so I suspect that the rules will be strict about that configuration.

The other Ethernet port is supposed to be used for an Ethernet camera, but would it be possible to put an Ethernet switch on that port and attach another device to the switch as well? Or, are there restrictions (software, hardware, or rules) in place to prevent this type of configuration?

Is the serial port accessible from user code?


I realize that rules and software may change before the season starts, but I'm working on a project and I'd like to get an idea of the options before I proceed any further. I'm hoping that some of the beta test teams will be able to provide me with some answers.

Re: cRio external 'co-processor' options
 

I can't tell you much about the rules, but I can tell you that the serial port is accessible.

Greg McKaskle

Re: cRio external 'co-processor' options
 

Thanks, that what I needed to know.

Re: cRio external 'co-processor' options
 

I think we are all curious - what is this co-processor you are adding?

Re: cRio external 'co-processor' options
 

There is also an I2C port.

Re: cRio external 'co-processor' options
 

Past rules will not necessarily apply to what will be allowed in 2009, but "co-processors" and other custom circuits were allowed on robots, subject to cost limits ($400). There were other restrictions as well: no custom PWM circuits to Victor inputs, no wireless communications, no connections to radio or tether ports on the RC, etc.

There are some interesting co-processor options out there; just check out the choices at Tern, Inc.

But, before I'd worry about how to interface external processing capability, I'd want to understand what the cRIO system can do itself!

Re: cRio external 'co-processor' options
 

I don't want to talk about the details, yet. I will say I'm not really going to be doing any processing that requires an external processor, but I now have a functional prototype and I'm concerned about the time involved porting and debugging it on another platform.

If I have time once the new system ships I will probably port it over, but I want to plan for the very likely scenario where I don't have that much time.

My current prototype is using a system which is far less than $400, and I'm not concerned that the cRio couldn't handle what I'm doing. I don't believe the time involved to port my current project to the cRio is worth the effort if I can simply interface with my existing hardware using a relativity simple protocol.

Didn't know that, thanks.

Re: cRio external 'co-processor' options
 

How much data do you have to transfer? If it's just motor values (since your co-processor mustn't control motors directly, correct?), then serial should be adequate.

Re: cRio external 'co-processor' options
 

I've been testing with serial between my prototype and a PC, and that seems to be adequate.

Re: cRio external 'co-processor' options
 

From what we saw at the demo (We're not a beta team) the Ethernet hardware is quite capable of networking to another system (co-prossessor). I did not see any DHCP controller software (Greg ... is the cRIO under VxWorks capable of being a DHCP server?) so the addressing may be in the FPGA (in which you wont be able to use the ethernet port for further networking). Since the rules haven't come out, no one can answer that, however if the hardware/software is capable it is unlikely that they will restrict coprossessors. They will, most likely, ban other transmitters (such as 900 MHz cameras) though.

Other data connections:
I2C
Serial
DIO
All are accessable but you'll most likely have to write your own (or modify) driver to interpret the data.

Last year the rules were no single electronics device over $400. There are a number of off the shelf devices that conform to that. Last year we used a $250 ARM gumstix coprossessor through the onboard serial (program?) port to interpret SONAR signals.

Good luck.

Re: cRio external 'co-processor' options
 

I know a DHCP server isn't running, and I don't think one is on the controller that simply needs to be enabled. The enet expandability depends directly on whether or not a switch, hub, or other enet expansion device will be allowed. Currently there are two ports, one for radio, and the other used by the camera, if you use it.

For future years, another expansion bus is CAN.

Greg McKaskle

Re: cRio external 'co-processor' options
 

DHCP is only used with TCP/IP, which can be used over Ethernet, but other Protocols also work over Ethernet.

I like CAN, I use it every day at work....

Re: cRio external 'co-processor' options
 

The FPGA has nothing to do with the Ethernet ports or the serial port. Those are connected directly to the PPC processor that will be running your code. As Greg said, no DHCP.

The FPGA provides access to a dedicated I2C engine for each digital module. It also has a buffered (512 word send and 512 word receive) SPI interface. You can also use the DIO directly.

-Joe

Re: cRio external 'co-processor' options
 

Why are people concerned about not having a DHCP server? DHCP is not an integral part of the TCP/IP stack, and can be bypassed simply by configuring a static IP address. DHCP is only used to allow more flexibility in network topology.

My assumption would be that the cRio's access point NIC would be a DHCP client and the cRio's second NIC and the camera would have static, but configurable, IP addresses. Can any of the beta teams confirm this?

Re: cRio external 'co-processor' options
 

Actually, both NICs are given static IPs. The access-point-facing IP is 10.xx.yy.2 (where xxyy is the team number in base 10 digits), and the camera-facing IP is 192.168.0.3. I imagine there's a way to change these from the cRIO software, but I don't know how, nor can I think of a reason for bothering to do it.