Electronicseng Embedded Systems: 128-bit SIMD on a $2 ESP32-S3 Delivers roughly double Throughput

A compact MCU becomes more interesting when its instruction set contains a detail that changes the architecture conversation. This Electronicseng EmbeddedSystems note, prepared by Rachel Williams, examines an experiment built around a $2 ESP32-S3, a dual-core device running at 240MHz and carrying WiFi plus Bluetooth Low Energy peripherals. The experiment focused on a limited set of 128-bit SIMD instructions used to accelerate a FAST feature-detection path. The reported outcome was roughly double the reference implementation performance, with a QVGA frame sized 320x240 handled in around ~6ms, and the exploration also produced basm, a simple register allocator shaped by the chip's assembly constraints.

Hardware context: why the vector path matters for firmware work

The technical reference manual was the place where the vector capability was found. The chip is not being presented here as a generic coffee-cheap curiosity; the relevant engineering point is that the limited 128-bit SIMD instructions exist on silicon that also provides dual-core operation, 240MHz clocking, WiFi, and Bluetooth Low Energy. That combination makes it reasonable to ask whether a small image pipeline can exceed scalar performance while staying within tight code, memory, and power budgets.

The author's stated goal was a SIMD-accelerated FAST corner detector, not a broad port of a vision framework. The claimed result was that the detector reached roughly double performance versus the reference implementation and handled the 320x240 QVGA frame in around ~6ms. The instructions were not secret, but they were obscure enough that the available examples did not fully satisfy the goal of writing more advanced code. At the time of writing, three starting points were named: a blog post by Larry Bank that explored the feature with a minimal sample; esp-dsp, an Espressif library for DSP-style routines such as convolutions and FFT; and esp-dl, another Espressif library aimed at on-chip AI acceleration.

Step-by-step tutorial: turning scalar FAST logic into SIMD code

1. Confirm the vector instruction surface. Before choosing the algorithm, use the technical reference manual to see whether the $2 ESP32-S3 exposes a limited set of 128-bit SIMD instructions. On the hardware described here, the dual-core and 240MHz context, plus WiFi and Bluetooth Low Energy, make the question worth answering, because a small vision kernel may benefit from vector bytes.
2. Define the scalar rule that must survive vectorization. The FAST corner pre-test samples one pixel in each cardinal direction, then tests whether at least three extreme pixels exist, where extreme means an absolute difference from the center pixel beyond the configured threshold. That rule is the contract for the SIMD function.
3. Choose the vector granularity. A vector register holds sixteen eight-bit lanes, so the author selected a function that calculates the extrema count for sixteen pixels at a time. The design samples four chunks of pixels in each cardinal direction and compares those chunks with their respective center pixels.
4. Reproduce the basic assembly shape. The materials suggested a pattern: keep constants in .rodata; align executable code in a .text section using four-byte alignment; expose a global add function; open with an entry statement that sets up the stack pointer; assign register aliases; execute the addition; then return using retw.n so that a2 carries the result.
5. Plan for misaligned neighborhood access. The ISA disallows direct misaligned reads. If the center pixel block is assumed aligned, east and west blocks can become misaligned. The author solved this by reading two blocks adjacent to the center and using an instruction that extracts a slice from two concatenated registers into another register.
6. Convert image bytes into the signed comparison domain. Comparisons on the ESP32-S3 are only available for signed eight-bit values, while image data is stored as unsigned eight-bit values. Reinterpreting the bytes as signed data moves [128 255] nonlinearly into [-128 -1], breaking compare logic.
7. Normalize without relying on subtract. The desired linear range is [-128 127] from the source [0, 255] domain. A direct subtract of 128 would usually work, but SIMD arithmetic is saturating: values above 127 clamp at -128 instead of underflowing. Therefore the author needed a way to subtract 128 from each lane without a subtraction instruction.
8. Apply the bit-flip shortcut. Treating x as the minuend and placing its digits against the weights -128 64 32 16 8 4 2 1 shows why adding -128 is equivalent to incrementing the most significant digit. That increment flips the highest bit. Since XORing a bit with one equals bitwise NOT, the transformation is x ^ 0x80, with the mask 0b10000000. After this change, unsigned eight-bit image bytes are loaded, XORed with 0x80, and then processed in a linear signed range.
9. Measure the accelerated kernel. The report gives throughput from 5.1MP/s to 11.2MP/s, an improvement of about 220%. The resulting rate is described as acceptable for realtime computer vision, letting the chip handle a 30fps VGA stream. A SIMD scoring function was also built with a similar operation set, though the article did not discuss it further.

Common misconceptions: where small-MCU SIMD work goes wrong

• Obscure does not mean unavailable. The 128-bit path was present, just not obvious. At the time of writing, the named starting points were only three: Larry Bank's minimal sample, esp-dsp, and esp-dl. Engineers should treat these as entry points, not as the final architecture.
• Byte comparisons are not range-agnostic. The hardware compares signed eight-bit values. If unsigned pixels are passed directly, the high half of the byte space, [128 255], can appear as negative values in a nonlinear way, and the comparison result becomes unreliable.
• Saturating arithmetic changes normalization. A simple subtract 128 does not provide the needed signed mapping because values above 127 clamp at -128. The reliable route is x ^ 0x80, which is equivalent to x - 128 under the place-value view -128 64 32 16 8 4 2 1.
• Alignment is not a compiler detail. Direct misaligned reads are not allowed in the ISA. A kernel that assumes center, east, and west blocks all load cleanly can fail in the simplest neighborhood access. The solution was to use adjacent blocks and extract slices from two concatenated registers.
• Register pressure is a real reason for helper tooling. The odd restrictions encountered while writing the detector led to basm, a simple register allocator, rather than a pure handwritten register plan.

Comparison table: scalar assumptions and SIMD-aware decisions

Design question	Simpler scalar or library example assumption	ESP32-S3 SIMD-aware choice in this experiment	Reported consequence
What hardware is being used?	A tiny MCU may be treated as a scalar controller only.	The $2 ESP32-S3 was examined for its limited set of 128-bit SIMD instructions, with dual-core and 240MHz context plus WiFi and Bluetooth Low Energy.	A FAST detector became a candidate for byte-lane acceleration.
How are corner samples formed?	Check one pixel per cardinal direction against a threshold.	Use vector registers holding sixteen eight-bit values, calculate for sixteen pixels at a time, and sample four chunks per direction.	The scalar pre-test rule can be expressed with SIMD lanes.
How are misaligned blocks handled?	Assume the required neighborhood blocks can be read directly.	Read two blocks adjacent to the center and extract the needed slice from two concatenated registers.	The ISA restriction on direct misaligned reads is respected.
What numeric domain is compared?	Use unsigned image bytes as-is.	Convert [0, 255] values to [-128 127] before comparison; naive signed reinterpretation maps [128 255] to [-128 -1].	Compare operations behave consistently.
How is the range shifted without saturating errors?	Subtract 128 per byte lane.	Because SIMD arithmetic is saturating, apply x ^ 0x80, with mask 0b10000000, to represent x - 128.	Pixel bytes land in the signed range without clamping above 127 to -128.
What throughput was reported?	Reference implementation defines the baseline.	SIMD acceleration produced roughly double performance.	Throughput improved by about 220%, from 5.1MP/s to 11.2MP/s; a 320x240 frame ran in around ~6ms, and the result supports a 30fps VGA stream.

FAQ: quick answers for embedded reviewers

Q: What does basm contribute?

A: It is a simple register allocator. The article presents it as an outcome of the odd assembly restrictions encountered while implementing the SIMD FAST detector.

Q: Did any public examples already exist?

A: Yes. At the time of writing, the article mentions three: Larry Bank's minimal exploration, esp-dsp from Espressif for DSP-style routines, and esp-dl from Espressif for on-chip AI acceleration.

Q: What is the practical speed number?

A: The reported FAST throughput moved from 5.1MP/s to 11.2MP/s, which is an improvement of about 220%. The article describes that as the roughly double result and notes around ~6ms for a 320x240 QVGA frame.

Q: Why is x ^ 0x80 used instead of subtraction?

A: The target is to convert bytes from [0, 255] to [-128 127] while avoiding saturating arithmetic. The mask 0x80, written as 0b10000000, flips the highest bit, which is the place-value trick for x - 128 when the byte weights are viewed as -128 64 32 16 8 4 2 1.

Q: What is the most likely early debugging failure?

A: Alignment and signed-byte assumptions. Direct misaligned reads are not permitted, and comparisons are only defined for signed eight-bit values, so unsigned pixel data must be transformed before vector comparisons.

Action recommendations for EmbeddedSystems prototypes

1. Make the instruction check part of the initial feasibility pass. For a $2 MCU, search the technical reference manual for a limited set of 128-bit SIMD instructions before discarding the vector route.
2. Choose a byte-heavy kernel whose scalar rule can be stated exactly, such as the FAST pre-test that samples one pixel in each cardinal direction and looks for at least three extreme pixels.
3. Size the loop around sixteen eight-bit lanes, then decide whether four chunks per cardinal direction can be compared with their respective center pixels without creating unmanageable alignment cases.
4. Treat every misaligned neighborhood load as expected. When east and west access cannot be loaded directly, use adjacent blocks and slice extraction from two concatenated registers.
5. Normalize pixel values before compare. Keep the signed target [-128 127], avoid naive subtraction because of saturating arithmetic, and apply x ^ 0x80 using the 0b10000000 mask.
6. Benchmark against the reference implementation. Report the measured throughput path, not only the speedup adjective: in this experiment, 5.1MP/s becomes 11.2MP/s, about 220% faster, with a 320x240 frame in around ~6ms and enough headroom for 30fps VGA streaming.

For embedded software and firmware teams, the article's value is less about the low price and more about the architectural implication: a constrained MCU can sometimes accept vectorized image code if the engineer resolves register layout, byte-domain conversion, and memory access rules. The experiment described here kept the dual-core, 240MHz, WiFi, and Bluetooth Low Energy device within its own boundaries, while the SIMD FAST result landed at roughly double performance, about 220% measured throughput gain, and around ~6ms for a 320x240 frame. At the time of writing, only three public resources framed the starting point; the deeper lesson was that the vector instructions were not hidden but obscure, and the workable code depended on understanding signed eight-bit comparisons, misaligned reads, saturating arithmetic, and the need for basm.