Greg Steiert @steieio@qoto.org

The simplicity of USB from a user perspective is built on complexity for developers.

Creating a universal, plug-and-pray interface is inherently complicated. The USB standard is very tedious and every implementation is a little different, so developers need to learn the nuance of the hardware they are using. The vendor libraries help, but they are often bloated, and never portable. This is why TinyUSB and TinyUF2 are two of my favorite open-source projects.

TinyUSB is an open-source, cross-platform USB stack. It is designed to be compact and memory-safe for embedded applications. It supports over 100 boards from more than a dozen MCU vendors. This is a huge advantage for code portability.
https://github.com/hathach/tinyusb

This code portability is likely why @adafruit uses it for TinyUF2 and CircuitPython. TinyUF2 builds a drag-n-drop UF2 bootloader with TinyUSB for a growing list of microcontroller platforms.
https://github.com/adafruit/tinyuf2

Creating cross-platform projects like TinyUSB and TinyUF2 requires a high-quality, well-planned build environment. The portability forces them to be command line based, so they cannot use the crutch of graphical IDEs.

I think these projects are great for intermediate-beginner developers to help them learn good practices early. The code portability also provides a wide array of low-cost supported hardware. The hardest part may be choosing which board to get.

https://docs.tinyusb.org/en/latest/reference/boards.html

@piggo @arturo182 that's the definition I've always used, but I can understand that it may evolve. "Classic Rock" is probably even harder to define.

@arturo182 scary that 90/00 are now considered "oldies"

@misty it's almost hard to believe how useless Google search has become

Why is it so hard to find a good multimeter?
Phrased differently…
Why aren’t there more open source multimeter projects?

Fortunately, John Duffy is working to fix that. I have to applaud his motivation and initiative to create a project like this and make it open source. I agree that digital interfaces are not as common as they should be, and even when they are physically available, the software to make use of them is typically abysmal. The meter I’ve had since college, pictured below, is one such example.

Open source is a perfect match for test and measurement. Every application is a little different and being able to customize interfaces (software or electrical) can have a significant impact. This is why I often find a small development board more useful than a fixed function piece of test equipment.

I particularly like the fact that he is designing this to be modular, so it is easy to extend and upgrade. Modularity combined with open source are probably two of the best ways to accelerate the advancement of a new project.

I encourage everyone to check out the project. I will be following this closely.
Github: https://github.com/jduffy105/HydraMeter_0.4
Hackaday: https://hackaday.io/project/176607-hydrameter
YouTube: https://www.youtube.com/watch?v=JMexSal01gQ

Merry Christmas

Grok is a better syntax reference than Google.
When writing code, I used to google terms to figure out the proper syntax, but recently I started using Grok instead. I’m finding Grok is much more efficient.
With Google, I would follow a link to a reference and read through it to find the details I needed. Grok summarizes the details for me. I was a little skeptical at first and would check the links to make sure it interpreted them correctly. So far, I have been pleasantly surprised.
I am particularly impressed that it can even assist with more esoteric and complicated languages like Verilog for FPGAs. These do not have as many online resources as other languages and the vendor documentation leaves a lot to be desired. Even so, Grok was able to provide details on the synthesis directives I was looking for, including how to apply them in the source code or the constraint files.
I’m not sure I am ready to let Grok write my code yet, but it is certainly a powerful tool that will help me be more effective.

Open source is often misunderstood.
Hear @olofk provide a great explanation. Including the subtle differences between open source software, hardware, and silicon.
https://open.spotify.com/episode/44ypT98vIwNe0XpaF2QlpI?si=RSW-oxi_RLiLf0CJmcqcRg

@pmdj @funkylab @osmocom @LaF0rge There is no issue with IOUSBLib, except that it is different than LInux, Windows and Android. The problem is that you have to develop a custom application on every platform you want to support. You are lucky if you get a DFU app for Windows and Linux. It is rare to see support for macOS let alone Android or ChromeOS.

@funkylab @osmocom @LaF0rge UF2 does not rely on the OS sending everything in order. Every packet includes the destination address so they can be sent in any order, as long as every packet is sent. I know Adafruit's TinyUF2 tolerates that, but I'm not sure the RP2040 ROM implemented that based on my experience concatenating data to a firmware image.

@funkylab @osmocom @LaF0rge I agree CDC is another easy to use USB profile supported by most operating systems.

@funkylab @osmocom @LaF0rge I agree CDC is another easy to use USB profile supported by most operating systems.

@funkylab @osmocom @LaF0rge I would argue that macOS and Android are even worse than Microsoft (iOS is fundamentally broken). It is very difficult to build an accessible platform agnostic solution with DFU. USB MSC can even work with Android or ChromeOS. That opens up cheap hardware that you could put in a middle school classroom.

@piggo @funkylab I agree with the fragility of the mbed implementation, and so did Michal Moksal who came up with UF2. He came up with some clever ways to get the data through in spite of the OS. His blog post "One chip to flash them all" describes the motivation and method: https://makecode.com/blog/one-chip-to-flash-them-all

@funkylab Great question. DFU was intended for this but everyone implements it differently and the drivers are not built into operating systems by default, so you need to write a custom application and build it for every operating system you want to support. MSC (Mass Storage Class) used by USB drives is supported in everything (even Android) without a custom app. The blog post I linked to explains why they developed UF2 at Microsoft

UF2 works for data too.

The USB Flashing Format (UF2) was developed as a way to update firmware on microcontrollers, but it works equally well for data. Let’s look at how and why you might want to do that using the real world application of loading an FPGA.

The great thing about UF2 is that it emulates a USB thumb drive so images can be transferred by dragging and dropping the properly formatted file using the drivers that are standard in every operating system. The key is the specially formulated packets that you can read about in this blog:
https://makecode.com/blog/one-chip-to-flash-them-all
I also spoke about it at Crowd Supply Teardown 2023:
https://www.youtube.com/watch?v=AdoWZkSSaoA

While primarily created for firmware updates, it can transfer data just as easily. In the case of loading an FPGA, the firmware that loads the image into the FPGA does not need to change for each new image. One way to transfer the data is to convert the image to a C array and build it with the firmware, but that would require rebuilding the firmware for every new image which is not necessary. Instead of converting the image to a C array, you can convert it to UF2 packets so that it can be loaded directly into flash without rebuilding.

I did just this when I ported Altera’s JBC player code to the Raspberry Pi Pico board. The RP2040 implements a UF2 bootloader in its ROM, and the SDK produces a UF2 file when building the code. The same bootloader can be used to load an FPGA JBC image into the flash by converting the file to UF2 packets with the uf2conv utility.

The JBC player firmware needs to know where the JBC FPGA image is located, and the size. To make sure the firmware is compatible with the image, and make it easier to use, I decided to combine the firmware UF2 image with the JBC UF2 image. I created a custom UF2 converter that would take the firmware output from the RP2040 SDK, add a 256byte header with the JBC image size, and append the JBC image.

The header is 256 bytes to fill one UF2 block, so I added some additional information such as a description of the image. The output is a combined file similar to if you had included the JBC file as a C array, but in this case, to replace the JBC image, you do not need to have the RP2040 SDK installed, you only need to run a Python script.

You can learn more about the process and some quirks with the RP2040 ROM UF2 implementation in this Crowd Supply Teardown Session:
https://www.youtube.com/watch?v=Ns5RiT4F2Mw

The code is available on GitHub:
https://github.com/steieio/jbcuf2
And I used it in a workshop at Crowd Supply Teardown 2024:
https://github.com/gsteiert/pico-dirty-blaster-workshop