VxWorks Kernel

[Cadyyan]

So I've been wondering...I've heard that the VxWorks kernel is open source. Is this true? If it is true where would I be able to download the source code for it?
Thanks for any responces!
~Cadyyan~

[Dave Flowerday]

Originally Posted by Cadyyan

I've heard that the VxWorks kernel is open source. Is this true?

Definitely not.

What are you trying to accomplish? There are plenty of open-source kernels out there if you're interested in browsing some source and learning a bit.

[Cadyyan]

I'm currious about how the watchdog actually turns off the robot. I had an idea, not sure if it is already implemented in the library and I just don't know about it, about having the DS display where in the code the watchdog timed out at. I hate having to hunt through code to find watchdog errors when I program blind.

[The Lucas]

Originally Posted by Cadyyan

about having the DS display where in the code the watchdog timed out at.

The watchdog doesn't know where in your code it is when it times out. It just knows it hasn't been fed. I would guess the watchdog is implemented in the FPGA.

[RyanCahoon]

Originally Posted by Cadyyan

I'm currious about how the watchdog actually turns off the robot. I had an idea, not sure if it is already implemented in the library and I just don't know about it, about having the DS display where in the code the watchdog timed out at. I hate having to hunt through code to find watchdog errors when I program blind.

The watchdog timer is a hardware device; there's may not even be a dedicated function in the kernel that manages it, because VxWorks can run on many different hardware architectures. While I can't tell you how watchdog is specifically implemented on the cRIOs, I can tell you how they work in general. (For more information, you can also look at the Wikipedia article or one of these articles on NI.com)

One of the fundamental hardware devices in a microcontroller is a hardware timer. The function of such a device is, when told, periodically decrement a number in its internal memory, and then when that number gets to 0, set its output to a high state (output a "1" if you want to think in binary). The processor in the microcontroller is hooked both to control lines for the timer in order to start and stop it and to set the timer's counter value, and to the timer's output line so that the program running can use it like any other digital input (or more commonly the output will be connected to a hardware interrupt line so that the program is actively notified whenever the counter reaches zero). Timers (also called counters) are used for many things in embedded programming, including generating PWM signals to control motors, control operating system scheduling routines, to regulate transmission rates over communication ports such as RS232, I2C, or SPI, etc.

A watchdog timer is a hardware timer whose output line, instead of being connected to an input to the processor, is instead connected to the processor's reset line. Thus if the timer is allowed to reach 0, it will cause the processor to reset. When you first open the watchdog (Watchdog Open.vi or new Watchdog(); ) it enables the watchdog, meaning the watchdog starts counting down. Whenever you feed the watchdog, you are resetting the counter value to a large enough number. Thus, if the watchdog isn't fed often enough, the timer will reach 0 and the processor will reset, all as hardware functions. Because the watchdog is a hardware device, as [The Lucas] pointed out, it's probably connected through the FPGA, as that seems to be how most hardware devices are connected in the cRIO, but this will be part of NI's proprietary hardware design, so I doubt anyone who knows could tell you.

So basically (as [The Lucas] also pointed out) it's not possible to know where the watchdog timed out because if the watchdog is working properly it will only reset when the code is frozen. The best thing you can do is routinely update the DS's display with some indicator of the last thing that was run in your code, and so when the Watchdog throws the display will be stuck there.

Good luck,
--Ryan

P.S. For a good free open source kernel, check out the FreeRTOS project.


EDIT: Looks like link to the second NI article is dead for the moment.

[Greg McKaskle]

The FRC watchdog is not implemented in the kernel, but in the FPGA. cRIO, which NI pronounces see-ree-oh, rather than kree-oh, stands for compact Reconfigurable I/O. The reconfigurable piece is the FPGA which can be used to implement lots of custom circuit fabric.

In the FPGA for FRC, almost all of the outputs are conditional. If the system watchdog timer is happy and fed, then the setpoints for PWMs, relays, etc. will be in control of the I/O. If the watchdog is unhappy and unfed, the outputs are forced to the disabled state.

The watchdog itself is simply a counter, like an egg timer. Each time it is fed, the countdown timer is reset to the watchdog period, ~200ms I think. The e-stop and kill immediately set the value to zero, and prevent a simple feed from enabling again. Much of the watchdog circuitry is actually the interconnection to the I/O.

The system watchdog is completely controlled by the communications protocol. If the system watchdog goes unfed it is because the DS control packets have stopped arriving, or possibly because the task on the cRIO that handles the packets has somehow died and is no longer feeding the watchdog.

The second watchdog, the user watchdog, is also not implemented in the kernel. It is implemented in the WPI layer. If it is used, it must be fed. If your user watchdog goes off, search for the feed calls. It means that NONE of those were called for the watchdog period. Personally, I think there are a number of API changes that can make watchdogs easier and even safer, but that is for another year.

Greg McKaskle

[Cadyyan]

Thank you guys for all the great information. I think I have an idea now of where to start. I think I'm just going to update a new class as to specific code events and have it display to the cRIO so that you can look at the last event.