Skip to content

Need documentation for what types to take into controller constructorΒ #434

@leandrumartin

Description

@leandrumartin

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

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Type

    Projects

    Status

    πŸ”– Ready

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions