workflows adjustments?

[pdgilbert]

If I had understood workflows I would have activated it on my own fork before making a pull request. I think my pull request is now going to cause a workflows run on michaelbeaumont:main every time I push to my fork. So here is the status and what I think may be a problem:

-I have fixed the rustfmt and some of the clippy problems. The remaining problem is that clippy cannot be run with --all-features because only one MCU can be specified. I think the solution to this is to modify the ci.yaml file by adding a strategy.matrix and adjust the clippy arg:

strategy:
  matrix:
    mcu: [stm32f042, stm32f103, stm32f401, stm32f411]  #plus others if this works
    dht: [dht11, dht22]
...
      - uses: actions-rs/cargo@v1
        with:
          command: clippy
          args: --features ${{ matrix.mcu }},${{ matrix.dht }} -- -D warnings

• The package job needs an mcu specified as a feature:

cargo package   --features stm32f042

otherwise there is an error no 'InputPin' in 'digital::v2' . I think this is because the trait does not get resolved without a package that the feature pulls in (but I'm just guessing).

• The build_and_test job step Build also cannot be run with --all-features because only one MCU can be specified.

cargo build --release  --features stm32f042

I have now activated workflows on my fork and will momentarily push the changes to my code and the ci.yaml file. If that activates a workflow job on michaelbeaumont:main then that job may not allow me to specify a new ci.yaml file. (It could be considered a security risk, or it could be well sandboxed.)

The strategy.matrix could also be applied in the package and build_and_test jobs, but I will start slowly. (I'm doing this with just a couple of hours crash study of workflows). Please let me know if you know a better solution.

[pdgilbert]

(Just to wrap up.) I now have workflows working on my fork with the example dht-multi-hals. Results are available at https://github.com/pdgilbert/dht-sensor/actions. The workflow report summary gives a quick indication of what MCUs build and should load with the dht-sensor crate. At present, the crate builds and should load with MCUs stm32f042, stm32f103, stm32f100, stm32f101, stm32f303xc, stm32f401, stm32f411, stm32l100, and stm32l151. I had to remove testing of stm32f030xc and stm32l0x2 because the binary is too large for flash even in --release mode. Also, I had to remove stm32h742 because hal stm32h7xx is not building. These results are based on released versions of hals. Results based on git versions of the hals are reported at https://pdgilbert.github.io/eg_stm_hal/ (example dht).

Actual tests running the example on hardware have been done and work on a bluepill (stm32f103), and blackpills with stm32f401, and stm32f411. As reported in #4 I currently have run time problems on discovery-stm32f303 and discovery-stm32l100.

[pdgilbert]

(update) I merged fix with overflow, switched the stm32f303xc example to use a different delay function, and found a breadboard wiring error the may have affect some tests. The example code in my dht-sensor fork has now been tested to run with both DHT11 and DHT22 on bluepill (stm32f103), blackpill-stm32f401, blackpill-stm32f411, discovery-stm32f303, discovery-stm32l100 and heltec-lora-node151 (stm32l151).