Greg Steiert @steieio@qoto.org

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.

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

Ever wonder how to program an FPGA through an MCU?

That is what I showed people how to do in my workshop at @crowdsupply Teardown 2024. The participants didn't even need to install any software as the method emulates a USB thumb drive for drag-n-drop programming.

If you are interested in how this works or where I got the idea, I will be speaking with @helenleigh in a Teardown Session on YouTube at noon Pacific Time on December 5th.
https://www.youtube.com/watch?v=Ns5RiT4F2Mw

I'll talk about where I got the idea, and how a failed first attempt lead to an even better solution. Along the way, I'll cover some of the various methods for loading an FPGA and their tradeoffs and other background details. This will also touch on my favorite UF2 file format.

Let me know in the comments if there is something specific you wold like me to cover.

The instructions and code from the workshop are available on GitHub if you want to try it yourself:
https://github.com/gsteiert/pico-dirty-blaster-workshop

A few lucky viewers of the live-stream will get a workshop kit including the MAX10 FPGA based 10M08 Evaluation Kit courtesy of Altera.

#FPGA #microcontroller

Did you ever wonder how much current you can draw from the energy harvested output of an NFC EEPROM? I did, and I built a board to measure it.

The ST25DV and NXP NTAG I2C PLUS are designed for the same antenna loading so I was able to design a board that would support both devices. The results were a little surprising. The NXP NTAG I2C PLUS does a much better job regulating the output voltage. The ST25DV starts at about 4V with no load, and drops off rather quickly. I could draw almost 5mA before dropping below the 2.7V minimum voltage of the WCH32V003 with the NT3H2211, but less than 4mA from the ST25DV. Based on this data, I switched my beeping, blinking business-card designs to the NT3H2211.

Learn more about the project on Hackaday:
https://hackaday.io/project/177897-beeping-blinking-business-card-badge-b4/log/221646-power-estimates

Happy Halloween