Hi,
I got rti micro edition 2.2.3 which i use for a kernel task (build in static without -DRTI_RTP) and also for RTPs (build in dynamic with -DRTI_RTP).
If i launch all the RTPs first and then the kernel task, there is no more exchange (DDS) between all these processes (before kernel task, RTPs were communicating).
If i launch first the kernel task and then the RTPs, there is no issue (all communication are OK).
Investigating, i finally found that what makes the "mess", is the call in
OSAPI_System_initialize() which calls clock_settime(CLOCK_REALTIME, &init_time) in case of ! defined(RTI_RTP)
So, i made a test where i added RTI_RTP for the build of my static lib of rti.
And in this case, i have no issue.
So, could someone explain me, the concept and behaviour of this OSAPI_System.
What relation/ impact if initialized from a RTP or from the kernel ?
Also, could it be a problem to use rti me 2.2.3 both in kernel and in rtp ?
Is it possible to update the names of generated threads (udp_rx_mc, osapi_timer,...) because i got several processes using DDS from RTI so i have a list of plenty threads all named osapi_timer,udp_rx_mc.
Regards,
Rodolf
Hello Rodolf,
The call to clock_settime() is a bug in Micro when building Micro from source and running in VxWorks kernel mode that has been fixed for the next release. The reason for this statement was that for the VxWorks 5.5 kernel and board combo in our test lab the clock did not increment unless it was initialized to some value. However, the call to clock_settime() has been moved to the appropriate place in our test code instead of the Micro core libraries. The clock in question is used to drive the internal timers Micro use to maintain deadline, liveliness and other timing related statuses. The call to clock_settime() can safely be removed assuming that the clock is initialized elsewhere and is running. Running Micro in both kernel and RTP mode should not pose any problems.
Naming the threads so they are easier to distinguish is a good suggestion. We do have an improvement filed related to naming Linux threads and I'll add your request to this issue (MICRO-638).
regards,
tron