Open bgamari opened 10 years ago
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)
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?
An alternative to platformtree
Imagine there existed a trait,
and a syntax extension providing an attribute (let's call it
compile_time
) which given a type definition derived an appropriate instance. For example,Finally, we'll want a function,
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.
where peripheral bindings would register with
use
with an interface like,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
Pin
s 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,
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.