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”

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”