Windows 7 64bit Compatibility For ALL Tools ??

[Tristan Lall]

Given Joe's clarification, I withdraw my indictment of Wind River. (I assume that if I'd read the documentation thoroughly, they'd have explained somewhere that it wasn't their fault.)

Now I'm curious: which changes to VxWorks are incompatible with the cRIO-FRC? Did they stop supporting the PowerPC processor, or something like that?

[jhersh]

Basically it means we need to either find a new solution for the C++ environment or we need to require teams to come up with a 32-bit environment, albeit painful.

We aren't sure why some see problems and others don't. Not enough samples, I guess.

[jhersh]

Originally Posted by Tristan Lall

Now I'm curious: which changes to VxWorks are incompatible with the cRIO-FRC? Did they stop supporting the PowerPC processor, or something like that?

For one thing, the networking stack was completely replaced. There have also been innumerable little changes that break compatibility in source, binary, behavior, etc. It is simply not an approachable amount of work.

[rrossbach]

Originally Posted by jhersh

Modern WindRiver tools do support 64-bit Win 7. The reason FRC is not able to take advantage of that is because the version of VxWorks running on the cRIO is too old to work in the latest version of WindRiver Workbench. WindRiver Workbench version is directly tied to the VxWorks version. Upgrading VxWorks on the cRIO is not a viable option because of the immense changes to VxWorks since 6.3.

According to WindRiver's product note, Workbench 3.3 supports Win7 x64 on the host side, and VxWorks 6.3 as a target. Is this already being checked into?

As a side note for anyone interested, there is a wealth of information in this guide on developing c/c++ without having to use WindRiver - much of the information refers to using the gcc command-line toolchain, but that can be driven from other IDE's if you so choose. Of course, the main thing that is still lost without WindRiver is integrated debugging on the target.

- Ron
Team #2607 controls mentor

[Mark McLeod]

I think we're running Workbench 3.0.1
Eclipse is the 3.3.1 version

I can't confirm or lookup the appropriate product notes right now though, so I don't know if that is much of a difference or not.

[rrossbach]

Originally Posted by Mark McLeod

I think we're running Workbench 3.0.1
Eclipse is the 3.3.1 version

I can't confirm or lookup the appropriate product notes right now though, so I don't know if that is much of a difference or not.

Right, I realize the Workbench version currently supplied in the KoP is "old" and isn't supported on Win7 x64 - I guess I should make my question clearer.

It seems like Joe was indicating that we couldn't use a modern Workbench version (i.e. later than WB 3.0) because the later versions didn't support VxWorks 6.3, and we're constrained to use VxWorks 6.3 on the cRIO.

However, per the WindRiver product note it seems that WB 3.3 does support VxWorks 6.3, and it is certified on Win7 x64. So, is anyone working on testing WB 3.3 and possibly getting it included in the KoP, as opposed to the out-of-date WB 3.0.1?

- Ron
Team #2607 controls mentor

[Mark McLeod]

Ah, I didn't understand you were asking for more details about why FRC made the decision not to upgrade to Wind River Workbench v3.3.

[jhersh]

We are exploring several options, but there is no solution yet.

[kirtar]

Ummmm I know for some software if it doesn't have a certified driver or w/e, Windows 7 and Windows Vista (x64 only) will complain and not let it run. Worst case scenario, if you're running professional or better on Windows 7, you could use XP mode