The Apple II MouseCard (Credit: AppleLogic.org)

The Apple II MouseCard IRQ Is Synced To Vertical Blanking After All

Recently [Colin Leroy-Mira] found himself slipping into a bit of a rabbit hole while investigating why only under Apple II MAME emulation there was a lot of flickering when using the (emulated) Apple II MouseCard. This issue could not be reproduced on real (PAL or NTSC) hardware. The answer all comes down to how the card synchronizes with the system’s vertical blanking (VBL) while drawing to the screen.

The Apple II MouseCard is one of the many peripheral cards produced for the system, originally bundled with a version of MacPaint for the Apple II. While not a super popular card at the time, it nevertheless got used by other software despite this Apple system still being based around a command line interface.

According to the card’s documentation the interrupt call (IRQ) can be set to 50 or 60 Hz to match the local standard. Confusingly, certain knowledgeable people told him that the card could not be synced to the VBL as it had no knowledge of this. As covered in the article and associated MAME issue ticket, it turns out that the card is very much synced with the VBL exactly as described in The Friendly Manual, with the card’s firmware being run by the system’s CPU, which informs the card of synchronization events.

Button Debouncing With Smart Interrupts

Debouncing button or switch inputs on microcontrollers can be a challenging problem for those first starting to program these devices. Part of the reason for this difficulty is that real-world buttons don’t behave like the idealized textbook components we first learn about, and therefore need special consideration to operate like one would expect. There are simple ways to debounce inputs like adding a delay after a button is pressed, but for more efficient use of computer resources as well as adding some other capabilities to inputs you might want to look at this interrupt service routine (ISR) method from [Lee] aka [stockvu].

The strategy with this debounce method is not simply to use a single ISR for the button input, but to activate a second timer-based ISR at that time that runs at a certain interval which timestamps any button press and checks the amount of time the button has been active. If it’s under a certain threshold the ISR assumes it’s caused by bounce and blocks the bounce. If the timestamp ages past another longer threshold it knows the button has been released. This method allows on-the-fly adaptation between long button presses and rapid button presses and is capable of debouncing both types.

For those wanting to try this out, [stockyu] has included some example Arduino code for others to use. It’s an interesting take on a solution for a common problem, and puts very little load on the microcontroller. There are about as many ways to debounce inputs as there are microcontroller platforms, though, and you can even use a 555 timer to get this job done which frees up 100% of the microcontroller’s CPU.

ANTIRTOS: No RTOS Needed

Embedded programming is a tricky task that looks straightforward to the uninitiated, but those with a few decades of experience know differently. Getting what you want to work predictably or even fit into the target can be challenging. When you get to a certain level of complexity, breaking code down into multiple tasks can become necessary, and then most of us will reach for a real-time operating system (RTOS), and the real fun begins. [Aleksei Tertychnyi] clearly understands such issues but instead came up with an alternative they call ANTIRTOS.

The idea behind the project is not to use an RTOS at all but to manage tasks deterministically by utilizing multiple queues of function pointers. The work results in an ultra-lightweight task management library targeting embedded platforms, whether Arduino-based or otherwise. It’s pure C++, so it generally doesn’t matter. The emphasis is on rapid interrupt response, which is, we know, critical to a good embedded design. Implemented as a single header file that is less than 350 lines long, it is not hard to understand (provided you know C++ templates!) and easy to extend to add needed features as they arise. A small code base also makes debugging easier. A vital point of the project is the management of delay routines. Instead of a plain delay(), you write a custom version that executes your short execution task queue, so no time is wasted. Of course, you have to plan how the tasks are grouped and scheduled and all the data flow issues, but that’s all the stuff you’d be doing anyway.

The GitHub project page has some clear examples and is the place to grab that header file to try it yourself. When you really need an RTOS, you have a lot of choices, mostly costing money, but here’s our guide to two popular open source projects: FreeRTOS and ChibiOS. Sometimes, an RTOS isn’t enough, so we design our own full OS from scratch — sort of.

The Inner Machinations Of The Arduino Are An Enigma

Arduinos have been the microcontroller platform of choice for nearly two decades now, essentially abstracting away a lot of the setup and lower-level functions of small microcontrollers in favor of sensible IDEs and ease-of-use. This has opened up affordable microcontrollers to people who might not be willing to spend hours or days buried in datasheets, but it has also obscured some of those useful lower-level functions. But if you want to dig into them, they’re still working underneath everything as [Jim] shows us in this last of a series of posts about interrupts.

For this how-to, [Jim] is decoding linear timecodes (LTCs) at various speeds. This data is usually transmitted as audio, so the response from the microcontroller needs to be quick. To make sure the data is decoded properly, the first thing to set up is edge detection on the incoming signal. Since this is about using interrupts specifically, a single pin on the Arduino is dedicated to triggering an interrupt on these edges. The rest of the project involves setting up an interrupt service routine, detecting the clock signal, and then doing all of the processing necessary to display the received LTC on a small screen.

The project page goes into great detail about all of this, including all of the math that needs to be done to get it set up correctly. As far as general use of interrupts goes, it’s an excellent primer for using the lower-level functionality of these microcontrollers. And, if you’d like to see the other two projects preceding this one they can be found on the first feature about precision and accuracy, and the second feature about bitbanging the protocol itself.

Diagram of the LTC protocol, showing the difference between 1 bits and 0 bits - both transmitted using one up and one down pulse, but with '1' bit pulses being half as short.

Animate Arcane Protocols With Interrupt-Backed Bitbanging

We often take our “SoftwareSerial” libraries for granted, and don’t investigate what goes on under the hood — until they fail us, at least. Would you like to learn how to harness the power of interrupt-driven bitbanging? [Jim Mack] teaches us how to make our protocol implementations fly using the LTC protocol as a springboard.

LTC (Linear/[Longitudinal] TimeCode) is a widely-used and beautifully-crafted protocol that tends to fly under our radar, and is one that hackers could learn plenty from. It’s used for synchronization of audio/video devices during media production and playback. LTC’s signal is almost digital but not quite: it doesn’t need a clock, and it has no polarity. Additionally, it mimics an audio signal really well, you can decode it at any playback speed, and many other benefits and quirks that [Jim] outlines. You do need to maintain the timings, though, and [Jim]’s article shows us how to keep them right while not inconveniencing your primary tasks.

Continue reading “Animate Arcane Protocols With Interrupt-Backed Bitbanging”

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

Time And Accuracy In Las ATMegas

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.

Bare-Metal STM32: Please Mind The Interrupt Event

Interruptions aren’t just a staple of our daily lives. They’re also crucial for making computer systems work as well as they do, as they allow for a system to immediately respond to an event. While on desktop computers these interrupts are less prominent than back when we still had to manually set the IRQ for a new piece of hardware using toggle switches on an ISA card, IRQs along with DMA (direct memory access) transfers are still what makes a system appear zippy to a user if used properly.

On microcontroller systems like the STM32, interrupts are even more important, as this is what allows an MCU to respond in hard real-time to an (external) event. Especially in something like an industrial process or in a modern car, there are many events that simply cannot be processed whenever the processor gets around to polling a register. Beyond this, interrupts along with interrupt handlers provide for a convenient way to respond to both external and internal events.

In this article we will take a look at what it takes to set up interrupt handlers on GPIO inputs, using a practical example involving a rotary incremental encoder.

Continue reading “Bare-Metal STM32: Please Mind The Interrupt Event”