STM32 Hotspot, a new GitHub for unofficial projects

[Peter BENSCH]

ST is unveiling STM32 Hotspot on GitHub, which comprises repositories developed by ST employees for demos or example features that are not part of the official ST GitHub page or the traditional STM32Cube ecosystem on ST.com.

Developers now have access to more code examples to help them implement a significantly broader range of new functionalities. There are 27 repositories today, with more on the way. All projects comply with standard ST licensing rules, meaning that any developers can reuse our source code on an STM32 project without worrying about copyright restrictions or copyleft regulations that would compromise commercial projects. Moreover, while STM32 Hotspot doesn’t accept third-party submissions, we strongly encourage forking or cloning projects locally and customizing them.

The official ST GitHub vs. STM32 Hotspot

Why is the official ST GitHub so popular?

Most STM32 developers are already familiar with ST’s official GitHub page. It contains more than 450 repositories, from standard STM32Cube MCU packages for all current STM32 microcontroller series to expansion packages for specific applications. For instance, ST published four machine learning programs last year on the official GitHub channel. It ensured developers could reduce their time to market when using our sensors and our code for movement recognition. Similarly, ST released its X-CUBE-AZRTOS on GitHub last April to hasten developments on Azure RTOS. The code serves as implementation examples for features like FileX, ThreadX, or USBX, among others.

Why did so many users want an STM32 Hotspot?

All projects on the official ST GitHub page undergo rigorous inspection and receive extensive support. However, the projects on the official ST GitHub are just a fraction of what our prolific employees come up with. Regional offices and many of our divisions write applications for trade shows or to meet a customer’s demand. Many teams conceive small validation programs or test applications showcasing specific features. However, ST developers don’t share them because they were never meant to go through official distribution channels. The STM32 Hotspot solves this by opening a new avenue for innovation and creativity. By providing projects as-is, authors don’t have to commit as much to specific programs, and users get more code to assist them.

STM32 Hotspot is also a direct answer to the many people that reach out to our teams during trade shows or through the course of normal operations to request that we share our smaller projects. The new GitHub page is thus a hub between ST engineers and our community.

...read on...

[waclawek.jan]

Reinventing the wheel is easy and you can invent a wheel to exactly fit your purpose. OTOH the wheels in offerings are just a glittery accessory to a vehicle designed primarily to prevent you to step out of it.

But as I've said, as long as it's just code and discussion to that code, github is OK-ish.

Also, read last sentence of my post. Yes, that's the thing. Face it.

This repository is publishing existing work of ST employees done for some particular purpose - to support a wealthy customer or to test internally some feature. It's a byproduct (not that it's bad, it's far far better than nothing of course). It's provided as-is. It's not intended as a starting point for some further development based on discussion. Read Peter's original post above, carefully.

> Indeed, STM should allocate some resources to manage these repositories.

I would be glad if they would not. Resources are scarce and it's us who pay for them.

I would rather like ST allocating resources to write proper examples (yes, no Cube and "libraries" and any of that garbege) and proper application notes (dozens per peripheral). That is, to lay out solid foundations, finally.

JW

[Pavel A.]

Hi Jan,

I agree with what you said about dispersion. The "discussions" on github are mostly about the code in the repositories (reviews, pull requests, etc.) but they also have a tickets/bugs tracking and some project management tools (projects, canban boards, and integration with Microsoft world (Azure Devops, nee Team Foundation Server), CodeSpaces and other scary stuff.

Why I proposed to use github for the newsletter or magazine: the previous issues posted by STOne are formatted document files - PDFs or PPS. Git of course is not intended for storing binaries, but people use github for this and it works.

It can serve rendered PDFs (view in browser) and html, and finally, github.io is a platform (yes) for publishing documents and blogs.

If we can get used to this forum, we'll get used to github too.

Again, as the experience taught, dealing with Microsoft is scary but so is most of the world these days ((

[Pavel A.]

@Danish​ Re. the GPL concerns: the readme specially says: "All the source code published in these repositories is delivered by ST under business-friendly licensing terms".