Can I pass a reference to a event to my device driver to be activated when an operation is complete?

Question

Hello,

I'd like to be able to create a general mechanism where my application can send a request to a device with the device driver knowing as little as possible about the request, so I can extend the device command set without altering the driver.

What I'd like to do is pass a reference to an event to the driver, and have the driver trigger the event and send a void * data value for the application to interpret. It seems like triggering an event is the best way to go - UpdateProperty wants a specific data type, and I'd like for the driver not to have to know the data type of the result.

I wrote a small app to test the concept, and I see the code generated for the trigger event is:

    /* This method is intended to be called by the device to notify the GUI applicationabout a particular system event. */
    void ApplicationDeviceClass_TriggerEvent( ApplicationDeviceClass _this )
    {
         CoreSystemEvent_Trigger( &_this->SystemEvent, 0, 0 );
    }

It seems like the parameter is supposed to be a reference to the class, not arbitrary data. Is that correct? Or does the parameter get passed to the event handler without being interpreted? It the second case, can I pass a reference to the trigger function to my device driver to be called when the operation is complete?

Thanks!

Answer 1

Hello,

in principle it would be possible to pass a reference of a system event to the device driver - but this has to be done very carefully in order ot avoid that the Garbage Collector is removing the instance...

The recommended way is to use a set of sytem event classes that are used to promote the different events from the device driver into your UI application. Within your UI application you can then react with suitable system event handler on the dedicated system event. Otherwise, if you just have one generic system event all system event handler will react on every system event and they all have to evaluate the current status.

Best regards,

Manfred.

Comments

Hi Manfred,

Thanks for your answer and the quick response. If I understand correctly the second option you propose is to  generate a single event for all types of responses from the device, and have the UI application ask the driver for information about the response when that event is received. That could work, but could also stall device communication if the UI application fails to retrieve the response information. (It seems like I'd have to delay sending new commands to the device until the previous command response was handled by the UI so that the information isn't lost.) The handler for this system event would have to be associated with an object that won't go away, correct? Like an auto global object?

I'm not sure I understand your first option - do you propose the driver having a map of command responses and system events? That sounds very much like what I want to do, especially if I can define the map dynamically and download it to the device driver. Do you have any example code on passing this type of information to the driver? Would I pass pointers to TriggerEvent functions?

Thanks very much for your help!

Greg

---

Hi Greg,

I think you understood the idea correctly. Concerning the global auto objects, please also consider the lifetime of autoobjects.

Maybe you try to make the interface too abstract / too generic. The idea of the device class is to provide an interface to a dedicated device so that it can be accessed or controlled by the UI application. If the communication with the device is asynchronous, then the UI application sends a command or request to the device and later (when the device has returned the answer) the device class can send a System Event that indicates the completion or it can change a certain Property that contains the returned value.

If this seems not to be suitable for your application, can you please explain more details about your application and your device?

Best regards,

Manfred.

---

Hi Manfred,

We're building a platform that will be used to develop multiple instruments. At power-on, the software detects which boards are installed and adapts accordingly. Each board type has its own command set, so I am trying to build an interface for devices that is more general purpose/generic.

My hope is that I can pass to the driver a command to be sent (a command byte and a pointer to a data buffer) along with a function to call upon completion (either an Update for a property or a TriggerEvent function?). The callback function would decode and interpret the data it gets back.

It sounds as if this approach might not fit well with the Embedded Wizard framework. Do you have recommendations for an architecture that would prevent me from having to put too much knowledge into the driver? To expand on the idea I wrote about before, I could download information from the application to the device driver that would map each command to a callback function, so the application could adapt the device driver to different device types. Do you have other ideas I could consider?

Thanks again for your help!

Greg