The Tech Blog

Last month, Bluetooth Core 6.2 made a change I have wanted for years. It solves a long-standing pain point in Bluetooth LE when you care about real-time response. Back when I was building low latency MIDI controllers at ACPAD, we were operating in the BLE 4.0 era. On that, I could move plenty of bits, but not shorter data faster. The main issue was the connection timing.

In BLE, a connected link wakes up in repeating connection events. The connection interval is the time between those events. Until 6.2, the minimum connection interval was 7.5 ms, which means your worst case packet can wait 7.5ms for the next connection, even before protocol overhead delays. For tight MIDI timing in real time instrument playing, this delay feels like a sound lag for professional musicians.

BLE 6.2 introduces Shorter Connection Intervals(SCI), pushing the minimum down to 0.375 ms when both devices support it. This means you can send small packets of data faster. In practice, that means you can get a polling rate over 1kHz. This is a big deal of HID devices like mouse. Gamers don’t use wireless BLE mouse for this exact reason. You will see a large boom in wireless BLE mouse and fall in the mouse with 2.4GHz USB dongles where this limit is not applicable.

Please note that your raw on-air speed is still based on the 2M LE PHY and that has not increased. Shorter intervals just reduce waiting time between opportunities to send small packets.

BTW, do not treat the smallest interval as a default setting. More transfers mean more battery loss. A better option is adaptive timing, meaning run a longer interval while idle, then negotiate a shorter one only during interaction, and return to a longer interval when activity stops. A 6.2 connection still starts at ≥7.5 ms and only then negotiates shorter intervals.

BLE 6.2 can mark some input packets as “flushable”. If packet loss conditions delays them, BLE can drop the old ones instead of sending them late. Good for mice or MIDI, as the late updates feel worse than a missed one.

I recently read about the STM32V8 launch and it has pretty great specs. When you see that it has a 800 MHz on a Cortex-M with a 5,072 CoreMark, you know you are getting close to compute you normally see on embedded microprocessors(MPU) with an external DDR memory. ST positions STM32V8 as its flagship high-performance STM32 MCU.

The chip is built on 18nm FD-SOI plus embedded phase-change memory. FD-SOI is a chip process that reduces leakage current and helps push frequency without wasting as much power. It also integrates up to 4 MB of non-volatile memory and is specified up to an extreme 140°C junction temperature. The key part is the PCM.

Embedded phase-change memory (PCM) is a way to store bits without the floating gate used in Flash. The bit lives as resistance in a special material. When the material is in one phase it reads high resistance, and in the other phase it reads low resistance. Because the phase stays put when power is removed, it is non-volatile memory. You write to it by sending a short, shaped current pulse that heats the cell into the wanted phase.

This matters because embedded Flash does not scale nicely into newer chip process nodes. Resistive memories like PCM is the route most vendors take from around 28nm and below, mainly to avoid extra process complexity and cost. RRAM was another, I wrote about that one earlier in a post.

For firmware, PCM is not an infinite-write storage. The chip separates code and data profiles. Code can be around 1,000 write cycles with 10-year retention. Data can be up to 1,00,000 cycles with about 1-year retention at 140°C after cycling. This is actually great as realistically you wont have firmware changes that frequent in production. The practical benefit is you can keep more code, tables, and even small ML model weights on chip, and then buffer hot data in SRAM, the fast RAM that forgets its contents when power is off.

The new V8 chip seems to be in sampling mode currently by ST with elite customers like SpaceX because of the temp profile and radiation immunity claims.