Scheduling a component faster than 1Hz

[ThibFrgsGmz]

Hello,

I'm trying to trigger a passive component at a frequency higher than 1Hz (let's say at 60 Hertz for example) but I'm having a lot of difficulties to do it.

Context

To do this I am inspired by the RPI demonstration available in the F´ project, but in the Topology.cpp I have trouble understanding how to interact with the different instances of the components in relation to scheduling.

I understood that it is done through the two instances: RateGroupDriver: and ActiveRateGroup:

• RateGroupDriver:

The instantiation of this class is done in the following manner in RPI for 10Hz and 1Hz:

// Rate Group Dividers for 10Hz and 1Hz
static NATIVE_INT_TYPE rgDivs[] = {1,10,0};
Svc::RateGroupDriverImpl rateGroupDriverComp("RGDRV",rgDivs,FW_NUM_ARRAY_ELEMENTS(rgDivs));

If I refer to @timcanham words about the RateGroupDriver instance in the fprime/Ref/Top/Topology.cpp:

The RateGroupDriver takes as input (CycleIn) some sort of periodic timing signal.

In the Ref example, the RateGroupDriver is driven by the notional driver "blockDrv", which has a 1Hz input (See Ref/Top/Topology.cpp).

Projects can use their own signal like a hardware interrupt to supply a timing signal. The table you mention for RateGroupDriver takes that input and divides down that primary input signal by the factor in entry in the table, and calls the corresponding output port at the new rate.

For the Ref example, the first port would be called at 1Hz/1 = 1Hz, the second at 1Hz/2 = 0.5Hz, and the third at 1Hz/4 = 0.25Hz.

So I understand that if we want to add a frequency of 60 Hz we have at least two possibilities:

1- Either enter a value so that 1Hz/x = 60Hz or x=1/60.
But the three values that we can give to this instance are of type NATIVE_INT_TYPE, i.e. an integer.
So it would seem impossible to program a frequency higher than 1Hz because the numerator is 1Hz.

2- Or modify the input frequency to 60Hz and put the value 1 in the first slot of RateGroupDriver.
But I don't see how to do it.

As the RPI tutorial would trigger a component at 1Hz or 10Hz, I think I have misunderstood something or I have missed some information.

I noticed that the RPI tutorial makes more use of ActiveRateGroup:

// Context array variables are passed to rate group members if needed to distinguish one call from another
// These context must match the rate group members connected in RPITopologyAi.xml
static NATIVE_UINT_TYPE rg10HzContext[] = {Rpi::CONTEXT_RPI_DEMO_10Hz,0,0,0,0,0,0,0,0};
Svc::ActiveRateGroupImpl rateGroup10HzComp("RG10Hz",rg10HzContext,FW_NUM_ARRAY_ELEMENTS(rg10HzContext));

static NATIVE_UINT_TYPE rg1HzContext[] = {0,0,Rpi::CONTEXT_RPI_DEMO_1Hz,0,0,0,0,0,0};
Svc::ActiveRateGroupImpl rateGroup1HzComp("RG1Hz",rg1HzContext,FW_NUM_ARRAY_ELEMENTS(rg1HzContext));

In fact it has been defined two enumerated types for rate group contexts in RPI/Top/RpiSchedContext:

    enum {
        CONTEXT_RPI_DEMO_1Hz = 10, // 10Hz cycle
        CONTEXT_RPI_DEMO_10Hz = 11 // 1 Hz cycle
    };

At the moment I'm still struggling to realize the potential of contexts by reading the RPI code but I don't have the impression that this is what makes 10Hz possible.

Question

Could you detail the process to program the triggering of a specific component at a frequency higher than 1Hz please?

---

Maybe the explanations could be used to feed the Rate Groups and Timeliness presentation in the F´ documentation which has been in TODO for a while.

[EbenezerA99]

Hi!

You are right about #2 "Or modify the input frequency to 60Hz and put the value 1 in the first slot of RateGroupDriver." - i think that would be the easiest way.

The Rate Group Driver's CycleIn is triggered via the LinuxTimer. To set the frequency that the LinuxTimer invokes a port call to the RateGroupDriver, adjust this argument in the linuxTimer.startTimer() in main.cpp see here

I believe the argument is an integer that represents the number of miiliseconds between invoking a call to the RateGroupDriver. After you set this to the desired value, you could keep the first index of the rgDivs at 1.

Ebenezer Arunkumar
Georgia Institute of Technology ’23
BS Aerospace Engineering / Minor in Computational Data Analysis
MS Aerospace Engineering

[ThibFrgsGmz]

Thank you @EbenezerA99 for your answer! Indeed you are right. I wrote my follow-up in the answer to @timcanham just below.

[timcanham]

If you look here:

https://github.com/nasa/fprime/blob/devel/RPI/Top/Main.cpp#L57

The Linux timer will drive the RateGroupDriver at 10 Hz with this line:

linuxTimer.startTimer(100); 

i.e. every 100ms.

If you want to drive the RateGroupDriver's fundamental tick at higher rate, lower this parameter. Then use the table to divide that frequency down to slower ones for other rate groups. Granted, 60Hz isn't an even number of milliseconds, but I don't know how important 60Hz exactly is.

[ThibFrgsGmz]

Thanks @timcanham, I managed to operate a 60Hz scheduling, since I start from Ref deployment and not from RPI I can't directly implement the same approach as RPI deployment for this Timer stuff.

To do this I have reduced the delay time for triggering a cycle to 16ms in the Ref/Top/Main.cpp:

void run1cycle(void) {
    // call interrupt to emulate a clock
    blockDrv.callIsr();
    Os::Task::delay(16); //60Hz
}

I then configured my RateGroupDriver as follows:

static NATIVE_INT_TYPE rgDivs[Svc::RateGroupDriverImpl::DIVIDER_SIZE] = {60,1,0};
Svc::RateGroupDriverImpl rateGroupDriverComp(FW_OPTIONAL_NAME("RGDvr"),rgDivs,FW_NUM_ARRAY_ELEMENTS(rgDivs));

Note: what is better to do between increasing the number of dividers in the RateGroupDriver instance or creating another RateGroupDriver instance?

And with the following rate groups:

One at 1Hz in order to keep the rate of the components inherited from the Ref deployment:

static NATIVE_UINT_TYPE rg1Context[] = {PoC::REF_SCHED_CONTEXT_RATE_GROUP_1Hz,0,0,0,0,0,0,0,0};
Svc::ActiveRateGroupImpl rateGroup1Comp(FW_OPTIONAL_NAME("RG1"),rg1Context,FW_NUM_ARRAY_ELEMENTS(rg1Context));

And another one at 60Hz on which I connected my component that should be clocked at 60Hz:

static NATIVE_UINT_TYPE rg2Context[] = {0,0,PoC::REF_SCHED_CONTEXT_RATE_GROUP_60Hz,0,0,0,0,0,0};
Svc::ActiveRateGroupImpl rateGroup2Comp(FW_OPTIONAL_NAME("RG2"),rg2Context,FW_NUM_ARRAY_ELEMENTS(rg2Context));

In the Top/RefTopologyAppAi.xml I connect my component to the second Rate Group. I put the port number 2 of this RateGroup even if any port allows to clock at 60Hz.

    <connection name = "RGOhTempAcq60Hz">
         <source component = "rateGroup2Comp" port = "RateGroupMemberOut" type = "Sched" num = "2"/>
         <target component = "OHTempAcqProcComp" port = "Run" type = "Sched" num = "0"/>
    </connection>

I can visually see that my component is being triggered at high speed, I'm having trouble seeing how to elegantly interact with the ConsoleTextLoggerImpl class to display the messages formatted with the TextLogger_handler method and thus with the datations between each component trigger.

So I calculate the time between two triggers with the traditional technique, I get 0.000154 second but if I put the component back on the RG1 at 1Hz I get 0.00099 second and visually the logs arrive well each seconds, I guess I have a conversion error somewhere.

The 60Hz is not critical in my mockup, if it is a real time critical application it would most likely require an external hardware signal.

PS: why is the timing implementation method different between RPI deployment and Ref deployment?

[timcanham]

Your setup looks good to me, but I'm not sure I understand your question about the ConsoleTextLogger.

Question 1: What is better to do between increasing the number of dividers in the RateGroupDriver instance or creating another RateGroupDriver instance?

Answer: There is no requirement to use a single RateGroupDriver to drive multiple rate groups. They are components, so you can mix and match them in a way that makes sense. We did a single one in the Ref app to illustrate how you could drive multiple rate groups from a single timing source.

Question 2: Why is the timing implementation method different between RPI deployment and Ref deployment?

The Ref deployment is supposed to be more universal, i.e. you could run it on embedded if you like for a demo before tying it to an interrupt. The "timerfd" library is available on the RPI version of Linux, but not on all versions of Linux. The "timerfd" approach gives more precise timer ticks, whereas the task delay method is not precise because each cycle you are actually delaying the delay time plus the time it takes to execute the cycle before delaying again. That causes the cycle to "walk" in time. That's good enough for a demo, but for a particular embedded application you very likely want to tie it to a timer interrupt to keep the cycle time consistent.

[ThibFrgsGmz]

Thanks!
My question about the ConsoleTextLogger comes from the fact that I want to log a simple message in the following standard format (appearing in https://github.com/nasa/fprime/blob/devel/Svc/PassiveConsoleTextLogger/ConsoleTextLoggerImplCommon.cpp#L46):

Fw::Logger::logMsg("EVENT: (%d) (%d:%d,%d) %s: %s\n",
        id, timeTag.getTimeBase(), timeTag.getSeconds(), timeTag.getUSeconds(),
        reinterpret_cast<POINTER_CAST>(severityString), reinterpret_cast<POINTER_CAST>(text.toChar()));

But going through the ConsoleTextLoggerImpl component with the TextLogger_handler method in order to do things correctly so that there is no heterogeneity in the code and have the same way of displaying the logs.

And have the same kind of messages (especially for the timetag that is included) that we have by default at the start of the application in the console:

EVENT: (121) (2:1631114601,891232) DIAGNOSTIC: (CMDDISP) OpCodeRegistered : Opcode 0x021D registered to port 4 slot 0

As I didn't succeed after 15mn I finally went through a simple cout<< (I didn't spend more time on it as it wasn't the most important).

I may try again later in the week to search more precisely.

But maybe you have some leads for me?

Hovering the code, I have the impression that a port must be used to interact with this log component.
What bothers me is that in flight configuration, this connection will have to be removed because there will be no console, so doing this for each component wanting to log (for simulation/dev/debug configuration) is complicated.

[timcanham]

The TextLogger port is automatically used by the component when you define events in your component. You aren't expected to use it directly. If you don't have a console, you can leave it unconnected. You can also write your own component to route the text somewhere else if you like.