标签：#embedded

Look inside almost any modern connected device -- a smartphone, a smartwatch, a Wi-Fi thermostat, a battery-powered sensor node -- and you will find a processor core designed by ARM. It is one of the most successful engineering ideas in computing history. And here is the strange part: ARM has never manufactured a single one of those chips. It does not own a factory. It sells blueprints. A three-person project in Cambridge The story starts at Acorn Computers in Cambridge, England, in the early 1980s. Acorn had built the BBC Micro, a hugely popular educational computer in the UK, and it needed a faster processor for its next machine. The commercial chips available at the time were disappointing, so a tiny team decided to design their own. The acronym everyone knows today originally stood for Acorn RISC Machine . Sophie Wilson designed the instruction set and wrote the simulator; Steve Furber led the physical chip design. RISC -- Reduced Instruction Set Computing -- was the key bet. Instead of piling on complex instructions, they kept the instruction set small and simple, which made the chip easier to build, cheaper, and remarkably power-efficient. The first silicon, the ARM1, was fabricated by VLSI Technology and delivered to Acorn on 26 April 1985. When the team powered it on, it simply worked -- first try. For anyone who has designed hardware, that is almost unheard of; new processors normally need several rounds of revisions to shake out design errors. A famous piece of Acorn lore is that the early ARM chips drew so little current they could keep running on leakage alone after the power was disconnected. From a British computer to the whole world Acorn the computer company faded, but the processor design did not. In 1990 the ARM team was spun out into a separate joint venture, and the acronym was quietly re-expanded to Advanced RISC Machines . The new company made a decision that defined its future: it would not build chips. It would license the designs and let oth

Ask most people to name the chip that started modern electronics and they will say the microprocessor. But there is a quieter hero inside almost everything you own that beeps, blinks, or connects to the internet: the microcontroller. And the first one you could actually buy shipped in 1974 as the Texas Instruments TMS1000. Microprocessor vs. microcontroller The distinction matters. A microprocessor, like Intel's famous 4004, is just the processing core. To build anything useful with it you still have to wire up separate memory chips, input/output controllers, and support logic on a circuit board. A microcontroller collapses all of that onto a single piece of silicon: the CPU, the ROM that holds your program, the RAM that holds your data, and the I/O pins that talk to the outside world, all in one package. That is exactly what the TMS1000 did. Designed by Texas Instruments engineers Gary Boone and Michael Cochran, it was a 4-bit device using a Harvard architecture, meaning it kept program memory and data memory in separate spaces so it could fetch an instruction and read data at the same time. One chip in, one chip out, and you had a complete tiny computer dedicated to a single job. Cheap enough to put in everything The genius of the TMS1000 was not raw power, it was economics. In 1974 you could buy the chips in volume for around two dollars each. By 1979, Texas Instruments was selling roughly 26 million of them every year. That price point changed what engineers could build. Suddenly it made sense to drop a small, programmable brain into products that never would have justified a full computer. You have almost certainly held one. The TMS1000 family ran the Speak & Spell, the Big Trak programmable toy vehicle, and the electronic memory game Simon, along with countless calculators, microwave ovens, and appliances. Each one was doing the same fundamental thing an IoT node does today: read some inputs, run a fixed program, drive some outputs. Why this still matters for

If you have ever wired a sensor to a Raspberry Pi or run your first Python script on one, you have used a device whose name hides two small jokes and one very deliberate design decision. Why is it called the Raspberry Pi? The short answer: "Raspberry" is a nod to a decades-old tradition of naming computers after fruit, and "Pi" is short for Python, the programming language the board was originally built to run. Both halves say something about where the machine came from, and why it went on to become a staple of IoT and embedded development. The fruit tradition behind "Raspberry" The "Raspberry" is not random. In the early decades of personal computing, a surprising number of companies named themselves after fruit. Apple is the obvious one, but there was also Acorn Computers (the British firm whose ARM architecture now sits inside nearly every phone and microcontroller on Earth), Apricot Computers, and Tangerine. When Eben Upton and his collaborators at the University of Cambridge set out to build a cheap computer to teach kids to code, choosing a fruit name placed the project squarely in that lineage. Upton has also cheerfully admitted the name is a bit of a pun, a wink at "blowing a raspberry" and at raspberry pie the dessert. Why "Pi" stands for Python The "Pi" is the part that reveals the machine's original purpose. As Upton has explained in interviews, the plan was to produce a computer that could really only run one thing well: Python. So the "Pi" in the name is a compressed reference to Python . It doubles neatly as a nerdy nod to the mathematical constant, but Python was the driving idea. That original intent matters because it explains the board's whole philosophy. The Raspberry Pi was never meant to be a powerhouse. It was meant to be cheap enough that a student could own one, simple enough that a beginner could learn on it, and open enough that it ran a full Linux operating system with Python ready to go. During development the design grew more capable tha

Every camera-equipped connected device you build today, from a smart doorbell to an ESP32-CAM streaming frames over Wi-Fi to a factory machine-vision rig, is a descendant of one clunky, toaster-sized prototype: the first digital camera , built at Eastman Kodak in December 1975. It weighed about 8 pounds, took 23 seconds to capture a single 0.01-megapixel black-and-white image, and recorded that image to a cassette tape. It looked like a science-fair project, but it proved a radical idea that underpins the entire IoT sensing industry: an image could be captured, digitized, and stored as data with no film at all. An engineer, a side project, and a CCD The camera was built by a 24-year-old Kodak engineer named Steven Sasson . His manager had handed him a loose assignment: could the newly invented charge-coupled device (CCD) image sensor be used to build a camera with no moving film? The CCD, developed at Bell Labs in 1969, converts light falling on an array of tiny capacitors into electrical charge, pixel by pixel. Sasson took a Fairchild 100-by-100-pixel CCD, bolted it to a lens from a Super 8 movie camera, added a digitizer, and wired the output to a portable cassette recorder. The result captured just 0.01 megapixels, a grid of 10,000 pixels. To view a photo, Sasson's team built a custom playback rig that read the tape and painted the image onto a television screen. That first image, a Kodak lab technician, took 23 seconds to write to tape and several more to display. Crude, yes, but it was the first fully electronic, filmless photograph. Why Kodak shelved the future Here is the twist that every embedded engineer should remember. Kodak owned the patent on the first digital camera, but the company made its money selling film, chemicals, and photo paper. Executives saw a filmless camera as a threat to that business, so the project was quietly set aside. Kodak did file the patent in 1978 and collected licensing revenue for decades, but it never led the digital transiti

When you first step into the world of embedded systems, one of the earliest and most consequential decisions you will face is choosing a programming language. Two names come up more than any others: Python and C++. Both are powerful, both have passionate communities, and both are genuinely useful — but for very different reasons and in very different contexts. This article is not about declaring a winner. It is about understanding why each language exists in this space, what trade-offs you are actually making, and how to make a confident, informed decision for your next project. Understanding the Fundamental Difference Before comparing features, it helps to understand why these two languages feel so different at a deeper level. C++ is a compiled, statically-typed, systems-level language . When you write C++, you are writing code that gets translated directly into machine instructions. You manage memory manually. You control exactly when objects are created and destroyed. The hardware does precisely what you tell it to, nothing more and nothing less. This directness is both its superpower and its source of complexity. Python, by contrast, is an interpreted, dynamically-typed, high-level language . A Python runtime sits between your code and the hardware, managing memory automatically through garbage collection, resolving types at runtime, and handling a lot of bookkeeping so you don't have to. This makes Python wonderfully expressive and fast to write, but it introduces overhead that matters enormously on constrained hardware. The mental model to hold onto is this: C++ gives you control, Python gives you speed of development . Both are valuable. The question is which one your project needs more. Where C++ Shines in Embedded Systems 1. Bare-Metal and Resource-Constrained Environments If you are programming a microcontroller like an STM32, an AVR ATmega, or an ESP32 running its native SDK, C++ is almost always your primary language. These devices often have kilobytes —

One of the most important ideas in modern wireless communication did not come out of a corporate research lab or a defense contractor. It was patented in 1942 by one of the most famous movie stars of the era, working alongside an avant-garde composer. The actress was Hedy Lamarr, and the technique she helped invent, frequency hopping , is a direct ancestor of the Wi-Fi, Bluetooth, and GPS signals your devices rely on every day. The patent Hollywood forgot At the height of her Hollywood fame, Hedy Lamarr was also a self-taught inventor who tinkered between film shoots. Early in World War II she became fixed on a hard problem: radio-controlled torpedoes were easy to jam, because an enemy who found the single control frequency could simply drown it in noise and send the weapon off course. Working with composer George Antheil, she designed a system where the transmitter and receiver would rapidly and secretly switch together across many different frequencies. Antheil, who had once synchronized sixteen player pianos for a concert piece, suggested using a slotted paper roll like a player piano to keep both ends hopping in step across 88 frequencies , the same number as the keys on a piano. On August 11, 1942, they received U.S. Patent 2,292,387 for a "Secret Communication System." The U.S. Navy filed the idea away and did not use it during the war. For decades the patent sat largely forgotten, and Lamarr received no money and little recognition for it in her lifetime. She was finally inducted into the National Inventors Hall of Fame in 2014, years after her death. What frequency hopping actually does The core insight is deceptively simple. Instead of putting a signal on one fixed frequency, you spread it across many frequencies in a pattern that only the sender and receiver know. Both ends "hop" in perfect synchronization, dwelling on each frequency for only a fraction of a second before jumping to the next. This buys you two enormous advantages. It is very hard to jam, b

If you have ever wired up a cellular modem, a WiFi module, or a Bluetooth radio and typed something like AT+CGMR into a serial terminal, you have used a command language that is older than most of the engineers using it. The humble AT command set that still configures a huge share of today's connected hardware was born in 1981 , with a device called the Hayes Smartmodem. Four decades and billions of devices later, it refuses to die, and that longevity has a lesson in it for anyone building embedded systems. What AT actually stands for When Dennis Hayes and his company released the Hayes Smartmodem 300 in 1981, they faced a small but real design problem: how does a computer tell a modem the difference between a command to the modem and data to be sent down the phone line ? Their answer was an attention sequence. Every command line began with the two letters AT , short for attention , which told the modem to wake up and listen to what followed. ATD dialled a number, ATH hung up, and so on. It was readable, it was easy to implement on the microcontrollers of the day, and crucially you could type it by hand to debug a link. That simplicity is exactly why it spread. Competing modem makers cloned the Hayes command set to stay compatible, it became a de facto industry standard, and later it was formally captured in telecom standards. A convention that started as one company's pragmatic shortcut turned into the lingua franca of getting a device onto a network. From phone lines to the Internet of Things Here is the part that surprises people. The AT command set never retired when dial-up modems did. It quietly migrated into the components that make modern IoT possible. Cellular modules that put a device on a 4G or LTE network, from vendors like Quectel, SIMCom, and u-blox, are almost universally driven by AT commands. Classic Bluetooth and many WiFi modules expose an AT interface too. Even the ESP8266 and ESP32, the microcontrollers behind an enormous number of hobby and com

Memory Chips Supply chain strategy from electronics production engineering, 500–50k units/year Introduction "Order from Digi-Key" is a prototyping strategy, not a production strategy. The 2020–2023 IC shortage demonstrated that supply chain resilience must be designed in — not improvised when lead times hit 52 weeks. The Sourcing Tier Structure Tier Examples MOQ Price Premium Lead Time Risk Authorized dist. Digi-Key, Mouser, Newark 1 pc +25–40% 1–3 days (stock) Lowest Franchise dist. Arrow, Avnet, TTI 100–1k Baseline 2–8 weeks Low Manufacturer direct TI, Infineon, ST portals 1k–10k+ −10 to −30% 8–20 weeks Low Regional aggregators IC-Online, local dist. Mixed Variable Variable Medium Spot market Brokers, eBay 1 pc +50 to +500% Days High Never use spot market for ICs without incoming inspection. Counterfeit STM32, ESP32, and common analog ICs are well-documented. Volume Pricing Reality Illustrative for a $2.50 MCU: Volume Digi-Key Arrow/Avnet Manufacturer Direct 100 $3.10 $2.65 N/A 1,000 $2.75 $2.15 $1.85 10,000 $2.40 $1.70 $1.25 50,000 $2.10 $1.40 $0.90 The franchise/direct savings are material at 1k+ units. Establishing Arrow or Avnet relationships pays for the admin overhead within 2 production cycles. BOM Resilience Framework For each critical component, document: Primary source : authorized distribution or direct Secondary distributor : alternative channel for same part Alternate part : functionally equivalent, different manufacturer, validated Buffer stock : target weeks at production rate Lead time worst-case : historical peak, not current During normal periods: 4-week buffer, one secondary source, one qualified alternate. For 5+ year product lifecycles: qualify the alternate before you need it. Practical Sourcing Mix: 500–5k Units/Year Component Type Primary Secondary Notes Commodity passives Digi-Key/Mouser + Yageo/Walsin Arrow Annual pricing agreements MCUs < $3 Arrow direct IC-Online for gap fills 90-day POs, buffer stock MCUs $3–$10 Manufacturer direct + A

A device that resets in the field is not always the hardest problem. The harder problem is a device that resets, comes back online, and leaves no evidence about what happened before the reboot. That is where a firmware black box becomes useful. This is the DEV.to edition of a Silicon LogiX technical article. The canonical English source is linked at the end. What a firmware black box is A firmware black box is a small diagnostic subsystem inside the firmware. Its job is to preserve enough information to support post-mortem analysis after a reset, watchdog event, HardFault, panic or unexpected reboot. It does not need to record everything. It needs to record the data that helps answer the first diagnostic questions: why did the device reset? how long had it been running? which firmware build was installed? what state was the application in? which task was active? did the watchdog fire? did memory, stack or heap margins collapse? did the network, modem, BLE, Wi-Fi or OTA flow fail just before the reboot? Without that data, every field reset deletes most of the evidence. Why sporadic resets are expensive Rare embedded bugs are often more expensive than obvious failures. A crash that happens every time in the same function can usually be analyzed with a debugger, logs and a repeatable test. A reset that appears once every ten days on a customer device is different. The cause may depend on a combination of: temperature unstable power brown-out cable length enclosure heating network drops modem state memory fragmentation stack exhaustion long uptime race conditions a peripheral that stops responding an OTA edge case In the lab, the product may look clean. In the field, the environment changes. The customer report often becomes: "it rebooted", "it stopped communicating", or "we had to power-cycle it". That is not enough for firmware diagnosis. What to capture A good first version does not need to be large. Start with a compact structure that survives the next boot: reset r

Look at almost any piece of electronics on your desk and you will find a small light staring back at you. A router with a row of blinking status lights. A power brick with a steady green dot. A development board with a tiny red point that flickers every time it does something. We barely notice these lights anymore, but each one descends from a single laboratory breakthrough in 1962, when an engineer at General Electric coaxed a sliver of semiconductor into glowing visible red for the first time. Who invented the first visible LED The engineer was Nick Holonyak Jr., a consulting scientist at General Electric's lab in Syracuse, New York, and a former student of John Bardeen, one of the inventors of the transistor. On October 9, 1962, Holonyak demonstrated the first practical visible-spectrum light-emitting diode. It emitted red light, and it worked at room temperature, which made it genuinely useful rather than a laboratory curiosity. What made his approach different was the material. Other researchers in the early 1960s were building diodes that emitted infrared light, which is invisible to the human eye. Holonyak gambled on a different alloy, gallium arsenide phosphide, and it paid off with the first light a person could actually see coming out of a semiconductor. He was so confident in the idea that he predicted LEDs would one day replace the incandescent bulb. At the time that sounded outlandish. Today it is simply how lighting works. Why a tiny red light mattered so much The incandescent bulb that Thomas Edison commercialized makes light by heating a filament until it glows. That is wildly inefficient, because most of the energy escapes as heat rather than light, and the filament eventually burns out. An LED works on a completely different principle. When current flows across a specially engineered semiconductor junction, electrons release their energy directly as photons. There is no filament to burn out, almost no wasted heat, and the device can switch on and o

Why 40V Input and 500mA Output Matter in Noise-Sensitive Designs You’ve probably fought a power rail that looked clean on a multimeter but still trashed your 24‑bit ADC readings. The culprit is rarely the DC level—it’s the broadband noise, switching artifacts, and line‑frequency ripple that ride on top. In precision analog, RF, and sensor signal chains, even 50 µV of supply noise can bury a 1 mV sensor signal or degrade an RF PLL’s phase noise by 10 dB. The MAX20151R addresses this head‑on with a combination that’s hard to find in a single LDO: a 40 V input range, 500 mA output drive, and just 6.5 µV RMS output noise (10 Hz–100 kHz). That wide input headroom lets you power sensitive circuitry directly from a 12 V or 24 V industrial rail, an automotive battery, or a noisy intermediate bus without a pre‑regulator. You eliminate an entire buck converter stage, saving board space and avoiding the switching noise that would otherwise require heavy filtering. The 500 mA output current is equally important. Many ultra‑low‑noise LDOs top out at 200 mA or 300 mA, forcing you to split rails or add a discrete pass transistor. With 500 mA, the MAX20151R can comfortably supply a mixed‑signal chain—an MCU, a precision ADC, a low‑jitter clock, and a handful of op‑amps—from a single quiet rail. And because the device maintains its noise performance across the full load range, you don’t have to derate your noise budget as current increases. Field experience shows that transient events on 24 V vehicle buses can easily exceed 40 V during load dump. The MAX20151R’s 40 V absolute maximum input rating, combined with integrated reverse‑voltage protection down to –40 V, gives you a robust front end that survives those spikes without external clamping. This is a practical necessity for any design that must pass ISO 7637‑2 or similar automotive transients, and it’s a key reason engineers are migrating from lower‑voltage LDOs to the MAX20151R in harsh electrical environments. Key Takeaway: If

Ask someone to name the most manufactured object in human history and you will hear guesses like the nail, the brick, or maybe the smartphone. The real answer is something almost nobody can name out loud: the MOSFET. This tiny transistor, invented at Bell Labs in 1959, is the on/off switch inside every microprocessor, memory chip, and connected sensor. An estimated 13 sextillion of them have been built since 1960, making the MOSFET not just the foundation of modern electronics but the most-produced artifact our species has ever made. What a MOSFET actually is MOSFET stands for metal-oxide-semiconductor field-effect transistor. Strip away the jargon and it is an electrically controlled switch with no moving parts. A small voltage on one terminal, the gate, controls whether current can flow between the other two. Billions of these switches flipping on and off billions of times per second is, quite literally, what computation is. The genius of the design is that it scales: shrink the transistor and you can pack more of them onto a chip while using less power per switch, the trend that drove decades of Moore's law. The breakthrough came from two engineers at Bell Labs, Mohamed Atalla and Dawon Kahng, who fabricated the first working MOSFET in 1959. Their key insight was using a thin layer of silicon dioxide, ordinary glass, to insulate the gate from the silicon underneath. That oxide layer turned out to be the unlock that made silicon the dominant material in electronics, edging out the germanium used in the very first transistors of the late 1940s. Why it beat every earlier transistor The point-contact transistor demonstrated in 1947 and the integrated circuit of 1958 were both monumental, but neither was easy to mass-produce by the standards we take for granted today. The MOSFET was different. It was simpler to fabricate at scale, drew far less power in its complementary (CMOS) configuration, and lent itself to the photolithographic processes that let manufacturers pr

The Internet of Things is now a phrase you see on product boxes, in boardroom slide decks, and across thesis titles in engineering departments everywhere. But it has a surprisingly precise origin. The term was coined in 1999 by a British technologist named Kevin Ashton, and it was not born in a research lab or an academic paper. It started its life as the title of a corporate sales presentation. A slide deck, not a laboratory In the late 1990s Ashton was a brand manager at Procter & Gamble, the consumer goods giant behind products you would find on any supermarket shelf. He was wrestling with a mundane but expensive problem: store shelves kept running out of a particular shade of lipstick, even though the warehouse had plenty in stock. The supply chain simply had no reliable way to know, in real time, what was where. Ashton's proposed fix was radio-frequency identification, or RFID: tiny tags that could be attached to products and read automatically by sensors, with no human scanning each item by hand. The vision was that physical objects could report their own location and status, feeding that data up into computer systems without anyone typing it in. To sell this idea to executives, he needed a title that would make supply-chain tagging sound as exciting as the technology dominating headlines at the time. So he linked his RFID proposal to the hottest topic of 1999 and called the presentation "Internet of Things." By his own account, years later in RFID Journal, the choice was deliberate. Tying tags and sensors to the red-hot word "internet" was the surest way to get senior people in the room to pay attention. The pitch worked well enough that the phrase stuck, and Ashton went on to help found the Auto-ID Center at MIT, a research group that did much of the early standards work that made networked RFID practical. Why the name was actually a good description It would be easy to dismiss the term as a marketing flourish, but it captured something real. Ashton's point

Almost everything that makes the modern world hum, from the phone in your pocket to the sensor on a factory floor, traces back to a single quiet afternoon in a nearly empty laboratory in Dallas. In the summer of 1958, a newly hired engineer named Jack Kilby built the first working integrated circuit at Texas Instruments. It was a crude little thing, a sliver of germanium with a few components and some fine gold wires, but it carried an idea that would reshape electronics: that an entire circuit could be made from one piece of semiconductor material. Every microcontroller and connected device we build today is a descendant of that prototype. The engineer who was left behind Kilby had only just joined Texas Instruments and had not yet earned any vacation time. So when the company shut down for its traditional summer break in July 1958 and most of his colleagues left, he found himself nearly alone in the lab with time to think. The problem on his mind was one the whole industry called the "tyranny of numbers." Circuits were getting more capable, which meant more transistors, resistors, and capacitors, each one a separate part that had to be wired together by hand. Every added component meant more connections, more soldering, and more chances for something to fail. The complexity was becoming a wall. Kilby's insight was disarmingly simple. If resistors and capacitors could be made from the same semiconductor material as transistors, then every part of a circuit could be fabricated together in a single block. No separate components, no forest of hand-soldered wires. He sketched the idea, and when his managers returned he had something to show them. September 12, 1958 On September 12, 1958, Kilby demonstrated his prototype to Texas Instruments executives. The device was a phase-shift oscillator built on a bar of germanium, with its elements connected by delicate gold "flying wires." He connected it to an oscilloscope, flipped the switch, and a steady sine wave rolled acro

The first text message ever sent was not a love note, a meeting reminder, or a meme. It was a Christmas greeting. On December 3, 1992, a 22-year-old engineer named Neil Papworth sat at a desktop computer, typed two words, and sent the world's first SMS to a mobile phone: "Merry Christmas." More than thirty years later, that humble two-word message has grown into one of the most quietly important protocols in connected technology, and it still shows up in the IoT devices we build today. The engineer who sent the first SMS Neil Papworth was working for the Anglo-French firm Sema Group Telecoms, part of a team building a Short Message Service Centre (SMSC) for the British carrier Vodafone. The SMSC was the piece of infrastructure that would store and forward text messages across the cellular network. To prove it worked, Papworth sent a test message from a computer terminal to the Orbitel 901 handset of Richard Jarvis, a Vodafone director who was at a company Christmas party. The message arrived. Jarvis read it. But he could not reply, because mobile phones at the time had no way to compose a text. There was no keypad-driven messaging app, no T9, no touchscreen. SMS started life as a one-way novelty riding on a spare slice of the network's signalling channel, and almost nobody involved thought it would matter very much. Why SMS was designed the way it was The technical detail that makes this story relevant to anyone building connected hardware is how SMS was engineered. Text messages were squeezed into the control channel that phones already used to talk to cell towers, the same channel that handles things like call setup. That is why a single SMS is capped at 160 characters: it had to fit inside a small, fixed-size signalling packet. This constraint turned out to be a feature. SMS is lightweight, store-and-forward, and works even when a data connection is weak or absent. The message waits in the SMSC until the device is reachable, then gets delivered. No persistent con

Dalla libreria embedded che ha invaso ogni dispositivo a un’implementazione moderna con concorrenza, async I/O e vector search: cosa cambia davvero per chi sviluppa app. Nel frontend e nel full‑stack capita spesso di parlare di database come servizi: Postgres gestito, cluster, repliche, connessioni, pooling, credenziali e una lunga lista di “cose che possono rompersi”. Ma esiste un’altra filosofia, più vicina all’idea di “dipendenza” che di “infrastruttura”: un motore SQL che vive dentro l’applicazione. Questa è la ragione per cui SQLite è ovunque. È una libreria, non un server. Legge e scrive su un singolo file su disco. Riduce drasticamente configurazione, porte, processi separati e complessità operativa. Ed è proprio questa semplicità a renderla una delle fondamenta silenziose dell’informatica moderna: la usi in browser, smartphone, desktop app, tool CLI, IoT… spesso senza nemmeno accorgertene. Ora immagina di riscrivere tutto da capo, in Rust, cercando di essere compatibile al 100% e allo stesso tempo più “moderna”. Sembra un’idea folle per definizione—finché non inizi a guardare ai limiti pratici che oggi emergono in molte applicazioni. Perché toccare SQLite, se funziona così bene? SQLite non è “il problema”. Anzi: è considerata estremamente robusta perché è conservativa, minimalista, e custodita con un rigore quasi maniacale. Il punto è un altro: il suo modello di sviluppo e manutenzione è atipico rispetto a quello che molti intendono per open source collaborativo . Il codice è disponibile e utilizzabile liberamente, ma l’evoluzione è guidata da pochissime persone e—di fatto—non segue la dinamica classica delle contribution esterne. Questa scelta ha un effetto collaterale positivo: riduce il rischio di regressioni introdotte da cambiamenti non coerenti con la visione del progetto. Ma ha anche un costo: se la tua azienda o il tuo prodotto hanno esigenze nuove (concorrenza più spinta, I/O non bloccante, funzionalità specifiche), “aspettare che arrivi upstream” n

Every developer who has ever muttered "there is a bug in this" is repeating a word with a surprisingly literal origin. On September 9, 1947, the operators of the Harvard Mark II, an early electromechanical computer, traced a malfunction to its source and found something they did not expect: a moth wedged inside Relay #70. They removed the insect, taped it into the operations logbook, and wrote a now-famous line beside it: "First actual case of bug being found." That page, moth and all, survives today in the collection of the Smithsonian's National Museum of American History. It is one of the best-loved stories in computing, and like most good stories it is a little more complicated than the popular version. Worth getting right, because the discipline it gave us is the same one behind every connected device we build. What actually happened in 1947 The Mark II was a room-sized machine built from relays, switches, and thousands of moving parts. When a moth flew into one of those relays, it physically interfered with the contacts and caused a fault. The technicians who found it had a sense of humor: calling it the "first actual case of bug being found" was a joke precisely because engineers had already been using "bug" for years to describe mysterious faults in machinery. Thomas Edison used the term in his notebooks back in the 1870s. So the 1947 moth did not invent the word "bug." What it did was give the term a perfect, photographable origin story, and it cemented the companion word that really matters: debugging. The act of removing that moth was, quite literally, de-bugging the computer. The Grace Hopper connection The story is almost always told with Grace Hopper at its center, and that deserves a small correction. Hopper, a pioneering computer scientist who later helped develop COBOL, was part of the Mark II team in 1947, but the evidence suggests she did not personally find the moth or write the logbook entry. What she did do was tell the story, brilliantly and o

Every connected device on your desk, from a smart plug to a fitness band to a hobbyist ESP32 board, runs on a descendant of one tiny chip that was never meant to change the world. In 1971, Intel released the 4004, the first commercially available microprocessor. It was not built for computers, robots, or the internet. It was built to run a desk calculator. The story of how a calculator chip became the foundation of modern IoT is one of the most instructive in all of electronics. A calculator contract that got out of hand The 4004 began as a job for hire. A Japanese calculator company called Busicom approached Intel in 1969 wanting a set of custom chips for a new line of printing calculators. The original plan called for around a dozen separate, purpose-built integrated circuits, each wired to do one fixed task. It was the standard approach of the era: if you wanted a device to do something, you designed silicon that did exactly that and nothing else. Intel engineer Ted Hoff looked at the sprawling design and proposed something radical. Instead of a pile of single-purpose chips, why not build one general-purpose processor that could be told what to do through software? A program stored in memory could make the same chip behave like a calculator today and something else entirely tomorrow. Stanley Mazor helped shape the architecture, and a newly arrived engineer named Federico Faggin turned the concept into a working device, inventing the silicon-gate design techniques that made it physically possible. Masatoshi Shima, Busicom's representative, worked alongside them on the logic. 2,300 transistors that started everything When the 4004 was announced on November 15, 1971, it packed about 2,300 transistors onto a single sliver of silicon. By modern standards that is almost nothing; a current smartphone chip holds tens of billions. But the leap was not about raw count. It was about the idea. For the first time, a complete central processing unit existed on one chip that an

Every FreeRTOS project I've worked on has the same problem. You have a sensor task that reads temperature. You have a UI task that needs to display it. So you create a QueueHandle_t, pass it to both tasks at init, call xQueueSend on one side and xQueueReceive on the other. Fine. Then you add a WiFi task that also needs temperature. You add another queue. Then a logging task. Another queue. Soon your app_init() is a mess of queue handles being passed around, and changing one task means touching everything it's connected to. On bare metal it's the same story in a different shape — a dozen global flags in main: if (flag_sensor) ... if (flag_button) ... if (flag_timer) ..., each one added as the project grows, none of them easy to trace back to where they're set. On embedded Linux it's pointers — modules holding direct references to each other, so a change in one ripples everywhere. I wanted one solution that works across all three without rewriting the dispatch logic every time. embedmq collapses it to 3 functions: embedmq_register(q, "sensor.temp", on_temp, NULL); // subscriber embedmq_post(q, "sensor.temp", &data, sizeof(data)); // producer, any thread/task No shared queue handles. No global flags. No direct pointers between modules. The library handles the ring buffer, the mutex, and the semaphore wakeup. Same API, three platforms: Linux: pthread + POSIX semaphore, zero external dependencies FreeRTOS: counting semaphore + xTaskCreate, static mode for zero heap after init Bare-metal: C11 atomic spinlock, drive dispatch with embedmq_poll() from your superloop FreeRTOS PAL is verified on the POSIX simulator in CI — not real hardware yet, I'll be honest about that. GitHub: https://github.com/w4ysonch/embedmq Happy to answer questions about the design or the FreeRTOS porting details.

You scan one to pay at a sari-sari store, pull up a restaurant menu, or board a flight. The QR code has quietly become one of the most universal pieces of interface design on the planet. But it was never meant for any of that. The QR code was invented in 1994 to solve a very specific problem on a Japanese car factory floor, and the engineering decisions made under that constraint are exactly why it later conquered the world. A barcode problem on the assembly line In the early 1990s, Toyota's manufacturing arm had a data problem. Tracking thousands of distinct components through production meant scanning barcodes, and barcodes are stingy: a standard one-dimensional barcode holds roughly 20 characters. Workers were ending up with parts plastered in ten or more barcodes just to encode enough information, and each one had to be scanned separately. It was slow, and on an assembly line, slow is expensive. Masahiro Hara, an engineer at Denso Wave, a Toyota subsidiary, took on the challenge of designing something better. He wanted a code that could hold far more data, be read much faster, and tolerate the dirt, smudges, and odd angles of a real factory rather than a clean lab. Designing for speed and any angle The breakthrough was going two-dimensional. By encoding data in a grid of black and white squares rather than a single row of lines, Hara's team could pack in thousands of characters instead of a few dozen. The name they chose, QR for "Quick Response," was a direct promise about scanning speed. The most recognizable feature of a QR code, the three large squares in its corners, solves the hardest part of the problem: letting a scanner instantly find the code and work out its orientation no matter how the part is turned. Hara's team analyzed printed material to find a black-and-white sequence that almost never occurs naturally in text and images, and settled on a ratio of 1:1:3:1:1 for those corner markers. Because that pattern is so rare in everyday print, a scanner ca