Speeding Up Drawing To MCU-Connected Serial Displays

Writing image data to serially connected (SPI/I2C) displays from a microcontroller is easy enough these days, courtesy of standards defined by the MIPI Alliance, yet there are some gotchas in it which may catch someone using it unaware. [Larry Bank] wrote up a good summary of how one can get maximum performance out of such a display link.

At the core is the distinction between pixel data and command transmissions. The change from command to pixel data mode requires signaling, which takes precious clock cycles away from transferring pixel data between the MCU and display. The common MIPI DCS instruction set allows for a big reduction in needed data transfers by allowing parts of the display to be addressed instead of requiring a full refresh. Yet by not properly segmenting command and data transfers, one ends up unnecessarily slowing down the process.

The result is that one can run something like a Pac-Man emulator on an AVR MCU with a sluggish 320×480 SPI LCD at 60 FPS, as one can see in the video that is embedded after the break. Check the article for another demo video as well.

Continue reading “Speeding Up Drawing To MCU-Connected Serial Displays”

WiringPi Library To Be Deprecated

Since the release of the original Raspberry Pi single board computer, the WiringPi library by [Gordon] has been the easy way to interface with the GPIO and peripherals – such as I2C and SPI – on the Broadcom SoCs which power these platforms. Unfortunately, [Gordon] is now deprecating the library, choosing to move on rather than deal with a community which he no longer recognizes.

Among the points which he lists are the (commercial) abuse of his code, and the increasing amount of emails and messages on social media from folk who either failed to read the friendly manual, or are simply rude and inconsiderate. As [Gordon] puts it, WiringPi was never meant to be statically linked into code, nor to be used with anything other than C and RTB BASIC programmers. He never supported the use of the library with other languages, or having it statically integrated into some Java/JavaScript/NodeJS project.

As this secondary use is what’s draining the fun out of the project, he has decided to put out one final release, before making it a closed-source project, for use by himself and presumably paying clients. What the impact of this will be has to be seen. Perhaps a new fork will become the new ‘WiringPi’?

Suffice it to say, none of this is a good thing. The illegal use of open source code and the support nightmare that gets poured on the authors of said code by less than informed users is enough to drive anyone away from putting their projects out there. Fighting abuse and junking the ‘spam’ is one way to deal with it, but who has the time and energy (and money) for this?

What are your thoughts on this news, and this issue in general? How should an open source developer deal with it?

Thanks to [Dirk-Jan Faber] for sending this one in.

Upping The Story-Telling Game With Dialog And The Å-Machine

During the decades since Infocom released their interactive story game Zork to world-wide acclaim for microcomputers, the genre of interactive fiction (IF) is still immensely popular, with a surprising number of modern IF works targeting Infocom’s original Z-Machine runtime for 8-bit micocomputers. We’ve seen a number of improved runtimes and languages for the platform over the years, with [Linus Åkesson]’s Dialog language a newcomer.

Covering the technical details about the language in this thread at IntFiction, the interesting aspect about this language is that while it has a compiler that compiles it to Z-code for the Z-Machine, [Linus] has also implemented a new runtime, called the ‘Å-Machine‘, since ‘Å’ follows ‘Z’ in the alphabet (if you’re Swedish, that is). This runtime should allow for larger stories and other features that make better use of more resources, while still allowing smaller stories to work on old hardware. Unfortunately the only Å-Machine implementation at this point is written in JavaScript, which is not known to work particularly well on Commodore 64 or even Amiga 500 systems.

As for Dialog itself, its documentation provides a detailed overview of the language’s capabilities, which claims to be inspired by both Inform 7 and Prolog. Its goals are to be easy to follow, with a minimal number of language concepts, and high performance. As the documentation notes, many Z-Machine based stories exist today that are unplayable on vintage hardware due to lack of optimization.

We covered Zork and the Z-Machine a while ago in some detail. We think it’s great to see that there’s still so much interest in the platform. Maybe someone will write an Å-Machine implementation for a Commodore or MSX system one of these days to see how it compares to Infocom’s Z-Machine. Here’s to another few decades of the Zork-legacy.

Using The Electricity Grid In Cities As A Source Of Heat

In the process of finding new, low-carbon ways to provide our homes with heat and electricity, it is that one might consider sources that never before came to mind. In London such a source that has been examined by researchers and an electricity network operator are the 2.5 meter wide tunnels that run for many kilometers underneath the city. In each of them are many more kilometers worth of electricity distribution cables, each of which produces so much heat from electric resistance that active cooling is required.

Currently, every 1.8 kilometers there are shafts that lead to the surface, through which cold surface air is brought in and the warm tunnel air is exhausted into the air. The study by London South Bank University researchers and UK Power Networks looked at using this heat directly for heating local houses, replacing the use of gas boilers. This is in effect similar to heating with waste heat from industrial processes, but with noticeable differences.

The thermal power available from each 1.8 kilometer section of tunnel differs between 100 – 460 kW by installing equipment at the top of the shafts. With London looking at using heat from the London Underground for heating in a similar fashion, it would be fascinating to see whether the combined heat from both underground sources could provide the city with a sizeable source of low-carbon heat, while increasing creature comfort.

GymCam Knows Exactly What You’ve Been Doing In The Gym

Getting exact statistics on one’s physical activities at the gym, is not an easy feat. While most people these days are familiar with or even regularly use one of those motion-based trackers on their wrist, there’s a big question as to their accuracy. After all, it’s all based on the motions of just one’s wrist, which as we know leads to amusing results in the tracker app when one does things like waving or clapping one’s hands, and cannot track leg exercises at the gym.

To get around the issue of limited sensor data, researchers at Carnegie Mellon University (Pittsburgh, USA) developed a system based around a camera and machine vision algorithms. While other camera solutions that attempt this suffer from occlusion while trying to track individual people as accurately as possible, this new system instead doesn’t try to track people’s joints, but merely motion at specific exercise machines by looking for repetitive motion in the scene.

The basic concept is that repetitive motion usually indicates forms of exercise, and that no two people at the same type of machine will ever be fully in sync with their motions, so that merely a handful of pixels suffice to track motion at that machine by a single person. This also negates many privacy issues, as the resolution doesn’t have to be high enough to see faces or track joints with any degree of accuracy.

In experiments at the university’s gym, the accuracy of their system over 5 days and 42 hours of video. Detecting exercise activities in the scene was with a 99.6% accuracy, disambiguating between simultaneous activities was 84.6% accurate, while recognizing exercise types was 93.6% accurate. Ultimately repetition counts for specific exercises were within 1.7 counts.

Maybe an extended version of this would be a flying drone capturing one’s outside activities, giving one finally that 100% accurate exercise account while jogging?

Thanks to [Qes] for sending this one in!

Why Ada Is The Language You Want To Be Programming Your Systems With

The Ada programming language was born in the mid-1970s, when the US Department of Defense (DoD) and the UK’s Ministry Of Defence sought to replace the hundreds of specialized programming languages used for the embedded computer systems that increasingly made up essential parts of military projects.  Instead, Ada was designed to be be a single language, capable of running on all of those embedded systems, that offered the same or better level of performance and reliability.

With the 1995 revision, the language also targeted general purpose systems  and added support for object-oriented programming (OOP) while not losing sight of the core values of reliability, maintainability and efficiency. Today, software written in Ada forms the backbone of not only military hardware, but also commercial projects like avionics and air-traffic control systems. Ada code controls rockets like the Ariane 4 and 5, many satellites, and countless other systems where small glitches can have major consequences.

Ada might also be the right choice for your next embedded project. Continue reading “Why Ada Is The Language You Want To Be Programming Your Systems With”

Everything You Wanted To Know About Padauk MCUs And More

At this point you’d need to have lived underneath a rock somewhere on the dark side of the Moon to not have heard about these amazing, 3-cent microcontrollers. A number of places have pitched in on them, but comprehensive reviews, let alone a full-blown review of the entire ecosystem surrounding these Padauk MCUs have been scarce. Fortunately, [Jay Carlson] has put in a lot of effort to collect everything you could possibly want to know about anything Padauk.

The most important take-away is that these MCUs do not have any kind of communication peripherals. UARTs, I2C, and SPI all have to be done in software. They’re not very great at low-power or battery-powered applications due to high power usage. Essentially you’ll be using GPIO pins a lot. On the other hand, its multi-CPU context, FPPA feature is rather interesting, with the article covering it in detail.

As for the development tools, [Jay] came away very impressed with the In-Circuit Emulation (ICE) instead of running code on an MCU, as this can reduce development times significantly. This makes even the OTP (one-time programmable) property of most Padauk MCUs less significant than one might at first assume.

Then there’s the actual programming of the MCUs. The Micro C compiler Padauk provides essentially implements a sub-set of the C language, with some macros to replace things like for loops. Initially this may seem like a weird limitation, until you realize that these MCUs have 64 to 256 bytes of SRAM. That’s bytes, without any prefixes.

Finally, [Jay] shows off a couple of test projects, including a NeoPixel SPI adapter and bike light, which are all available on Github. The WS2812b project is something we have seen before, for example this project from [Anders Nielsen] (featured in the article image), which provides another take on this range of MCUs.

Did reading [Jay]’s article change your mind on these Padauk parts? Have you used these MCUs and ICE parts before? Feel free to leave your thoughts in the comments.