I Have A Question About Pointers

[wireties]

Originally Posted by Greg McKaskle

I'm not on the RT team, but the reason I was given was that when they did the board support, the RTP introduced too much overhead for the I/O drivers. Until FRC, the only C programmers for the cRIO were the NI developers, so they kept it in kernel mode. At that time, all other users of the cRIO used LV.

Exposing the C/C++ interfaces and tools, going to RTP was evaluated, but there would be a lot of work and testing involved, and it would mess with the I/O rates of various drivers.

There are good reasons for staying in kernel space. I wasn't knocking NI's choices. But hey - if the students are running Java, how can isolating (just the students code) in an RTP slow things down too much? For example, the PID controller tasks could run in kernel context and share a memory region where the students code updated the operating parameters. This specific example would result in no performance penalty at all and errant student code code not crash the kernel or the NI infrastructure. I'm not a strong or gun-ho advocate but, strictly speaking, it is possible.

HTH

[wireties]

Originally Posted by Ether

Are these three Guides freely available online somewhere, for those who do not have the Workbench installed ?

Not that I know of - WindRiver does not open source VxWorks (or its documentation) yet. But you don't need Workbench to view them. I think they exist in html and/or pdf format. If someone on your team has Workbench installed they should be able to find them and give them to you. I doubt that would violate the WindRiver-FIRST licensing agreement.

HTH

[Ether]

Originally Posted by wireties

There are good reasons for staying in kernel space. I wasn't knocking NI's choices. But hey - if the students are running Java, how can isolating (just the students code) in an RTP slow things down too much?

Greg said the IO was the issue.

[Ether]

Originally Posted by wireties

Not that I know of - WindRiver does not open source VxWorks (or its documentation) yet. But you don't need Workbench to view them. I think they exist in html and/or pdf format. If someone on your team has Workbench installed they should be able to find them and give them to you. I doubt that would violate the WindRiver-FIRST licensing agreement.

Would these VxWorks documents be on a machine that has the 2011 FRC LabVIEW Framework installed? Or only if C++ is installed?

[wireties]

Originally Posted by Ether

Would these VxWorks documents be on a machine that has the 2011 FRC LabVIEW Framework installed? Or only if C++ is installed?

Only if Wind River's Workbench is installed, which is most of the C++ install I think.

HTH

[Ether]

Originally Posted by wireties
Check Help->Help Contents->Wind River Documentation from the Workbench IDE. Under Guides->Operating System there is a Application Programmers Guide (which is about programming in a RTP) and a Kernel Programmers Guide (about programming in kernel space/mode) and a BSP Developers Guide (which is about building a board support package - which NI gives us). In our case, NI and/or WPI chose to not use RTPs and stick everything in kernel space/mode (probably because that is how LabView's code generator works).

Originally Posted by Ether
Are these three Guides freely available online somewhere, for those who do not have the Workbench installed ?

Found them on-line, if anyone else if interested:

Kernel Programmer's Guide v6.7

Application Programmer's Guide v6.7

BSP Developer's Guide v6.7

[wireties]

Originally Posted by Ether

Found them on-line, if anyone else if interested:

Kernel Programmer's Guide v6.7

Application Programmer's Guide v6.7

BSP Developer's Guide v6.7

FIRST is running 6.3 (I think) but not too much has changed.

[davidthefat]

Originally Posted by Ether

Found them on-line, if anyone else if interested:

Kernel Programmer's Guide v6.7

Application Programmer's Guide v6.7

BSP Developer's Guide v6.7

Thank you sir.