Template projects

[puddly]

It looks like we've come full circle 😄.

This PR replaces our in-tree projects with templates deriving from the SDK examples. It should remove fragile code to strip off board-specific project customizations. We create a temporary project based on the template, modify it, then generate a chip-specific one to finally build.

I've taken this opportunity to drop unused firmwares (multi-PAN, the firmware eraser, and Z-Wave) and rename existing ones:

• bootloader-uart-xmodem -> bootloader
• ot-rcp -> openthread_rcp
• ncp-uart-hw -> zigbee_ncp

Z-Wave has been upgraded to the Simplicity SDK.

---

For debugging, you can run the project builder with --no-clean-build-dir and import the project into Simplicity Studio. Change the project generator from "Makefile" to "Simplicity IDE Project", force generation, and then clean the project root.

[tube0013]

@puddly for every manifest will it need a corresponding .slcp? or can the .slcp be some what generic, just defining the components needed. and the manifest handling the settings and the board setup? though I do see some settings defined in the .slcp

[puddly]

@tube0013 The SLCPs are generic, you can see the source tree here: https://github.com/puddly/silabs-firmware-builder/tree/puddly/project-templates/src. The manifest is the same as before, just more settings moved into it: https://github.com/puddly/silabs-firmware-builder/blob/puddly/project-templates/manifests/nabucasa/skyconnect_zigbee_ncp.yaml

[tube0013]

Okay I think I understand now, this looks like it will make my builds a lot easier with the different radios. Now I just need to figure out how to make it work with a zigbee_minimal project and a zap config.

[puddly]

For the most part the SLCP templates are just the project SLCPs with chip components removed, nothing more. I think I can make this work with an in-tree project as well if you aren't going to use a template, so you can just commit your whole repo and it will build from the SS project itself, like before.

[tube0013]

I like this better. I don't want to use SS at all if possible😂

[Nerivec]

I'd prefer hw or sw (depending on the flow control) being present in the filename (and metadata). So it can finally be used for proper identification for the rtscts setting and avoid the confusion of the previous ncp-uart-hw.
The new generic names remove it entirely, which removes the previous issue for sure, but also removes the possibility for identification (better for users to associate it, I think, rather than have to guess or go through various docs to figure it out).

[puddly]

So it can finally be used for proper identification for the rtscts setting and avoid the confusion of the previous ncp-uart-hw.

When flashing, we always use software flow control, never hardware. This metadata isn't accessible from the application itself, or the bootloader. Do you rely on it beyond flashing?

[Nerivec]

I don't mean about flashing, I mean about the user being able to know what setting to use in their app of choice based on the firmware filename (quick identification) and metadata (can be processed by the flasher to tell the user, or at least logged).

[puddly]

What about a variant key in the GBL metadata that influences the filename? You could populate it relatively free-form, it'll be available to the flasher, and be easily identifiable if your firmware requires software flow control:

 name: SkyConnect Zigbee
 device: EFR32MG21A020F512IM32
 base_project: src/zigbee_ncp
+filename: "{manifest_name}_{ezsp_version}_{variant}"
 sdk: "gecko_sdk:4.4.4"
 toolchain: "12.2.1.20221205"
 
 gbl:
   fw_type: zigbee_ncp
+  variant: sw_flow
   dynamic: ["ezsp_version"]
   baudrate: 115200

This would produce skyconnect_zigbee_ncp_7.4.4.0_sw_flow.gbl

---

In the future, I'll add EXPECTED_FLOW_CONTROL as a custom XNCP command (once the PR is merged #57) and then have the firmware keep track of its expected flow control settings directly. This would let you log a warning if they don't match up.

I don't really think software flow control alone really warrants an entirely new firmware type if it's a single tweak to settings. Zigbee is the only firmware with it (for now).

[Nerivec]

What about a variant key in the GBL metadata

Agreed.
Having this as a separate key in the GBL metadata will allow identifying firmware file that support this and react to it in the flasher without clashing (old firmware files would all have hw in the filename, or even names that don't match the usual pattern, so can't use filename to detect anything properly).

In the future, I'll add EXPECTED_FLOW_CONTROL as a custom XNCP command

That will be specific to firmware using those commands though (obviously), but indeed a good one to have in that case.