Software Development

748 Articles

An Interview With Reinhard Keil

March 6, 2022 by 3 Comments

Over on the Embedded FM podcast, [Chris] and [Elecia] just released their interview with [Reinhard Keil] of compiler fame. [Reinhard] recounts the story of Keil’s growth and how it eventually became absorbed into Arm back in 2005. Along with his brother Günter, the two founded the company as Keil Software in the Americas, and Keil Elektronik in Europe. They initially made hardware products, but as the company grew, they became dissatisfied with the quality and even existence of professional firmware development tools of the day. Their focus gradually shifted to making a CP/M- and a PC-based development environment, and in 1988, they introduced the first C-compiler designed for the 8051 from the ground up.

Love it or hate it, the Arm Keil suite of µVision IDE and the MDK/Cx51 compiler have been around a long time and used by embedded developers in many industries. Although a free and restricted-use version is available, the license fees prevent most folks from getting very enthusiastic about it. Pricing aside, the µVision IDE has its critics: [Jay Carlson], who used every IDE under the sun a few years ago in his review of sub-one-dollar microcontrollers, opined that it was nothing more than a free editor you get with C51 or MDK-ARM. On the other hand, even [Jay] concedes is that every chip he tested was officially supported by Keil and worked out of the box. Another thing that is important to some users is being able to produce consistent binaries from old projects. This isn’t important for your one-off MQTT hot tub thermometer. But if you need to recompile firmware for a fifteen-year-old railroad signaling system that has multiple certifications and regulatory approvals, using the original compiler and library versions is a huge help.

[Reinhard] goes on to discuss various tools and systems being developed at Arm by his team, such as improvements and additions to the CMSIS suite, the transition of the online Mbed compiler to the new Keil Studio Cloud, and an Arm hardware virtualization tool for cloud-based CI verification. Lest you think everything at Arm is proprietary and expensive, he points out that Arm is a major contributor to the GCC project and the CMSIS components are open source. Even if you aren’t interested in Arm/Keil tools, do check out the interview — it’s quite interesting and touches on several topics of general interest to all firmware developers. Or if you prefer, read the interview when the transcript is completed.

Ray Tracing On A Modern TI Graphing Calculator

February 21, 2022 by 16 Comments

Something being impractical isn’t any reason not to do it, which is why just about anything with a CPU in it can run Doom by now. For the same reason there obviously is a way to do ray tracing of 3D scenes on a modern-day TI-84 Plus CE graphical calculator. This is excellent news for anyone who has one of these calculators, along with a lot of time, perhaps during boring classes, to spare.

As [TheScienceElf] demonstrates in a video, also embedded after the break, it’s not quite the real-time experience one would expect from an NVidia RTX 30-series GPU. Although the eZ80-based CPU in the calculator is significantly more efficient than a Z80 as found in many 1980s home computers, the demo scene at standard resolution takes about 12 minutes to render, as also noted on the GitHub project page.

Perhaps the most interesting part about this project is its use of the Clang-based C & C++ toolchain for the TI-84 Plus CE which gives easy access to the calculator’s hardware and related, including graphics, file I/O, fonts, keypad input and more. Even if using a TI-84 Plus CE to render the next Pixar-level movie isn’t the most productive use imaginable for these devices, this project and the CE toolchain make it all too easy to tinker with these $150 devices.

It would also offer a nice change of pace from writing Snake in TiBASIC, a BASIC dialect in which [TheScienceElf] incidentally has also written a ray tracer.

(Thanks to [poiuyt] for the tip)

Continue reading “Ray Tracing On A Modern TI Graphing Calculator” →

Commodore 64 Monitor Traces I/O Calls, Eases Debugging

February 18, 2022 by 7 Comments

Developing for the Commodore 64 can be a rewarding retrocomputing experience, and thanks to [Dave Van Wagner], things are easier with his C64 IO_Monitor project, which opens the door to logging and tracing Kernal I/O calls for closer inspection. That’s not a typo, by the way. Kernal is what handles the C64’s low-level OS routines. Amusingly, as the story goes, it did in fact originate as a misspelling of kernel, but the name stuck.

What [Dave]’s program does is trace and log all input and output calls going through Kernal, which includes just about any function one might imagine. Things like keyboard input, screen output, and disk or tape I/O are all dutifully counted and logged, allowing one to really peek under the hood at a low level when doing any kind of development work. This kind of tool has turned out to be pretty handy given [Dave]’s penchant for porting Commodore emulators to a variety of (sometimes unusual) platforms.

Interested in giving it a spin? Head to the project’s GitHub repository for all the necessary files as well as some usage details, and enjoy making debugging and development a little less opaque than it otherwise would be.

Hello (Many Quantum) World(s)

February 17, 2022 by 9 Comments

Historically, the first program you write for a new computer language is “Hello World,” or, if you are in Texas, “Howdy World.” But with quantum computing on the horizon, you need something better. Like “Hello Many Worlds.” [IonQ] proposes what that looks like and then writes it in seven different quantum languages in a post you should check out.

Here’s the description of the simple program:

The basic quantum program we’ll write is simple. It creates a fully-entangled state between two qubits, and then measures this state. This state is sometimes called a Bell State, or Bell Pair, after physicist John Stewart Bell.

The measurement results for this program should give us 0 for both qubits or 1 for both qubits, in equal amounts. When running these, we’ll be able to tell that we’re running on real hardware because that’s not always what we get! These errors are what currently limit quantum computers, but the first steps to overcome this with quantum error correction have already begun.

Continue reading “Hello (Many Quantum) World(s)” →

Twist Promises Easier Quantum Programming

February 5, 2022 by 17 Comments

We keep trying to learn more about quantum computers. But the truth is, the way we program quantum computers — or their simulators — today will probably not have much in common with how we program them in the future. Think about it. Programming your PC is nothing like programming the ENIAC. So we expect we’ll see more and more abstractions over the “bare metal” quantum computer. The latest of these is Twist, from MIT.

According to the paper (and the video, below), Twist expresses entangled data and processes in a way that traditional programmers can understand. The key concept is known as “purity” of expressions which helps the compiler determine if data is actually entangled with another piece of data or if any potential entanglement is extraneous. A pure expression only depends on qubits it owns, while a mixed expression may use qubits owned by other expressions.

Continue reading “Twist Promises Easier Quantum Programming” →

Hackaday Invades The FLOSS Weekly Podcast

February 2, 2022 by No comments

Regular Hackaday readers will know that we’re big supporters of free/libre and open source software (FLOSS) around these parts. There’s an excellent chance you are too, as so many of the incredible projects you send our way make it a habit to share their innermost details, from firmware source code to the OpenSCAD files that generate its 3D printed components. So when our recently minted Editor in Chief [Elliot Williams] was invited to join This Week in Tech’s FLOSS Weekly podcast, he jumped at the chance to represent our little corner of the Internet to the wider world of open source aficionados. (Ed: The final version is now live!  How did we get episode 666?!)

Hosted by [Doc Searls], FLOSS Weekly is known for its in-depth interviews with “the most interesting and important people in the Open Source and Free Software community”, so we hope the incursion by hacker rabble such as ourselves doesn’t taint their brand too much.

It’s live streamed every Wednesday at 12:30 PM Eastern / 9:30 AM Pacific / 17:30 UTC, which means that by the time this post hits the main page of the site, you’ve still got time to tune in. For those of you with gainful employment who can’t slack off for an hour or so in the middle of the workweek, the recorded version will be available afterwards for your time-shifted viewing and or listening pleasure.

[Elliot] will be joined by Hackaday writer and regular co-host of FLOSS Weekly [Jonathan Bennett], making this something of a Jolly Wrencher double-feature. [Jonathan] has been providing readers with a regular peek into the other type of hacking with his fantastic This Week in Security column, and is himself a devout FOSS supporter with a particular passion for GNU/Linux. We’re excited to listen in as the trio riffs on open source at the crossroads of hardware and software, not just because it promises to be an entertaining bit of programming, but because it’s a great opportunity to introduce the world of Hackaday to the wider open source audience.

A graph visualising approximation errors - the specific principle pictured is described well by the linked article

Time And Accuracy In Las ATMegas

January 31, 2022 by 4 Comments

Do you ever have to ensure that an exact amount of time passes between two tasks in your microcontroller code? Do you know what’s the difference between precision and accuracy? Today, [Jim Mack] tells us about pushing timers and interrupts to their limits when it comes to managing time, while keeping it applicable to an ever-popular ATMega328P target! Every now and then, someone decides to push the frontiers of what’s possible on a given platform, and today’s rules is coding within constraints of an Arduino environment. However, you should check [Jim]’s post out even if you use Arduino as a swearword – purely for all of the theoretical insights laid out, accompanied by hardware-accurate examples!

This will be useful to any hacker looking to implement, say, motor encoder readings, signal frequency calculations, or build a gadget processing or modifying audio in real time. To give you a sample of this article, [Jim] starts by introducing us to distinctions between precision and accuracy, and then presents us with a seemingly simple task – creating exactly 2400 interrupts a second. As much as it might look straightforward, problems quickly arise when clock crystal frequency doesn’t cleanly divide by the sampling frequency that you have to pick for your application! This is just a taste of all the examples of hidden complexity presented, and they’re accompanied with solutions you can use when you eventually encounter one of these examples in your hacker pursuits. In the end, [Jim] concludes with links to other sources you can study if you ever need to dig deeper into this topic.

Keeping our projects true to the passage of time can be an issue, and we’ve been at it for ages – calibrating your RC oscillator is a rite of passage for any ATTiny project. If you ever decide to have an interrupt peripheral help you with timing issues, we’ve gone in-depth on that topic in the past, with a three-part series describing the benefits, the drawbacks and the edgecases of interrupts. Going for a more modern target? Our piece on using interrupts with STM32 is a great path for trying out tools of the modern age.