A screenshot of the release page, showing the headline and a crop of the release notes

MicroPython 1.23 Brings Custom USB Devices, OpenAMP, Much More

MicroPython is a wonderful Python interpreter that runs on many higher-end microcontrollers, from ESP8266 to STM32 to the RP2040. MicroPython lets you build devices quickly, and its latest release, 1.23, brings a number of improvements you should be aware of.

The first one is custom USB device support, and it’s a big one. Do you want to build HID devices, or play with MIDI, or do multiple serial streams with help of PIO? Now MicroPython lets you easily create USB devices on a variety of levels, from friendly wrappers for creating HID or MIDI devices, to low-level hooks to let you define your own USB descriptors, with user-friendly libraries to help all the way through. Currently, SAMD and RP2040 ports are supported in this part of code, but you can expect more in the future.

Hooray to 10 years of MicroPython!

There’s more – support for OpenAMP, an inter-core communication protocol, has received a ton of improvements for systems where MicroPython reigns supreme on some of the CPU cores but also communicates with different systems on other cores. A number of improvements have made their way through the codebase, highlighting things we didn’t know MicroPython could do – for instance, did you know that there’s a WebAssembly port in the interpreter, letting you run MicroPython in your browser?

Well, it’s got a significant overhaul in this release, so there’s no better time to check it out than now! Library structure has been refactored to improve CPython compatibility, the RP2040 port receives a 10% performance boost thanks to core improvements, and touches upon areas like PIO and SPI interfaces.

We applaud all contributors involved on this release. MicroPython is now a decade old as of May 3rd, and it keeps trucking on, having firmly earned its place in the hacker ecosystem. If you’ve been playing with MicroPython, remember that there are multiple IDEs, graphics libraries, and you can bring your C code with you!

Use That One Port For High-Speed FPGA Data Export

There’s a good few options for exporting data out of FPGAs, like Ethernet, USB2, or USB3. Many FPGAs have a HDMI (or rather, sparkling DVI) port as well, and [Steve Markgraf] brings us the hsdaoh project — High-Speed Data Acquisition Over HDMI, using USB3 capture cards based on the Macrosilicon MS2130 chipset to get the data from the FPGA right to your PC.

Current FPGA-side implementation is designed for Sipeed Tang chips and the GOWIN toolchain, but it should be portable to an open-source toolchain in the future. Make sure you’re using a USB3 capture card with a MS2130 chipset, load the test code into your FPGA, run the userspace capture side, and you’re ready to add this interface to your FPGA project! It’s well worth it, too – during testing, [Steve] has got data transfer speeds up to 180 MB/s, without the USB3 complexity.

As a test, [Steve] shows us an RX-only SDR project using this interface, with respectable amounts of bandwidth. The presentation goes a fair bit into the low-level details of the protocol, from HDMI fundamentals, to manipulating the MS2130 registers in a way that disables all video conversion; do watch the recording, or at least skim the slides! Oh, and if you don’t own a capture card yet, you really should, as it makes for a wonderful Raspberry Pi hacking companion in times of need.

Schematic of the Pi Pico wireup, showing the various outputs that the firmware will generate on the GPIOs

A Scope Test Tool You Can Build With Just A Pico

Ever wanted to see how well your oscilloscope adheres to its stated capabilities? What if you buy a new scope and need a quick way to test it lest one of its channels its broken, like [Paul Wasserman] had happen to him? Now you only need a Pi Pico and a few extra components to make a scope test board with a large variety of signals it can output, thanks to [Paul]’s Sig Gen Pi Pico firmware.

description of the signals generated by the software, that can be read in detail on the project websiteDespite the name it’s not a signal generator as we know it, as it’s not flexible in the signals it generates. Instead, it creates a dozen signals at more or less the same time — from square waves of various frequencies and duty cycles, to a PWM-driven DAC driving eight different waveforms, to Manchester-encoded data I2C/SPI/UART transfers for all your protocol decoder testing.

Everything is open source under the BSD 3-Clause license, and there’s even two PDFs with documentation and a user manual, not to mention the waveform screenshots for your own reference.

It’s seriously impressive how many features [Paul] has fit into a single firmware. Thanks to his work, whenever you have some test equipment in need of being tested, just grab your Pico and a few passive components.

So What’s All This HaLow Long-Range WiFi About Then?

We’re all used to wireless networking, but if there’s one thing the ubiquitous WiFi on 2.4 or 5 GHz lacks, it’s range. Inside buildings, it will be stopped in its tracks by anything more than a mediocre wall, and outside, it can be difficult to connect at any useful rate more than a few tens of metres away without resorting to directional antennas and hope. Technologies such as LoRa provide a much longer range at the expense of minuscule bandwidth, but beyond that, there has been little joy. As [Andreas Spiess] points out in a recent video though, this is about to change, as devices using the so-called HaLow or IEEE 802.11ah protocol are starting to edge into the realm of affordability.

Perhaps surprisingly, he finds the 5 GHz variant to be best over a 1km test with a far higher bandwidth. However, we’d say that his use of directional antennas is something of a cheat. Where it does come into its own in his tests, though, is through masonry, with far better penetration across floors of a building. We think that this will translate to better outdoor performance when the line of sight is obstructed.

There’s one more thing he brings to our attention, which seasoned users of LoRA may already be aware of. These lower frequency allocations are different between the USA and Europe, so should you order one for yourself, it would make sense to ensure you have the appropriate model for your continent. Otherwise, we look forward to more HaLow devices appearing and the price falling even further because we think this will lead to some good work in future projects.

Continue reading “So What’s All This HaLow Long-Range WiFi About Then?”

The film scanner [xssfox] found, in the center of a table, with other stuff strewn across the table

Answering All Your ISCSI Scanner Questions

iSCSI is a widely used protocol for exposing SCSI devices over a network connection, and some scanners have in the past been equipped with SCSI ports. So, could you have an iSCSI network scanner? [xssfox] details her journey making a Canoscan FS4000US film scanner work over iSCSI, sparked by someone’s overly-confident StackOverflow comment that it couldn’t be done. Nothing in the spec said it couldn’t actually work, however, and after figuring out a tentative architecture, a hardware setup was put together.

No flatbed scanners with SCSI ports could be found on the cheap, so a film scanner had to be procured. After figuring out a few hitches with the loading mechanism and getting a test image locally, it was time to try and build up the software setup, tearing through SCSI compatibility and cabling, driver and PCI pass-through woes, bluescreens, and intermediate software having dropped some of the necessary features by now. Still, [xssfox] eventually exported the scanner as an iSCSI target – and, on the other end of the network, successfully connected to it and completed a scan. The StackOverflow answer was wrong, after all.

It’s fun to see how far old technology can go, and get answers to questions you never knew you had. Whether you’re reminiscing about SCSI days or wondering what the technology about, we’ve talked about it aplenty, from a retrospective to modern-day experiments, repurposing old SCSI hardware for modern SATA ports, a Raspberry Pi implementation, an emulator, and a fair bit more.

We thank [Valentijn Sessink] and [adistuder] for sharing this with us!

Two pictures of the same black dog, wearing two separate pairs of the AR glasses reviewed in these two articles

A Master-Class On Reverse-Engineering Six AR Glasses

Augmented reality (AR) tech is getting more and more powerful, the glasses themselves are getting sleeker and prettier, and at some point, hackers have to conquer this frontier and extract as much as possible. [Void Computing] is writing an open source SDK for making use of AR glasses, and, along the way, they’ve brought us two wonderful blog posts filled with technical information laid out in a fun to read way. The first article is titled “AR glasses USB protocols: the Good, the Bad and the Ugly”, and the second one follows as “the Worse, the Better and the Prettier”.

Have you ever wanted to learn how AR glasses and similar devices work, what’s their internal structure, which ones are designed well and which ones maybe not so much? These two posts have concise explanations, more than plenty of diagrams, six case studies of different pairs of AR glasses on the market, each pair demonstrated by our hacker’s canine assistant.

[Void Computing] goes in-depth on this tech — you will witness MCU firmware reverse-engineering, HID packet captures, a quick refresher on the USB-C DisplayPort altmode, hexdumps aplenty, and a reminder on often forgotten tools of the trade like Cunningham’s law.

If reverse-engineering lights your fire, these high-level retrospectives will teach you viable ways to reverse-engineer devices in your own life, and they certainly set a high bar for posts as far as write-ups go. Having read through these posts, one can’t help but think that some sort of AR glasses protocol standard is called for here, but fortunately, it appears like [Void Computing]’s SDK is the next best thing, and their mission to seize the good aspects of a tentative cyberpunk future is looking to be a success. We’ve started talking about AR glasses over a decade ago, and it’s reassuring to see hackers catching up on this technology’s advancements.

We thank [adistuder] for sharing this with us on the Hackaday Discord server!

The Minimalistic Dillo Web Browser Is Back

Over the decades web browsers have changed from the fairly lightweight and nimble HTML document viewers of the 1990s to today’s top-heavy browsers that struggle to run on a system with less than a quad-core, multi-GHz CPU and gigabytes of RAM. All but a few, that is.

Dillo is one of a small number of browsers that requires only a minimum of system resources and will happily run on an Intel 486 or thereabouts. Sadly, the project more or less ended back in 2016 when the rendering engine’s developer passed away, but with the recent 3.10 release the project seems to be back on track, courtesy of efforts by [Rodrigo Arias Mallo].

Although a number of forks were started after the Dillo project ground to a halt, of these only Dillo+ appears to be active at this point in time, making this project revival a welcome boost, as is its porting to Atari systems. As for Dillo’s feature set, it boasts support for a range of protocols, including Gopher, HTTP(S), Gemini, and FTP via extensions. It supports HTML 4.01 and some HTML 5, along with CSS 2.1 and some CSS 3 features, and of course no JavaScript.

On today’s JS-crazed web this means access can be somewhat limited, but maybe it will promote websites to have a no-JS fallback for the Dillo users. The source code and releases can be obtained from the GitHub project page, with contributions to the project gracefully accepted.

Thanks to [Prof. Dr. Feinfinger] for the tip.