Oftentimes, we’ll find ourselves using an PC attached to a project for serial debugging. Other times, we’ll be squinting at a status LED trying to remember the flash code we invented. This embedded dashboard from [hgrodriguez] aims to land somewhere in the middle.
The dashboard features LEDs, several 5×7 matrix displays, and will also mount a small OLED display as well. Everything onboard is driven by an ItsyBitsy board, featuring an Atmega32u4 microcontroller. Data can be fed to the ItsyBitsy via UART, SPI, or eventually, I2C as well.
With the ItsyBitsy handling actually driving the various displays, your project only need send out debug data over one of the listed interfaces. The ItsyBitsy will then display your byte values or word values on the matrix displays, flash the LEDs as required, and so on.
The result is a useful little console that can show you what’s going on in the brain of your microcontroller project. It’s no substitute for a full serial terminal, but it could definitely come in handy when you need to get eyes on a few variables in RAM!
By today’s standards, the necessities for running a Linux-based operating system are surprisingly meagre in terms of RAM and processor power. Back in the day we ran earlier Linux versions on Intel 386 and 486 machines with tiny quantities of memory compared to the multi-gigabyte many-core powerhouses we do today.
So it stands to reason that many of the more powerful microcontrollers should also run Linux, but of course they are often unable because the lack a memory management unit. The original ESP32 is just such a candidate, plenty of power but unable to run Linux. Not so fast, because [Dror Gluska] has managed to boot a Linux kernel on Espressif’s dual-core chip. How on earth? By emulating a RISC-V processor on it and booting a RISC-V version of the kernel.
The emulator in question is [Fabrice Belard]’s TinyEMU, a piece of software that brings both RISC-V and x86 to limited-spec platforms, and the write-up describes the extensive optimization and tracing of ESP32 bottlenecks which was finally able to get a Linux kernel booting in 1 minute and 35 seconds. Of course it’s simply an exercise to prove it can be done and we won’t be seeing Linux-based ESP projects any time soon, but it’s still an impressive piece of work.
[Gregory] had a TV that didn’t support automatically turning on when the power was applied. This is frustrating when you like to leave devices switched hard off when not in use to save on standby energy draw. Thus, there needed to be a way to send the screen an on signal when his multi-monitor setup was powered on.
A simple circuit paired with a Pi Pico was pressed into service. The Pico flashes an IR LED, squirting out the requisite code to tell the TCL branded TV to switch on. [Gregory] figured out the codes by using an Arduino to read the output of the TV’s remote with an IR sensor. The hook here is the code is written in MicroPython, using IR libraries from [Peter Hinch].
Now, when [Gregory] powers up his rig, the IR sender will trigger the TV to switch on. It’s a little frustrating that the auto-on function wasn’t available in the factory, but regardless, now everything’s working as it should. If you want to do this in reverse, consider building a TV-B-Gone or a silencer for the boomboxes used by dancing grandmas!
[Dan Julio]’s gCore (short for Gadget Core) is aimed at making GUI-based portable and rechargeable gadgets much easier to develop. gCore is the result of [Dan]’s own need for a less tiresome way to develop such hardware.
A touchscreen is great, but high-quality power control and charging features are what really make a portable device sing.
[Dan] found that he seemed to always be hacking a lot of extra circuitry into development boards just to get decent power management and charge control. To solve this, he designed his own common hardware platform for portable gadgets and the gCore was born.
While the color touchscreen is an eye-catching and useful addition, the real star of his design is the power management and charging features. Unlike most development hardware, the gCore intelligently shares load power with charging power. Power on and power off are also all under software control.
Sound intriguing? That’s not all the gCore has to offer, and you can learn more from the project page at hackaday.io (which has a more in-depth discussion of the design decisions and concept.) There are also some additional photos and details on [Dan]’s website.
[Dan] is no stranger to developing hardware. The tcam-mini thermal imager (and much more) is his work, and we have no doubt the gCore’s design and features are informed directly by [Dan]’s actual, practical development needs.
[Kevin O’Connor] writes to us about his project, can2040 – adding CAN support to the RP2040. The RP2040 doesn’t have a CAN peripheral, but [Kevin] wrote code for the RP2040’s PIO engine that can receive and send CAN packets. Now we can all benefit from his work by using this openly available CAN driver. This library is written in C, so it’s a good fit for the lower-level hackers among us, and in all likelihood, it wouldn’t be hard to make a MicroPython wrapper around it.
The CAN bus needs a peripheral for the messages to be handled properly, and people have been using external chips for this purpose until now. These chips, [Kevin] tells us, have lately been unavailable due to the chip shortage, making this project more valuable. The documentation is extensive and accessible, and [Kevin] details how to best use this driver. With such a tool in hand, you can now turn your Pico into a CAN tinkering toolkit, or wire up some CAN devices for use in your own projects!
While the rest of the world’s hacker camps shut their doors through the pandemic there was one which managed through a combination of careful planning and strict observation of social distancing to keep going. The Danish hacker community gather every August for BornHack, a small and laid-back event in a forest on the isle of Fyn that has us coming back for more every year. They always have an interesting badge thanks to the designs of [Thomas Flummer], and this year looks to be no exception as they’ve dropped some details of the upcoming badge.
In short, it’s a beautifully designed hand-held games console with a colour screen, powered by the ubiquitous-in-the-chip-shortage RP2040 microcontroller. On board are the usual interfaces and a prototyping area plus CircuitPython for easy coding, and we expect it to sprout some addictive and playable gaming action. It’s the sort of PCB that we could imagine coming as a product from the likes of Pimoroni, but for now the only way to get your hands on one is to go to the event. We’ll being you a review when we have one. Meanwhile you can take a look at a previous year’s badge.
Over the years we’ve covered many projects aimed at detecting elevated radiation levels, and a fair number of them have been Internet connected in some way. But as they are often built around the Soviet-era SBM-20 Geiger–Müller tube, these devices have generally adhered to a fairly conservative design. With the current situation in Europe heightening concerns over potential radiation exposure, [g3gg0] thought it was a good a time as any to revisit the idea of an Internet-connected Geiger counter using more modern components.
Now to be clear, even this modernized approach still makes use of that same SBM-20 tube. There’s such an incredible wealth of information floating around out there about how to work with them that you’d almost put yourself at a disadvantage to chose something else to base your design on. Put simply, it’s hard to go wrong with a classic.
An unfortunate bug was discovered in the HV circuit.
That said, [g3gg0] decided early on that the design would use as many SMD components as possible, a considerable departure from many of the SBM-20 counters we’ve seen. That meant coming up with a new high-voltage power supply capable of providing the tube with the necessary 400 V, which from the sound of things, took a few attempts to complete. The final result is perhaps the smallest and cleanest looking board we’ve ever seen play host to this particular tube.
To run the show, [g3gg0] selected the ESP32-PICO-D4. You certainly don’t need such a powerful microcontroller to read the impulses from the SBM-20 tube and publish them via MQTT, but to be fair, the chip has a number of other duties. It’s handling the WS2812 RGB LEDs that go off in response to detected particles, running the (apparently optional) 2.9 inch WaveShare electronic paper display, and also pulling data from a BME280 environmental sensor as well as a CCS811 VOC sensor — so it’s keeping fairly busy.
As impressive as this build is, we do hate that it had to be built. From certain world leaders dropping casual comments about the strength of their nuclear arsenal to foolhardy attempts to capture the Chernobyl power station, having access to a reliable Geiger counter isn’t an unreasonable precaution right now. For everyone’s sake, let’s hope the fancy RGB LEDs on this particular build remain as dark as possible.
