On Mon, Sep 20, 2010 at 10:34 PM, Sagar Behere <sagar [dot] behere [..] ...> wrote:
> Hi Peter,
>
> There is a problem with the suggested approach.
>
> On 09/15/2010 03:29 PM, Peter Soetens wrote:
>
>> You're pretty close to what you need. Take this snippet as an inspiration:
>>
>>

>> #include<boost/bind.hpp>
>> using namespace boost;
>>
>>   class Component : public TaskContext {
>>     void process_gps_data( GPSData* data ) {
>>           // make a copy of 'data', ...
>>            // finally, wake up component:
>>            this->trigger();
>>    }
>>    void updateHook() {
>>           // process data received from process_gps_data
>>           // ...
>>           // finally, trigger a new read: (see boost::bind for syntax
>> examples)
>>           getGpsData(..., bind(&Component::process_gps_data, this, _1) );
>>    }
>> };
>> 

Oh yeah, I had seen that coming, but I was hoping your lib had a
STL-ish API that accepted function objects too :-]

We once had this problem with a CAN driver, exactly the same
situation. What we did was to create
a 'static' lookup table in the component class and let each instance
of the component register itself
in that std::map/vector/list... Then a static callback is registered
with the getGpsData function, which
has access to this lookup table and calls an object function for each
instance with a pointer to the new data.

Like this:

class GPSComponent : public TaskContext {
public:
   GPSComponent(...) ... {
       instances.push_back(this);
   }
   static vector<GPSComponent*> instances;
   static process_gps_data(GPSData * gd) {
        for(vector<GPSComponent::iterator it =instances.begin(); it !=
instances.end; ++it)
             (*it)->newGPSData(gd);
   }
   void newGPSData(GPSData* gd) {
         // copy gd to local instance data
         // maybe only the last component in 'instances' sends a new trigger
         // it depends...
   }
};
<code>
You could also codify a singleton, or assign gps devices to different
instances etc
(we had one component for each CAN channel for example).
It's mostly a C++ problem, due to the fact that Orocos components
might run in the
same process, which excludes a singleton solution in case of multiple
gps devices
(only makes sense in redundancy setups...).
 
I don't think there's another solution than something similar as the above.
 
Peter
-- 
Orocos-Users mailing list
Orocos-Users [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users

Hi again,

The following approach compiled. [Can't test it yet, since I'm coding
from home and the embedded development kit is back in the office]. But
I'd like your comments anyway :)

----in file gps.cpp----

#include "gps.hpp"

using namespace RTT;

gps *temp_gps_pointer = NULL;

gps::gps(std::string name, std::string propertyfilename):
TaskContext(name)
{
temp_gps_pointer = this;
}

void gpsDataCallback (gpsData *data)
{
//do stuff with data using temp_gps_pointer to get into gps
//TaskContext
temp_gps_pointer->getActivity()->trigger();
}

void gps::updateHook(void)
{
// process data received from process_gps_data
// ...
getGpsData(gpsDataCallback);
}

---end of gps.cpp contents---

Regards,
Sagar

On 09/20/2010 10:34 PM, Sagar Behere wrote:
> Hi Peter,
>
> There is a problem with the suggested approach.
>
> On 09/15/2010 03:29 PM, Peter Soetens wrote:
>
>> You're pretty close to what you need. Take this snippet as an
>> inspiration:
>>
>>

>> #include<boost/bind.hpp>
>> using namespace boost;
>>
>> class Component : public TaskContext {
>> void process_gps_data( GPSData* data ) {
>> // make a copy of 'data', ...
>> // finally, wake up component:
>> this->trigger();
>> }
>> void updateHook() {
>> // process data received from process_gps_data
>> // ...
>> // finally, trigger a new read: (see boost::bind for syntax examples)
>> getGpsData(..., bind(&Component::process_gps_data, this, _1) );
>> }
>> };
>> 

On Thursday 16 September 2010 11:02:52 Sagar Behere wrote:
> Hi,
>
> Thanks, this makes sense. I need two more clarifications.
>
> >> getGpsData() doesn't block.. so how/when exactly will process_gps_data()
> >> be executed?
> >
> > Your library will determine that moment, so you must assume that
> > process_gps_data may not modify data shared with other threads, or the
> > TaskContext's updateHook()
> >
> >> The library will try to execute it as soon as there is some
> >> data available from the GPS device, but orocos might be executing a
> >> different TC at that time (this shouldn't even be possible on a
> >> uniprocessor system).
> >
> > It is possible, since the scheduler may interrupt your threads at any
> > time to execute another thread.
>
> Assume the functions & callback of this library are defined and executed
> in TC A. updateHook() of TC A calls the getGpsData() function, thus
> registering the callback. getGpsData() is non-blocking() and returns
> immediately and TC A finishes executing. Then TC B starts execution and
> the GPS device receives data. What happens? Is TC B stopped and
> callback() in TC A executed? Does TC B continue executing and the
> callback function executed whenever TC A gets its chance to execute? Are
> there any rules to specify what should happen?

All thread scheduling is done by the Linux/Windows/Mac-OS-X/... schedulers.
There is one thread for each component (the default setting), and as such the
mapping thread <-> updateHook() is 1:1. So for your specific case:
1. GPS data is received
2. B's thread is preempted (stopped temporarily) by the callback
3. A is trigger() 'ed by the callback
4.a If A's thread has a higher priority, A's updateHook will run, when it
finishes, B's updateHook will continue OR
4.b If B's thread has a higher priority, B's updateHook will continue first and
when it's done, A's updateHook will be executed.

I'm not describing 'Orocos' scheduling here. I'm describing what the
Linux/Xenomai/... schedulers would do.

>
> >> So when exactly will that function be executed?
> >>
> >> Is there a better way to use a library function which needs a callback
> >> to be registered?
> >
> > You're pretty close to what you need. Take this snippet as an
> > inspiration:
> >
> >

> > #include<boost/bind.hpp>
> > using namespace boost;
> >
> >    class Component : public TaskContext {
> >      void process_gps_data( GPSData* data ) {
> > 	   // make a copy of 'data', ...
> >             // finally, wake up component:
> >             this->trigger();
> >     }
> >     void updateHook() {
> >            // process data received from process_gps_data
> 
> [really basic question :( ] So the copy of the data that
> process_gps_data() makes is used by the TC's updateHook(). But above,
> you said that process_gps_data() may not modify data shared with the
> TC's updateHook(). I didn't understand why you said that, since this
> code makes sense.
 
I meant, we copy the data to a safe place, like a DataObject<GPDData>, OR, we 
put a MutexLock around it (RTT::os namespace), ie typical critical section 
protection. 
 
Normally, Orocos users don't need to care that much about critical sections, 
because the copying is done between components, but when you're using an 
external library which calls you back, you almost always need a mutex or some 
safe-copy container like DataObject.
 
> 
> >            // ...
> >            // finally, trigger a new read: (see boost::bind for syntax
> > examples) getGpsData(..., bind(&Component::process_gps_data, this, _1) );
> 
> Right! And I guess I don't have to call this function here if I tell the
> library "Call the callback() everytime you get data" ( which is also
> possible. )
 
Exactly.
 
Peter