Hacker Diary: Embedded World 2022

Yesterday I went up to the Embedded World trade fair in Nuremburg, Germany. As a lone hacker, you often feel more than a little out of place when you buy chips in single unit quantities and the people you’re talking to are used to minimum order quantities of a million. But what’s heartening is how, once you ask an interesting question, even some of the suit-wearing types flip into full-on kids who like to explain the fun tech. I struck up conversations with more than a couple VPs of global chip behemoths, and they were cool.

But my heart is still with the smaller players, and the hackers. That’s where the innovation is. I met up with Colin O’Flynn, of Chip Whisperer fame — his company is selling fancier chip-glitching tools, but he still had a refined version of the open source, quick-and-dirty zapper circuit from his Remoticon talk last year. There was a small local company producing virtual buttons that were essentially Pepper’s Ghost illusions floating in mid-air, and the button press was detected by reflective IR. Cool tech, but I forgot the company’s name — sorry!

Less forgettable was Dracula Technologies, a French company making inkjet-printable organic solar cells. While they wouldn’t go into deep details about the actual chemistry of what they’re doing, I could tell that it pained them to not tell me when I asked. Anyway, it’s a cool low-power solar tech that would be awesome if it were more widespread. I think they’re just one of many firms in this area; keep your eyes on organic solar.

When talking with a smaller German FPGA manufacturer, Cologne Chip, about their business, I finally asked about the synthesis flow and was happily surprised to hear that they were dedicated to the fully open-source Yosys toolchain. As far as I know, they’re one of the only firms who have voluntarily submitted their chips’ specs to the effort. Very cool! (And a sign of things to come? You can always hope.)

I met a more than a few Hackaday readers just by randomly stumbling around, which also shows that the hacker spirit is alive in companies big and small. All of the companies have to make demos to attract our attention, but from talking to the people who make them, they have just as much fun building them as you or I would.

And last but not least, I ran into Hackaday regular Chris Gammell and my old boss and good friend Mike Szczys who were there representing the IoT startup Golioth, and trying to fool me into using an RTOS on microcontrollers. (Never say never.) We had an awesome walkaround and a great dinner.

If you ever get the chance to go to a trade show like this, even if you feel like you might be out of your league, I encourage you to attend anyway. You’d be surprised how many cool geeks are hiding in the least likely of places.

[Banner image: Embedded World]

Old Firewall Reborn As Retro PC

We like projects where old gear is given a new life. [Splashdust] has a twenty-year old business firewall that’s build like a tank. He cracks it open and finds a complete x86 embedded motherboard inside, and sets off to restore it and turn it into a retro gaming computer (see the video from his Odd & Obsolete YouTube channel below the break).

This business firewall and router box is from a small Swedish firm Clavister, part of their S-Series from the early 2000s. The motherboard appears to be a generic one used in other equipment, and is powered by a VIA Eden ESP 4000 running at 400 MHz. The Eden line of x86 processors were low-power chips targeting embedded applications. The graphics chip is a Twister T by S3 Graphics which was purchased by VIA in 2000. After replacing the electrolytic capacitors, and making a few cables, [Splashdust] pops in a PCI sound card and boots up into Windows 98 from a CF card (we like the compact PCB vise he uses).

In two follow-up videos (here and here), he builds an enclosure (instructions on Thingiverse) and tries out several other operating systems. He was able to get the Tiny Core Linux distribution running with the NetSurf browser, but failed to get Windows 2000 or XP to work. Returning to Windows 98, he tweaks drivers and settings and eventually has a respectable retro-gaming computer for his efforts. The next time you’re cleaning out your junk bins, have a peek inside those pizza-box gadgets first — you may find a similar gem.

Continue reading “Old Firewall Reborn As Retro PC”

Adafruit AVRProg Grows UPDI Interface Support

Making a small number of things with an embedded application is pretty straightforward, you usually simply plug in a programmer or debugger dongle (such as an AVRISP2) into your board with an appropriate adaptor cable, load your code into whatever IDE tool is appropriate for the device and hit the program button. But when you scale up a bit to hundreds or thousands of units, this way of working just won’t cut it. Add in any functional or defect-oriented testing you need, and you’re going to need a custom programming rig.

Adafruit have a fair bit of experience with building embedded boards and dealing with the appropriate testing and programming, and now they’ve updated their AVR Programming library to support the latest devices which have moved to the UPDI (Unified Programming and Debug Interface) programming interface. UPDI is a single-wire bidirectional asynchronous serial interface which enables programming and debugging of embedded applications on slew of the new AVR branded devices from Microchip. An example would be the AVR128DAxx which this scribe has been tinkering with lately because it is cheap, has excellent capacitive touch support, and is available in a prototype-friendly 28-pin SOIC package, making it easy peasy to solder.

The library is intended for use with the Arduino platform, so it should run on a vast array of hardware, without any special requirements, so making a custom programming jig out of hardware lots of us have lying around is not a huge hassle.

Adafruit provide a few application examples in the project GitHub to get you going, such as this ATTiny817 example that wipes the flash memory, sets appropriate fuses and drops in a bootloader.

The UPDI code was taken from the [brandanlane’s] portaprog which is hosted on the TTGO T-Display ESP32 board from Chinese outfit LilyGo, which is also worth checking out.

A little while ago we saw how the AVR Multitool, the AVRGPP learned to speak UPDI, and since we’re on programming interfaces, its possible to get the cheap-as-chips USBasp to speak TPI as well.

Continue reading “Adafruit AVRProg Grows UPDI Interface Support”

Interconnected CPU nodes forming a system-wide network

With Luos Rapid Embedded Deployment Is Simplified

Those of us tasked with developing firmware for embedded systems have a quite a few hurdles to jump through compared to those writing for the desktop or mobile platforms. Solved problems such as code reuse or portability are simply harder. It was with considerable interest that we learnt of another approach to hardware abstraction, called Luos, which describes itself as micro-services for embedded systems.

This open source project enables deployment of distributed architectures composed of collaborating micro-services. By containerizing applications and hardware drivers, interfaces to the various components are hidden behind a consistent API. It doesn’t even matter where a resource is located, multiple services may be running on the same microcontroller, or separate ones, yet they can communicate in the same way.

By following hardware and software design rules, it’s possible to create an architecture of cooperating computing units, that’s completely agnostic of the actual hardware. Microcontrollers talk at the hardware level with a pair of bidirectional signals, so the hardware cost is very low. It even integrates with ROS, so making robots is even easier.

Luos architecture

By integrating a special block referred to as a Gate, it is possible to connect to the architecture in real-time from a host computer via USB, WiFi, or serial port, and stream data out,  feed data in, or deploy new software. The host software stack is based around Python, running under Jupyter Notebook, which we absolutely love.

Current compatibility is with many STM32 and ATSAM21 micros, so chances are good you can use it with whatever you have lying around, but more platforms are promised for the future.

Now yes, we’re aware of CMSIS, and the idea of Hardware Abstraction Layers (HALs) used as part of the platform-specific software kits, this is nothing new. But, different platforms work quite differently, and porting code from one to another, just because you can no longer get your preferred microcontroller any more, is a real drag we could all do without, so why not go clone the GitHub and have a look for yourselves?

Continue reading “With Luos Rapid Embedded Deployment Is Simplified”

Embedded Rust Hack Chat

Join us on Wednesday, May 12 at noon Pacific for the Embedded Rust Hack Chat with James Munns!

Programming languages, like fashion, are very much a matter of personal taste. Professional developers often don’t have much say in which language they’ll use for a given project, either for legacy or team reasons, but if they did have a choice, they’d probably choose the language that works best with the way they think. Some languages just “fit” different brains better than others, and when everything is in sync between language and developer, code just seems to flow effortlessly through the keyboard and onto the screen.

One language that consistently scores at the top of developers’ “most loved” lists is Rust. For a language that started as a personal project and has only existed for a little more than a decade, that’s really saying something. The emphasis Rust puts on safety and performance probably has a lot to do with that. And thanks to its safe concurrency, its memory safety, and its interoperability with C and other languages, Rust has made considerable in-roads with the embedded development community.

To learn more about Rust in embedded systems, James Munns will stop by the Hack Chat. James is an embedded systems engineer, with a history of working on software for a wide range of systems, including safety-critical avionics, and rapidly prototyped IoT systems. He’s a founding member of the Rust Embedded Working Group, as well as a founder of Ferrous Systems, a consultancy focused on systems development in Rust, with a specialty in embedded systems development. James also used to write for Hackaday, so he must be a pretty cool guy. So swing by the Hack Chat and find out where Rust might be able to help you out with your next embedded project.

join-hack-chatOur Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, May 12 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.

Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
Continue reading “Embedded Rust Hack Chat”

DOOM On A Bootloader Is The Ultimate Cheat Code

Porting DOOM to run on hardware never meant to run it is a tradition as old as time. Getting it to run on embedded devices, ancient computers, virtual computers, and antique video game consoles are all classic hacks, but what DOOM ports have been waiting for is something with universal applicability that don’t need a bespoke solution for each piece of hardware. Something like DOOM running within a bootloader.

The bootloader that [Ahmad] works with is called Barebox and is focused on embedded systems, often those running Linux. This is the perfect environment for direct hardware access, since the bootloader doubles as a bare metal hardware bring-up toolkit. Now that DOOM runs on this bootloader, it effectively can run anywhere from embedded devices to laptops with minimal work, and although running it in a bootloader takes away a lot of the hard work that would normally need to be done during a port, it may still need some tweaking for specific hardware not otherwise supported.

For those already running Barebox, the bareDOOM code can be found on [Ahmad]’s GitHub page. For those not running Barebox, it does have a number of benefits compared to other bootloaders, even apart from its new ability to play classic FPS games. For those who prefer a more custom DOOM setup, though, we are always fans of DOOM running within an NES cartridge.

Photo: AntonioMDA, CC BY-SA 4.0 via Wikimedia Commons


Real-Time OS Basics: Picking The Right RTOS When You Need One

When do you need to use a real-time operating system (RTOS) for an embedded project? What does it bring to the table, and what are the costs? Fortunately there are strict technical definitions, which can also help one figure out whether an RTOS is the right choice for a project.

The “real-time” part of the name namely covers the basic premise of an RTOS: the guarantee that certain types of operations will complete within a predefined, deterministic time span. Within “real time” we find distinct categories: hard, firm, and soft real-time, with increasingly less severe penalties for missing the deadline. As an example of a hard real-time scenario, imagine a system where the embedded controller has to respond to incoming sensor data within a specific timespan. If the consequence of missing such a deadline will break downstream components of the system, figuratively or literally, the deadline is hard.

In comparison soft real-time would be the kind of operation where it would be great if the controller responded within this timespan, but if it takes a bit longer, it would be totally fine, too. Some operating systems are capable of hard real-time, whereas others are not. This is mostly a factor of their fundamental design, especially the scheduler.

In this article we’ll take a look at a variety of operating systems, to see where they fit into these definitions, and when you’d want to use them in a project. Continue reading “Real-Time OS Basics: Picking The Right RTOS When You Need One”