Today was a fairly mixed day, split between rearranging some upcoming development work, tidying up the electronics development pipeline, and starting work on a small authentication API that I expect to reuse across several future projects.

One consequence of reviewing the hardware pipeline was deciding to halt development of the USB-C Shield.

Pruning the Development Pipeline#

The USB-C Shield was originally developed largely as a test case while I was exploring EasyEDA rather than KiCad. It served that purpose well, but looking at it again as a potential Protoworks product, it doesn’t really make much sense to continue developing it at the moment.

There are already plenty of similar devices available on the market, and the board doesn’t add enough unique value to the catalogue to justify spending more development time on it.

Because it was also designed in EasyEDA, bringing it properly into the current development workflow would mean recreating or migrating the design into KiCad, reviewing it again, and preparing another manufacturing run.

Given everything else currently in the pipeline, that time is better spent elsewhere.

That doesn’t mean the idea is permanently dead. If I have a particular need for the device in future, or find a good reason to revisit it, it would be relatively straightforward to recreate the board in KiCad and send it off for manufacture.

For now, though, it has done its job as an experiment and doesn’t need to become a physical product.

A Better UCMOD Naming Scheme#

The second change was to the naming convention used for the UCMOD modules.

The original ATtiny-based module was called UCMOD-0, but it was becoming increasingly obvious that simply numbering modules as UCMOD-0, UCMOD-1, UCMOD-2 and so on would become unclear fairly quickly as the range expanded.

Instead, I’ve switched to product codes that say something useful about the module itself.

The current modules are now:

  • UCMOD-S-ATT — the small-format ATtiny-based UCMOD module.
  • UCMOD-L-STM32 — the larger-format STM32-based UCMOD module.
  • UCMOD-S-CH32 — a small-format module based around the CH32V006 microcontroller.

The first part after UCMOD describes the general module format:

  • S — small format.
  • L — large format.

The final part identifies the microcontroller family used by the module.

This seems considerably more useful than a sequential numbering system. A developer can get a reasonable idea of what a module is simply from its product code, while the exact microcontroller and capabilities can still be documented in the individual product specification.

It’s only a naming change, but it’s the sort of thing that is much easier to fix now than after there are ten or twenty different modules in the range.

A Small Authentication API#

I also started work on a small authentication API that will issue JSON Web Tokens (JWTs) when valid credentials are supplied.

The API is intended primarily for internal projects, including the inventory management system I’ve recently started working on, and gives me a common authentication service that can be reused rather than implementing the same functionality separately in every application.

Like the inventory API, it is being built as a C# Minimal API using .NET 10, Entity Framework Core, and PostgreSQL.

I’m also using BCrypt.Net-Next for password hashing and Otp.NET to provide optional TOTP authentication — the same general type of time-based one-time code used by applications such as Google Authenticator and 1Password.

The API will issue JWTs signed using HMAC-SHA256, allowing services that share the signing secret to verify that a token was issued by the authentication service and has not been modified.

The intention isn’t to build a general-purpose identity platform.

There are already mature systems such as Keycloak, Microsoft Entra ID, and Auth0 for applications that need full identity management, federation, external identity providers, enterprise authentication, and all the other features that come with a more complete identity platform.

For the projects I currently have planned, bringing in something of that scale would add a lot of functionality and complexity that I simply don’t need. What I want is a small authentication component that I understand completely, can run alongside my own services, and can reuse wherever a straightforward username, password, TOTP and token-based authentication flow is sufficient.

I’m deliberately keeping the API surface small and focused on a handful of responsibilities:

  • authenticating a username and password;
  • optionally validating a TOTP one-time code;
  • issuing JWT access tokens;
  • issuing and managing refresh tokens.

That’s really all I need for the projects I currently have planned.

I don’t need SAML, federation, enterprise identity providers, or most of the other functionality found in larger authentication platforms. If that changes in future I can reassess it, but for now a small, self-contained authentication service should be a good fit.

WCH-LinkE on the Way#

Finally, I ordered a WCH-LinkE programmer for working with the CH32V006 and other WCH microcontrollers.

That should be arriving shortly and will give me the programming and debugging hardware I need for experimenting with the CH32V006 before the UCMOD-S-CH32 boards are eventually sent off for manufacture.

So although today wasn’t dominated by a single hardware build or debugging session, it was still useful progress: removing something from the development pipeline that no longer justified the time, putting a more scalable naming convention in place for UCMOD, and laying some of the software groundwork for upcoming projects.