Enable microsecond timing

[nateinaction]

Description

This PR enables microsecond timing, up from millisecond timing.

I've been working with timing in the 10ms range and it's a little odd to have only 1ms resolution when timing is slipping around. I'd like to increase the system clock resolution to microseconds to match FPrime's expectations.

Zephyr docs describe k_uptime_ticks() as

the fundamental unit of resolution of kernel timekeeping.

Additionally I have been running with the CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000000 config setting for a few days on the detumble branch and anecdotally the system is less likely to experience a rate group slip.

Example call added to the ADCS run handler:

Fw::Time t = this->getTime();
Fw::Logger::log("ADCS Run Handler invoked at time: %u sec, %u usec\n", t.getSeconds(), t.getUSeconds());

Pre-change output:

[Os::Console] ADCS Run Handler invoked at time: 1767160726 sec, 661000 usec

Post-change output:

[Os::Console] ADCS Run Handler invoked at time: 1767160433 sec, 658244 usec

RP2350 Clock Capable of Microsecond Timing

The Zephyr system clock uses an external crystal oscillator running at $12MHz$ and is checked by the system clock running at $150MHz$. We can see in the device tree that the crystal oscillator is defined as node xosc and that the system clock (clk_sys) references xosc via the pll_sys clock definition. We can validate this on the running system with:

#include <zephyr/sys/printk.h>
#include <zephyr/device.h>
#include <zephyr/drivers/clock_control.h>
#include <zephyr/dt-bindings/clock/rpi_pico_rp2350_clock.h>

const struct device *clocks = DEVICE_DT_GET(DT_NODELABEL(clocks));

uint32_t rate;
clock_control_get_rate(clocks,
                       (clock_control_subsys_t)RPI_PICO_CLKID_CLK_SYS,
                       &rate);
printk("System clock rate: %u Hz\n", rate);

Where we see the output:

System clock rate: 150000000 Hz

Given that the crystal oscillator is expected to run at $12MHz$ we know that we have $10^{-8}$ precision in the clock and this PR sets the tick precision within that range since microseconds are $10^{-6}$.

References

• 8.1.2.3 Crystal Oscillator - RP2350 Datasheet
• Crystal Oscillator (XOSC) Definition - Zephry RP2350 Device Tree
• System Clock Definition - Zephyr RP2350 Device Tree
• pll_sys Definition in the Zephyr Device Tree

k_uptime_get() Already Derived From Ticks

Calling k_uptime_ticks() reduces the call stack when getting time because the call to k_uptime_get() derives millisecond timing return value from k_uptime_ticks().

Zephyr Microsecond Default

Zephyr defaults to $10000\ Ticks / s$ for most devices.

How Has This Been Tested?

• Unit tests
• Integration tests
• Z Tests
• Manual testing (describe steps)

[LeStarch]

A note about why this will take a lot of testing to qualify.

[LeStarch]

This change will have a massive effect on the system. It will change interrupt timings, thread switching timings, and any other timings defined by the system. It will also increase overhead of kernel operations (context switching, etc) because these will happen more often.

Ticks represent the minimum time quantum that the kernel can detect and act on. We currently use 10000. This increases that value by 100x.

[nateinaction]

Ah, thank you for this clarification. I thought the objection was around changing the Zephyr call from k_uptime_get() to k_uptime_ticks(). Agreed this is worth looking into.