[Thad House]

Originally Posted by Necroterra

I see now why such accuracy would be necessary, we never aimed for anywhere close to that level of detail.

So if I understand this DMA thing, the FGPA reads off the sensor values on an event happening, and the relatively slow accessing of the memory can be done later? Wouldn't that still give you inaccurate data unless you added on the expected change since it was read?

Also, by upstreamed, do you mean it will be part of default WPILIB?

Also, I read about CAN a while ago and iirc it isn't designed to have a specific frequency of changing the message frame, it just does it whenever it has time within a certain range. You can mess with the frequencies, but then you run the risk of maxing out the buffer. I would guess that it's intended for more complex data communication, and PWM is definitely better for a sensor that outputs a single value.

As for the JNI bindings, wpilibJ loads up a library called "libwpilibJavaJNI.so", which I would assume is either the NI library or a bridge to it.

All of the WPILib code is public, but its kind of a pain to find. It also uses the NI implementation. This is the callback that gets called by the interrupt.

void interruptHandler(uint32_t mask, void *data) {
	INTERRUPTJNI_LOG(logDEBUG) << "Calling INTERRUPTJNI interruptHandler";
	InterruptHandlerParam *param = static_cast<InterruptHandlerParam *>(data);

	INTERRUPTJNI_LOG(logDEBUG) << "InterruptHandlerParam Ptr = " << param;
	INTERRUPTJNI_LOG(logDEBUG) << "InterruptHandlerParam->obj = " << param->handler_obj;
	INTERRUPTJNI_LOG(logDEBUG) << "InterruptHandlerParam->param = " << param->param;

	//Because this is a callback in a new thread we must attach it to the JVM
	JNIEnv *env;
	jint rs = jvm->AttachCurrentThread((void**)&env, NULL);
	assert (rs == JNI_OK);
	INTERRUPTJNI_LOG(logDEBUG) << "Attached to thread";

	env->CallVoidMethod(param->handler_obj, param->mid, mask, param->param);
	if (env->ExceptionCheck()) {
		env->ExceptionDescribe();
	}

	rs = jvm->DetachCurrentThread();
	assert (rs == JNI_OK);
	INTERRUPTJNI_LOG(logDEBUG) << "Leaving INTERRUPTJNI interruptHandler";

So any slowness with interrupts would happen in this function. My guess would be that it attaches the interrupt thread to a new JVM thread, and then gets sent to the JVM scheduler, which doesnt have to start the thread in Java immediately.