You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/user-manual/design-patterns/rate-group.md
+3-29Lines changed: 3 additions & 29 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,41 +25,15 @@ system clock and the port call to rate group driver's `CycleIn` port.
25
25
The reference application calls the `CycleIn` port followed by a sleep for the system clock time within a while loop to
26
26
simulate a system-driven clock.
27
27
28
-
**_Example_**: Recall a crystal oscillator running at 1000 HZ (or 1 MHZ), then a system clock source would sample each 1MHZ. Recall that a `RateGroupDriver` is registered to this system clock source sampler that requires to be updated at a rate of 100HZ; therefore the following applies:
28
+
**_Example_**: Consider a crystal oscillator running at 1000 HZ (or 1 MHZ), then a system clock source would sample each 1MHZ. Recall that a `RateGroupDriver` is registered to this system clock source sampler that requires to be updated at a rate of 100HZ; therefore the following applies:
29
29
* On the API layers level, both drivers; the `SystemSourceDriver`, and the `RateGroupDriver` shall be implementations of F' components; thus they could only communicate via ports (e.g., commands, events, and telemetry channels). In this case, the implementation could be taken towards commanding.
30
30
* On the hardware level, the `SystemSourceDriver` shall use a clock divider that drives the `RateGroupDriver` each $$\frac{100HZ}{1MHZ}$$ of the system source sampler (i.e., at a rate of $$\frac{1}{10}$$ of the system source sampler).
31
31
* On the hardware implementation level, this could be done via many approaches; a counter algorithm (that triggers an interrupt when reaching 100 cycles resetting the `numberOfCycles` each second) can suffice or a more complex modular arithmetics algorithm could be used (e.g., $$((ticks\ mod\ rate)\ ==\ offset) \implies CycleOut$$; where `ticks` represents the current system virtual clocks, `rate` represents the `RateGroupDriver` required frequency, and `offset` represents the remainder of the value at which sampling shall occur when the system clock `ticks` reaches the requested `rate`; Zero `offset` means that the system source sampler will sample this driver when it reaches an integer multiple of its requested `rate`).
32
32
33
33
> [!NOTE]
34
34
> **Linking with the `Svc` core module:**
35
-
> * Here is an optimized simple algorithm utilized internally by `Svc::RateGroupDriver`; where values captured from this algorithm can be encapsulated further in a `Divider` structure.
36
-
> * This is essentially a variant of rate-controlled publish-subscriber pattern that samples the registered `RateGroupDriver` components by their requested sampling rate via their port channels:
> * Here is the simple algorithm of `Svc::RateGroupDriver` implemented by the core libraries; where values captured from this algorithm can be encapsulated further in a `Divider` structure.
36
+
> * This is essentially a variant of rate-controlled publish-subscriber pattern that samples the registered `RateGroupDriver` components by their requested sampling rate via their port channels: See [the Core Implementation `RateGroupDriver::CycleIn_handler(...)`](https://github.com/nasa/fprime/blob/devel/Svc/RateGroupDriver/RateGroupDriver.cpp).
63
37
> * The algorithm utilized here provides a software-based analogous activity to [the clock prescaler digital circuits](https://en.wikipedia.org/wiki/Prescaler).
0 commit comments