cargo embassy init generates invalid project if chip name is incorrect

[Luctins]

After running cargo embassy init <project_name> --chip STM32H563ZITx, the generated project doesn't contain the embassy_stm32 dependency with the chip passed from command line as as a feature, so it fails to compile.

❯ cargo embassy init test_project --chip STM32H563ZITx
  Finished in 17s
❯ cd test_project
❯ cargo b
error: failed to parse manifest at `<redacted>/test_project/Cargo.toml`

Caused by:
  feature `debug` includes `embassy-stm32/defmt`, but `embassy-stm32` is not a dependency

Tested using cargo-embassy v0.2.1 installed with cargo install.

[AdinAck]

This is because your chip identifier includes the package type at the end, Tx. The chip identifier you provide should be in the form of what embassy expects for the chip feature.

Would be nice if cargo embassy had some kind of warning about this instead of silently failing...

[Luctins]

Updated the title to reflect the actual issue. Also tested without the Tx and indeed it works.

Is there a logical place we could check for this? I would be interested in trying to fix this.

[AdinAck]

Any help would be much appreciated!

What I believe is happening is the chip identifier is parsed and passed to embassy as a feature here, which of course is not a valid feature so the cargo add fails.

I guess the simplest option would be to report when these subroutines fail, and the cherry on top would be to add a convenience message explaining that the reason it failed was because of the invalid feature.

[Luctins]

That seems like a good place to start, I'll open a PR when possible.