-
Notifications
You must be signed in to change notification settings - Fork 18
Description
Problem
Currently, our documentation site at https://oss-slu.github.io/Pi4Micronaut/ does not adequately describe what class types should be placed into the constructor for a controller.
For example, when creating a configuration for a component using the PWM protocol, the bean generated is of type Pwm. So the constructor of our DC Motor controller takes in @Named("motor") Pwm motor as an argument in its constructor.
Other components do not follow this pattern (which we might want to address in another issue as this is inconsistent...although this would break backwards compatibility). When creating an SPI configuration, the bean created is not of type Spi. Our RFID scanner controller takes in @Named("rfid") SpiConfig spi, Context pi4jContext as its arguments instead, as this is what is generated by the configuration.
What types are generated, and the discrepancy between how this is handled by different communication protocols, is not well described in our documentation. In fact, the diagram under the section "4.1.1. YAML Configuration Workflow" seems to suggest there is no discrepancy, and that the SPI configuration would produce an Spi object, which is not the case. The same is true of I2C.
Solution
- Recreate the diagram at "4.1.1. YAML Configuration Workflow" to show which classes are actually created by the beans
- Describe in text under each subsection of "4.1. Communicating with a Hardware Component" what beans are generated
- Include in each of those subsections a short code example of what the constructor for a controller for a hardware component using that communication protocol might look like. For example, as an example for the DigitalOutput protocol, we might include just a snippet that looks like
@Controller
public class ExampleController(@Named("example") DigitalOutput example) {Metadata
Metadata
Assignees
Labels
Type
Projects
Status