Is 32-bits Really Dead?

While some of us are still clinging onto our favorite 8-bit microprocessors, ARM announced they will be killing off the 32-bit architecture in 2022 and/or 2023. Over on the GaryExplains YouTube channel, [Gary Sims] posted a great review of the current 32- vs 64-bit state-of-affairs — not just for ARM but for Intel and AMD processors as well. And it’s a dismal outlook for you 32-bit fans.

ARM announced last Fall that there would be no more 32-bit support as of 2022, then this March they made a similar announcement but with a 2023 deadline. [Gary] tries to parse these statements, and takes an educated guess at what the disparity means (spoiler alert — he predicts that one more 32-bit core will soon be released).

[Gary] clearly breaks down the 32-bit situation by operating systems such as Linux, Windows, MacOS, Android, and iOS, and how all of these have been transitioning to 64-bits over recent years. He does a thorough job, and concludes that the transition is already well underway. And while Linux and Windows have not completely dropped 32-bit support, the writing is on the wall.

Take note, however, that this discussion regards the Cortex-A family of cores found in smart phones, tablets, computers, and powerful embedded applications like autonomous vehicles. The popular 32-bit Cortex-M family of low-cost / low-power cores that are used in so many embedded system designs will remain 32-bits for the foreseeable future.

After watching [Gary]’s presentation, if you want to learn more, check out the writeup that [Maya Posch] did on the details of the latest ARMv9 ISA a few weeks ago. Also watch this 8-bit vs 32-bit presentation by our Editor-in-Chief [Mike Szczys]. Despite being from five years ago, it is still quite applicable today. What about 16-bit MCUs — the old Intel/AMD embedded 80186 processor, the 8051 follow-ons like the 80C196, 80C251, or 8051XA, the 6502 follow-ons like the 65C816, Zilog’s Z8000, the Renesas M16C, etc. — is anyone using them anymore? If so, or if you’re using a 4-bit MCU these days, let us know in the comments below.

Continue reading “Is 32-bits Really Dead?”

Raspberry Pi RP2040: Hands-On Experiences From An STM32 Perspective

The release of the Raspberry Pi Foundation’s Raspberry Pi Pico board with RP2040 microcontroller has made big waves these past months in the maker community. Many have demonstrated how especially the two Programmable I/O (PIO) state machine peripherals can be used to create DVI video generators and other digital peripherals.

Alongside this excitement, it raises the question of whether any of this will cause any major upheaval for those of us using STM32, SAM and other Cortex-M based MCUs. Would the RP2040 perhaps be a valid option for some of our projects? With the RP2040 being a dual Cortex-M0+ processor MCU, it seems only fair to put it toe to toe with the offerings from one of the current heavyweights in the 32-bit ARM MCU space: ST Microelectronics.

Did the Raspberry Pi Foundation pipsqueak manage to show ST’s engineers how it’s done, or should the former revisit some of their assumptions? And just how hard is it going to be to port low-level code from STM32 to RP2040? Continue reading “Raspberry Pi RP2040: Hands-On Experiences From An STM32 Perspective”

The ARMv9 ISA, And What It Can Do For You

The number of distinct ARM Instruction Set Architectures (ISA) versions has slowly increased, with Arm adding a new version every few years. The oldest ISA version in common use today is ARMv6, with the ARMv6 ISA (ARM11) found in the original Raspberry Pi SBC and Raspberry Pi Zero (BCM2835). The ARMv6 ISA was introduced in 2002, followed by ARMv7 in 2005 (start of Cortex-A series) and ARMv8 in 2011. The latter was notable for adding 64-bit support.

With ARMv7 being the first of the Cortex cores, and ARMv8 adding 64-bit support in the form of AArch64, what notable features does ARMv9 bring to the table? As announced earlier this year, ARMv9’s focus appears to be on adding a whole host of features that should improve vector processing (vector extensions, or SVE) as well as digital signal processing (DSP) and security, with its Confidential Compute Architecture (CCA).

In addition to this, ARMv9 also includes all of the features that were added with ARMv8.1, v8.2, v8.3 and so on. In essence, this makes an ARMv9-based processor theoretically capable of going toe-to-toe with the best that Intel and AMD have to offer.

Continue reading “The ARMv9 ISA, And What It Can Do For You”

Debug ARM Virtually

With the advent of super powerful desktop computers, many developers make use of some sort of virtual or psuedo-virtual machines (VM). We run Windows in a VM and do kernel development in a VM, too. If you are emulating the same kind of computer you are on then the process is simpler, but it is possible to run, say, ARM code on an x86 (or vice versa) but with possibly slower performance than running natively. QEMU is probably the best-known program that allows a CPU to run code targeting a different CPU, but — by default — it targets desktop, laptop, and server-class machines, not tiny embedded boards. That’s where xPack QEMU Arm comes in. It allows you to run and debug embedded Cortex-M devices in an emulated environment on a host computer.

The tool supports boards like the Maple — which means it should support bluepill, along with popular boards such as the Nucleo, some discovery boards, and several from Olimex. They have plans to support several popular boards from TI, Freescale, and others, but no word on when that will happen. You can see a decidedly simple video example from [EmbeddedCraft] of blinking a virtual LED in the video below, although you might like to mute your audio before playing it.

Continue reading “Debug ARM Virtually”

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”

The Long Journey Ahead For Linux On Apple Silicon

An old joke from the Linux community about its prevalence in computing quips that Linux will run on anything, including some animals. While the joke is a little dated, it is true that Linux can run on just about any computing platform with a certain amount of elbow grease. The current exception is the new Apple M1 silicon, although one group called Asahi Linux is currently working to get Linux running on this novel hardware as well.

While the Apple M1 is specifically built to run macOS, there’s no technical reason why Linux couldn’t run on it once all of the kinks are ironed out. This progress report from last month outlines some of the current areas of focus, especially around booting non-Mac kernels. The new Apple silicon runs on an ARM processor and because of this it functions more like an embedded device than a PC with standardized BIOS or UEFI. This means a lot of workarounds to the proprietary boot process have to be created to get a Linux kernel to boot. Luckily there are already versions of Linux that run on ARM so a lot of work has already been done, but there’s still much ahead.

While it’s probably best to buy an x86 machine for the time being if you need a Linux on your own personal machine, it seems like only a matter of time until all of the barriers to Linux are overcome on the M1 silicon. If Linux is able to take advantage of some of the efficiency and performance benefits of these chips, it could be a game-changer in the Linux world and at least give us all another option for hardware. Of course, we will still be needing software that can run on ARM, too.

Thanks to [Mark] for the tip!

Blue Pill Vs Black Pill: Transitioning From STM32F103 To STM32F411

For many years now, the so-called ‘Blue Pill’ STM32 MCU development board has been a staple in the hobbyist community. Finding its origins as an apparent Maple Mini clone, the diminutive board is easily to use in breadboard projects thanks to its dual rows of 0.1″ pin sockets. Best of all, it only costs a few bucks, even if you can only really buy it via sellers on AliExpress and EBay.

Starting last year, boards with a black soldermask and an STM32F4 Access (entry-level) series MCUs including the F401 and F411 began to appear. These boards with the nickname ‘Black Pill’ or ‘Black Pill 2’. F103 boards also existed with black soldermask for a while, so it’s confusing. The F4xx Black Pills are available via the same sources as the F103-based Blue Pill ones, for a similar price, but feature an MCU that’s considerably newer and more powerful. This raises the question of whether it makes sense at this point to switch to these new boards.

Our answer is yes, but it’s not entirely clearcut. The newer hardware is better for most purposes, really lacking only the F103’s dual ADCs. But hardware isn’t the only consideration; depending on one’s preferred framework, support may be lacking or incomplete. So let’s take a look at what it takes to switch. Continue reading “Blue Pill Vs Black Pill: Transitioning From STM32F103 To STM32F411”