Idea for static configuration

[bgamari]

An alternative to platformtree

Imagine there existed a trait,

trait CompileTime {
    pub fn to_compile_time(tt: TokenTree) -> Self;
}

and a syntax extension providing an attribute (let's call it compile_time) which given a type definition derived an appropriate instance. For example,

#[compile_time]
enum Port { PortA, PortB }

#[compile_time]
struct Pin {
    pub block: Port,
    pub pin_n: uint,
}

#[compile_time]
struct SpiParams {
    pub speed: uint,
    pub phase: Level,
    pub polarity: Level,
    pub clk: Pin
    pub mosi: Pin
    pub miso: Pin
}

#[compile_time]
enum Level {High, Low}

Finally, we'll want a function,

fn to_compile_time<T: CompileTime>(tt: TokenTree) -> T

At this point we have something that could be used for compile-time specification of configuration. The nice thing about this is that we've punted all of the details of parsing to a reusable component (compile_time). In fact, with CTFE this component may almost disappear entirely. Moreover, we would benefit from any tooling support the user might have due to the use of standard Rust syntax.

All the device bindings need to worry about is a typical Rust struct. For instance you might have a syntax extension which handles peripheral instantiation, e.g.

#[use(SPI0)]
const Spi0 = SpiParams {
      speed: 100000,
      phase: High,
      polarity: Low,
      clk: Pin(PortA, 1),
      mosi: Pin(PortA, 2),
      miso: Pin(PortA, 3),
}

where peripheral bindings would register with use with an interface like,

pub fn register<Config: CompileTime>(instantiate: |Config| -> Result<TokenTree>);

Dealing with dependencies

One issue brought up by @farcaller is that of dependencies. Currently Platform Tree deals with this by encoding them in its tree structure.

This obviously won't work in the above proposal. In the case of simple dependencies we can encode these as fields as we did with the Pins above. But what if we have an open universe of potential dependents?

Say we have an I2C device (say, for instance, an ADC). Its configuration might look like this,

#[compile_time]
struct I2cAdc {
    addr: I2cAddress,
    resolution: AdcResolution,
    bus: &I2cBus,
}

Here we have encoded the device's dependency on its bus as a reference. The binding would then be free to call something like needs(self.bus) to ensure that its bus is initialized before it attempts to initialize itself.

[farcaller]

This replaces the parts of PT that do node -> instance conversion alongside with appropriate validations. It doesn't seem to handle the dependencies, right? And you'll still have the suffering of passing down any typed arguments down to task entry points (the #[zinc_task] thing)

[bgamari]

Correct, this focuses on the parsing side of the problem. I haven't pondered how the resulting configuration might be passed to the user at runtime. I haven't had much experience in this area but at first glance your approach of generating structs and passing them to user tasks seems quite workable. What has been the trouble with this approach in your experience?