A Deep Dive On Battery Life

There are all kinds of old wives’ tales surrounding proper battery use floating around in the popular culture. Things like needing to fully discharge a battery every so often, unplugging devices when they’re fully charged, or keeping batteries in the fridge are all examples that have some kernel of truth to them but often are improperly applied. If you really want to know the truth about a specific battery, its behavior, and its features, it helps to dig in and actually take some measurements directly like [Tyler] has done with a vast array of embedded batteries in IoT devices.

[Tyler] is a firmware engineer by trade, so he is deeply familiar with this type of small battery. Battery performance can change dramatically under all kinds of scenarios, most important among them being temperature. But even the same type of battery can behave differently to others that are otherwise identical, which is why it’s important to have metrics for the batteries themselves and be able to measure them to identify behaviors and possible problems. [Tyler] has a system of best practices in place for monitoring battery performance, especially after things like firmware upgrades since small software changes can often have a decent impact on battery performance.

While working with huge fleets of devices, [Tyler] outlines plenty of methods for working with batteries, deploying them, and making sure they’re working well for customers. A lot of it is extremely useful for other engineers looking to develop large-scale products like this but it’s also good knowledge to have for those of us rolling out our own one-off projects that will operate under battery power. After all, not caring for one’s lithium batteries can have disastrous consequences.

How Hardware Testing Got Plugged Into A Continuous Integration Framework

The concept of Continuous Integration (CI) is a powerful tool in software development, and it’s not every day we get a look at how someone integrated automated hardware testing into their system. [Michael Orenstein] brought to our attention the Hardware CI Arena, a framework for doing exactly that across a variety of host OSes and microcontroller architectures.

The Hardware CI Arena allows testing software across a variety of hardware boards such as Arduino, RP2040, ESP32, and more.

Here’s the reason it exists: while in theory every OS and piece of hardware implements things like USB communications and device discovery in the same way, in practice that is not always the case. For individual projects, the edge cases (or even occasional bugs) are not much of a problem. But when one is developing a software product that aims to work seamlessly across different hardware options, such things get in the way. To provide a reliable experience, one must find and address edge cases.

The Hardware CI Arena (GitHub repository) was created to allow automated testing to be done across a variety of common OS and hardware configurations. It does this by allowing software-controlled interactions to a bank of actual, physical hardware options. It’s purpose-built for a specific need, but the level of detail and frank discussion of the issues involved is an interesting look at what it took to get this kind of thing up and running.

The value of automatic hardware testing with custom rigs is familiar ground to anyone who develops hardware, but tying that idea into a testing and CI framework for a software product expands the idea in a useful way. When it comes to identifying problems, earlier is always better.

Rubber Bands And O-Rings Give 3D Prints Some Stretch

Sometimes it would be helpful if a 3D printed object could stretch & bend. Flexible filament like TPU is one option, but [NagyBig] designed a simple bracelet to ask: how about embedding rubber bands or o-rings into the print itself?

Embedding objects into prints usually involves hardware like fasteners or magnets, but this is the first one (we can think of) that uses rubber bands. Though we have seen rubber bracelets running on printed wheels, and o-rings used to provide tension on a tool holder.

The end result is slightly reminiscent of embedding 3D printed shapes into tulle in order to create fantastic, armor-like flexible creations. But using rubber bands means the result is stretchy and compliant to a degree we haven’t previously seen. Keep it in mind the next time you’re trying to solve a tricky design problem; an embedded o-ring or rubber band might just do the trick.

Continue reading “Rubber Bands And O-Rings Give 3D Prints Some Stretch”

Showing the scope screen and the BeagleBone setup side by side, with GPIO input and output traces shown on the scope screen.

How Realtime Is Your Kernel? Scope A GPIO To Find Out

When debugging something as involved as kernel scheduler timings, you would typically use one of the software-based debugging mechanisms available. However, in cases when software is close to bare metal, you don’t always need to do that. Instead, you can output a signal to a GPIO, and then use a logic analyzer or a scope to measure signal change timing – which is what [Albert David] did when evaluating Linux kernel’s PREEMPT_RT realtime operation patches.

When you reach for a realtime kernel, latency is what you care about – realtime means that for everything you do, you need to get a response within a certain (hopefully very short) interval. [Albert] wrote a program that reads a changing GPIO input and immediately writes the new state back, and scoped both of the signals to figure out the latency of of the real-time patched kernel as it processes the writes. Overlaying all the incoming and outgoing signals on the same scope screen, you can quickly determine just how suitable a scheduler is when it comes to getting an acceptable response times, and [Albert] also provides a ready-to-go BeagleBone image you can use for your own experiments, or say, in an educational environment.

What could you use this for? A lot of hobbyists use realtime kernels on Linux when building CNC machine controllers and robots, where things like motor control put tight constraints on how quickly a decision in your software is translated into real-world consequences, and if this sounds up your valley, check out this Linux real-time task tutorial from [Andreas]. If things get way too intense for a multi-tasking system like Linux, you might want to use a RTOS to begin with, and we have a guide on that for you, too.

KittyOS: Writing A Toy OS For The ATmega168 From Scratch

Writing an operating system for a computing platform is one of those non-trivial tasks few people actually need to do, regardless of whether it’s for a small microcontroller or a larger general-purpose computer. Many of us spend a large amount of our time working on producing robust code for embedded systems, occasionally diving deeper into the abstraction when we’re stuck on a problem. Quite often this work is sitting on top of an RTOS, which we consider a solved problem. [Jonathan Diamond] had picked up a fair bit of knowledge of some of the low-level AVR black magic, as well as some details of how operating systems work internally, and so decided to have a crack a building a toy operating system called KittyOS, for the learning experience alone.

[Jonathan] hastens to add that this is not a practical OS, but a learning platform that needs a few more bells and whistles added to be useful. Aimed at the 8-bit AVR ATmega168 with its mere 16kB of flash and 1kB of SRAM, the diminutive chip can still perform more than well enough to host the rudimentary OS — up to four application tasks, and some basic system call support.

Already, KittyOS sports preemptive multitasking, with prioritization and support for applications written in C. Hardware support is a bit limited, with just serial I/O and a spot of GPIO, but that’s more than enough for a demonstrator. Applications can be loaded into any of the four available slots, with per-slot run state control, using the Python-based host interface. The post is a long one, with an absolute ton of the gory details we love around these parts, and we’re very glad [Jonathan] took the time to make a proper write-up as well as a demonstration video, which can be found after the break.

Continue reading “KittyOS: Writing A Toy OS For The ATmega168 From Scratch”

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”