MicroUI is a tiny, portable, immediate-mode UI library written in ANSI C.

• Tiny: around 1100 sloc of ANSI C
• Works within a fixed-sized memory region: no additional memory is allocated
• Built-in controls: window, scrollable panel, button, slider, textbox, label, checkbox, wordwrapped text
• Works with any rendering system that can draw rectangles and text
• Designed to allow the user to easily add custom controls
• Simple layout system

See this open source MIT licensed software on GitHub.

When talking about large language models (LLMs), people usually imagine a general-purpose assistant: something that can answer questions about weather, politics, software, history, travel, cooking, electronics – and almost any other topic. The model is expected to know a little bit about everything, follow open-ended conversations, and respond to a very broad range of prompts. That’s the experience most of us are used to, since cloud-based AI tools have become so widespread.

Embedded systems work in a much more “narrow” world. A robot does not need to discuss politics, an inspection system does not need to suggest vacation destinations, and a maintenance assistant installed near a machine does not need to explain ancient history. The system needs to understand the device, the task, the possible commands, the local data, and the actions that are safe to suggest or execute. The goal is to give an edge device enough language intelligence to become more useful, more understandable, and more independent from the network.

This is the framework in which we can think about local LLMs on UNO Q: a practical platform to explore this idea because it brings together a Debian Linux environment and the Arduino^® hardware ecosystem. The Linux side can run local AI tools, command-line workflows, Python applications, web services, and inference runtimes. The Arduino side connects that intelligence to sensors, actuators, shields, Arduino^® Modulino nodes, and real-world signals. This combination makes it possible to experiment with language models not as isolated chatbots, but as part of real embedded workflows.

The most important question to consider is not how to force a large model to run, but what kind of useful intelligence can live close to the data, close to the device, and close to the physical action?

Step 1: choose the right model for your use case

The edge is where smaller, optimized models become interesting. On the cloud, a large general-purpose model makes sense because it is expected to answer almost anything. On the edge, a model that has been trained, fine-tuned, distilled, or quantized for a specific domain can be more practical. It carries less unnecessary weight, focuses on the type of language the device actually needs, and can be integrated into a controlled application flow.

For example, in robotics the interaction can often be reduced to a limited set of useful instructions: move forward, stop, inspect this object, return to base, report battery level, explain the last error, switch to manual mode. The model can help interpret natural language, but the system should still map that interpretation to a controlled set of valid commands. This makes the behavior easier to test, easier to validate, and easier to trust.

That narrower scope is one of the reasons local LLMs can make sense on embedded platforms.

Step 2: understand your memory and storage constraints

A large language model usually has many parameters, and every parameter represents data that must be stored, loaded, and processed during inference. Model weights are only part of the story. During generation, the runtime also needs working memory for the prompt, the intermediate computation, and the key-value cache used by transformer models to keep track of previous tokens. As the context grows, memory usage grows too.

A 1B-parameter model in 4-bit quantization (such as Llama 3.2 1B Q4) occupies roughly 600–700 MB on disk and requires around 1 GB of RAM at runtime, including the KV cache for a short context window. A 3B model at the same precision pushes past 2 GB. These are numbers that matter on a board with fixed memory and storage, where the model must coexist with the OS, the runtime, and the rest of the application.

Quantization is one of the techniques that makes this more realistic. Instead of storing model weights with high-precision numerical values, a quantized model uses lower-precision representations. This reduces memory usage and can make inference possible on hardware that would otherwise be too constrained. In practical terms, quantization helps move a model from “too large to run locally” towards “small enough to experiment with” – while accepting a trade-off in accuracy, fluency, or speed depending on the model and runtime.

Model distillation is another important concept. In simple terms, distillation is a training approach where a smaller model learns from a larger teacher model. The goal is to keep useful behavior while reducing inference cost and memory footprint. A distilled model will not have the full breadth of the teacher, but it can be much more suitable when the application needs a focused capability on-device.

This example of running local LLMs and VLMs on UNO Q with yzma expands the conversation beyond text chat and explores local LLM and VLM workflows using yzma and llama, pointing toward a wider class of edge AI experiments where language models can work together with images, local data, and device context.

Step 3: identify where a local LLM adds real value

Local LLMs become even more useful when they are combined with other edge workflows. OCR is a good example. A camera connected to an UNO Q may extract text from a label, display, document, or machine interface. A compact language model can then summarize that text, classify it, or turn it into a structured response. The model only needs to process the relevant context, which keeps the workflow lighter and more focused.

The same principle applies to an UNO Q that collects logs, sensor readings, error states, or system events. A local model can turn that information into a short human-readable summary directly on the device. For a technician, this can transform raw data into something immediately useful – a compact explanation of the current status or a short description of the last error condition.

Step 4: design the architecture and set your boundaries

One of the most practical ways to think about local LLMs on UNO Q is to treat the model as an occasional reasoning layer. It can be called when language understanding, summarization, or interpretation adds value. Fast control loops, continuous monitoring, and timing-critical actions remain better suited to deterministic software running on the appropriate side of the system.

When working with local LLMs on UNO Q, developers should take into consideration a few practical parameters. Memory usage comes first: the model must fit comfortably together with the runtime and the rest of the application. Response latency comes next: a model that runs may still feel too slow if the use case expects instant answers. Storage should also be planned carefully, because model files and dependencies can be large.

The best entry point is the Arduino Project Hub tutorial Local LLM AI Chatbot on UNO Q, which walks through installing a small LLM and running it offline. It is a useful starting point because it demonstrates the basic shape of a local LLM application

There is also a natural bridge toward local agents. Agentic workflows can move beyond a simple chat interface and start coordinating tools, files, scripts, and actions. On UNO Q, this direction is especially interesting when the agent is treated as an orchestrator on the Linux side. It can inspect logs, prepare files, call scripts, interact with local tools, or help drive development workflows, while the hardware-facing layer keeps direct control over physical I/O.

This kind of setup requires clear boundaries. Giving an agent access to tools means giving it the ability to change things, so the environment should be designed carefully. A dedicated board can be a useful sandbox for this type of experimentation, with limited credentials, limited data access, and a specific set of allowed tools. This makes it possible to explore agentic workflows while keeping the system understandable and controlled.

If you prefer a familiar developer workflow, Installing Ollama on Arduino UNO Q covers a practical detail that matters a lot on embedded Linux systems: how to efficiently manage the resources available on the UNO Q to get the most out of it.

Step 5: run it, measure it, iterate

Pick one model, run it on the board, and pay attention to memory usage and response time for your specific prompt. That real-world data will tell you more than any benchmark – and it will give you a much clearer picture of where a local LLM fits in your next embedded project.

Local LLMs on UNO Q always balance power, cost, size, latency, privacy, reliability, and connectivity. The most interesting question is how much useful intelligence can be placed close to the data, the hardware, and the user. Because edge AI is not about more power. It’s about smarter choices. With the right model, the right architecture, and the flexibility of UNO Q, you can test local AI where it matters most: on real hardware, in real projects.

Start building with UNO Q and bring your AI ideas closer to the real world.

UNO Q is available to order from DigiKey, Farnell,Mouser, Newark, RS Components, and Robu.in; along with our other authorized distributors and resellers.

Arduino and UNO, and the Arduino logo are trademarks or registered trademarks of Arduino S.r.l.

The post Running local LLMs on the Arduino® UNO Q board: a practical guide appeared first on Arduino Blog.

BytePack is a header-only C++17 Arduino library for serializing plain C++ structs into compact, portable byte buffers.

A message is any struct that lists its fields in a single io() member function; that one function drives serialization, deserialization and compile-time size counting, so the field list is written once and can never get out of sync.

The wire format is explicit little-endian with no padding, making it safe to exchange between different architectures (ESP32, ARM, a PC on the other end of a link, etc.). All buffers are caller-provided and statically sized; there is no dynamic memory allocation.

See this new open source, MIT licensed project on GitHub.

All airplane engines have the same basic goal, which is to create forward thrust. But the modern airline industry is an exercise in maximizing efficiency and the most efficient option for large aircraft tends to be a turbofan jet engine. Most of us never get to see those up close, but you can 3D print this wildly complex and partially functional turbofan jet engine model to see how they work.

This isn’t an exact scale replica of any specific engine, but it was heavily inspired by the CFM56-5 series of engines used in Airbus A320 jets. Referencing that actual engine design, CADLY’s Adrian Barsotti modeled this engine to be a good compromise between accuracy and 3D printing practicality. There are even two variations: a complete engine and just the turbofan assembly on a stand.

The complete engine has panels you can open up to see the inner workings, while the turbofan assembly gives you an unobstructed view of the good stuff all the time.

Both models are entirely 3D-printable, with the exception of some hardware, fasteners, and electronic components. Those electronic components bring the engine to life, so you can spin up the fans and actuate the reverse thrust flaps.

Those work thanks to an Arduino Nano board, which controls the main DC motor through an L298N dual H-bridge driver and opens the flaps with servo motors. Power comes in at 5V and there is a DC-to-DC converter for the 12V components. Wago connectors make the wiring easy and tidy.

If you want to print this model yourself, you can find all of the files over on Printables. 

The post You can 3D print this amazingly complex turbofan jet engine model appeared first on Arduino Blog.

If you want some very cold air, you’re going to have to dive deep into thermodynamic wizardry to find a practical way to get it. Hyperspace Pirate did that digging and discovered the Gifford-McMahon cryocooler design. That is just simple enough that Hyperspace Pirate was able to build his own cryocooler using 3D-printed parts and an Arduino.

You may have noticed that air compressors get very hot when you run them. Conversely, compressed air gets pretty cold when you release it. Compression increases temperature, while expansion lowers temperature. 

If you were to repeat the compression and expansion cycle over and over, you’d end up with a net increase in temperature due to inefficiency. But a Gifford-McMahon cryocooler “cheats’ by separating the cold part of the system from the hot part of the system. It consists of a chamber within a piston inside, which moves back and forth to move air to the cold side or hot side (input comes from an external air compressor). The piston is hollow and filled with material that readily transfers and retains heat (lead shot in this case), which helps with the transition between sides. 

The result is progressive net cooling of the air inside — though the air outside gets warmer.

Hyperspace Pirate built his Gifford-McMahon cryocooler on a budget. It is really just a cylinder with a piston inside. But it is sealed, so an external actuator moves the piston with magnets. An Arduino UNO Rev3 controls the rotation of a stepper, translated into linear motion to move the cylinder in and out. Originally limit switches detected the ends of the stroke, but Hyperspace Pirate switched to Hall effect sensors. Because he used an Arduino, Hyperspace Pirate was able to time the piston movement to match the opening of the cylinder’s valve.

With this approach, Hyperspace Pirate reached temperatures as low as -70°C. That isn’t quite cryogenic, but it is very cold. It would have been possible to go lower with very dry air (or another gas), but those temperatures caused ice to build up and stall the system.

Even so, -70°C is very impressive and useful for all kinds of work, which is great for such a low-cost cryocooler.

The post This cryocooler was made using 3D-printed parts appeared first on Arduino Blog.

Linus Torvalds has just released Linux 7.1 on LKML: So it’s only Sunday morning back home, but it’s Sunday afternoon where I am right now, so I’m doing the 7.1 release at the regular time – just not in the regular timezone. This obviously means that the merge window opens tomorrow, but I’ll be in yet another timezone by then, so timing will all be a bit irregular. Normally I try to front-load the merge window and do as much as possible the first few days – this time I’m not sure that will work out with my laptop and a couple of long flights without internet, but I’ve made sure that I have fetched the early pull requests (thank you – you know who you are), so I will be able to do some of it off-line. Anyway, possible slight hiccups in the merge window aside, the news today [...]

The post Linux 7.1 Release – Main changes, Arm, RISC-V, and MIPS architectures appeared first on CNX Software - Embedded Systems News.

M5Stack Capsule v1.1 is a Stamp-S3A-based IoT controller with a microSD card slot, several sensors (6-axis IMU, microphone),  an IR transmitter, a built-in 250 mAh battery, a few buttons, a buzzer, an RTC, and expansion capabilities through GPIO headers and a Grove connector. It’s an upgrade to the earlier Capsule based on the Stamp-S3 module. The new version still features an ESP32-S3 WiFi and Bluetooth microcontroller, 8MB flash, a USB-C port, and a few GPIOs, but benefits from the Stamp-S3A improvements, including an optimized antenna design and lower power consumption. We never had a look at the Capsule before, so let’s do it now. M5Stack Capsule v1.1 specifications: M5Stack Stamp-S3A module WiSoC – Espressif Systems ESP32-S3FN8 CPU Dual-core 32-bit Xtensa LX7 microcontroller with AI vector instructions up to 240MHz RISC-V ULP co-processor Memory – 512KB SRAM Storage – 8MB flash Wireless – 2.4GHz WiFi 4 (802.11b/g/n), Bluetooth 5.0 LE + [...]

The post M5Stack Capsule Kit v1.1- A Battery-powered ESP32-S3 IoT controller with IMU sensor, MEMS microphone, and IR transmitter appeared first on CNX Software - Embedded Systems News.

Most developers reach for a single-board computer, only to discover they still need a microcontroller for real-time I/O. Then they need eMMC and extra storage. Then a separate AI accelerator. Then comes the custom wiring nightmare just to make everything talk to each other. As your app grows, you find yourself stacking extra boards, external controllers, and shaky communication links. The bill of materials skyrockets, and the integration headaches follow, all just to bridge the gap between Linux computing and real-time control.

UNO Q starts where that frustration ends. One board. Qualcomm Dragonwing QRB2210 Linux-capable processor. Real-time STM32 MCU. Qualcomm^® Adreno GPU 3D graphics accelerator. Forget unreliable SD cards with the built-in 32GB eMMC. It’s simple: one board, double the value.

When you can slash system complexity right out of the box, you instantly accelerate your development pipeline and cut down your total deployment costs. No extra fluff, just pure efficiency.

Let’s look under the hood: here are four reasons why UNO Q completely crushes overpriced, complicated hardware with a single, unified platform.

#1 Expect more from the right board

Many modern applications need two very different kinds of computing. On one side, there is the need for AI inference, computer vision, networking, data processing, and cloud connectivity, which all benefit from a Linux environment running on a powerful application processor. On the other side, there are sensors, actuators, motors, industrial signals, and timing-critical tasks that require deterministic real-time control.

Traditionally, developers solve this challenge by combining multiple boards and creating custom communication layers between them. UNO Q puts both worlds on the same board. The Linux MPU handles AI, vision, and data. The STM32 MCU handles sensors, actuators, and timing. They work together – and you don’t even need to design and debug the communication layer.

Of course there is value in having “two boards in one”. But there is potentially even more value in eliminating external hardware, reducing integration effort, and simplifying system architecture.

This approach is already proving valuable in real-world applications. Star Stream, for example, uses UNO Q to process and analyze high-speed racing telemetry data at the edge. The platform combines Linux-level processing power for data handling and visualization with the deterministic control needed to interact with physical systems in real time. The result is a solution capable of delivering professional-grade, real-time insights without requiring a complex multi-board architecture: it’s Formula 1 results, without the Formula 1 budget.

#2 Lessen the cost with fewer components 

As you move on to more complex endeavors, it’s important to keep the bigger picture in mind: the purchase price of a board is only a small part of a project’s budget! Additional controllers, interface boards, communication modules, power supplies, and custom integration all contribute to the final cost of a solution. 

UNO Q consolidates that BOM. Linux processing, real-time control, high-speed connectivity, and industrial I/O, all on one board. Fewer components means fewer integration points, fewer failure modes, and a bill of materials that doesn’t keep growing. A lot more applications can be built with fewer components and fewer integration challenges. The result is a lower total cost of ownership (TCO), even before considering maintenance, deployment, and long-term support.

A great, concrete example of this comes from ZenCell from PriscoZen, a company developing automated quality inspection systems. By leveraging the dual-brain architecture of UNO Q, they were able to consolidate functionality that would traditionally require multiple devices into a single platform. Fewer boards meant lower BOM cost, fewer integration points, simplified maintenance, and a cleaner overall system design. What’s not to love?

#3 Develop AI-native projects with less second guessing 

If you are running an AI model, the real complexity often begins after inference is complete. You need to collect sensor data, make a decision, and trigger a physical response. This needs to be done reliably, in real time. That requires deterministic control, not a Linux process that can be preempted by the OS. Again, the dual-brain architecture of UNO Q can become particularly valuable from this perspective.

The Linux processor can handle AI models, vision pipelines, orchestration, and high-level decision making. Meanwhile, the microcontroller continues to manage sensors, actuators, and real-time interactions independently. The two processors complement each other naturally, allowing you to build systems that can both understand and react to their environment.

This architecture is especially relevant for applications such as visual inspection, predictive maintenance, robotics, smart gateways, and intelligent human-machine interfaces.

The RS DesignSpark team built a PCB inspection 4-part series (you can start with Part 1, here) that demonstrates this approach in practice. In the project, UNO Q handles image acquisition, machine learning workflows, and application logic while maintaining reliable interaction with the physical inspection environment. Rather than focusing solely on AI performance, the project showcases what is often more important in industrial deployments: connecting intelligence to action. The real kicker? Andrew told us he built the whole system for about $1,700 – with significant savings compared to similar systems starting at $3,000 and going all the way up to $20,000!

#4 Build it now, faster, and without friction

In many professional projects, engineering time can quickly exceed the cost of the hardware itself. Think about it: you need to prepare the environment, install the software stack, connect different tools, move data between systems, and create the infrastructure needed before real application development can even begin.

UNO Q helps reduce friction and speed up the process from the very first step. It ships with onboard eMMC and a preinstalled software environment. No SD card to format. No image to flash. No setup ritual before you can write a line of application code. With onboard eMMC storage and a preinstalled software environment, you can start working without first preparing removable media, flashing an operating system image, or assembling the basic development setup from scratch. 

It also matters after deployment. In real-world systems, storage is not just a setup detail: it can affect reliability, maintenance, and uptime. Removable storage can be more exposed to corruption, wear, accidental removal, or failure, which may lead to downtime and additional recovery costs when a system needs to be reinstalled or reconfigured. By relying on onboard eMMC storage, UNO Q offers a more robust foundation for applications that are expected to run continuously and reliably. It also gives you flexibility in how you work with the board: it can be used connected to a PC during development, or run as a full standalone single-board computer (SBC) when the application needs to operate independently.

The advantage of adopting UNO Q becomes particularly clear in machine vision and inspection projects, where developers can focus on building the application itself rather than assembling the underlying infrastructure.

As author Andrew Back noted in his final words on Part 4 of the DesignSpark PCB inspection project, “UNO Q, Arduino^® App Lab and Edge Impulse together provide a powerful combination, with a clear focus on convenience and enabling the rapid development of sophisticated applications.”

Understanding the full value of your hardware

At the end of the day, the greatest value is found in building a simpler, more efficient, more versatile and scalable system. UNO Q – with its unique combination of Linux computing, real-time control, edge AI readiness, and industrial-grade flexibility – is designed to reduce complexity rather than add it. And for developers building the next generation of intelligent devices, that may be the most valuable feature of all.

The real cost of a system is not what you pay for the board.

It’s the external MCU you didn’t have to buy. The AI HAT you didn’t need. The communication layer you didn’t have to build. The hours you didn’t spend on integration. The maintenance call you avoided, because eMMC doesn’t fail the way SD cards do. Every component you skip is money saved. Every integration point you eliminate is a failure mode removed.

The ultimate system cost isn’t the price of the board, it’s everything you no longer have to buy, wire, and fix. By packing Linux, edge AI, and real-time control onto a single board, UNO Q slashes your component list, cuts power consumption, and eliminates integration headaches. Zoom in, it does more; zoom out, it saves you more.

Want to dive deep into real-world applications that are proving the value of UNO Q? Read more about:

• How Star Stream created a smart, cost-effective solution to process and analyze high-speed racing telemetry data at the edge
• How ZenCell replaced two boards with one, to build a better quality inspection system
• How Andrew Back worked out automated visual inspection of PCBs, leveraging user-friendly training of AI/ML models made available by Edge Impulse

Qualcomm branded products are products of Qualcomm Technologies, Inc. and/or its subsidiaries. Arduino, UNO, and the Arduino logo are trademarks or registered trademarks of Arduino S.r.l.

The post Ditch overpriced hardware: 4 ways the Arduino® UNO Q board helps you do more for less appeared first on Arduino Blog.

• Jab, Jab2D, Jab3D — simple motion burst detectors for 1, 2, or 3 axes.
• Shake, Shake2D, Shake3D — smooth motion energy tracking for vibration and shaking.
• Tilt and Roll — orientation signals from 9DoF IMU data.
• Tilt_Roll — fast roll/tilt computation using accelerometer data only.
• TouchArrayGestureDetector — brush/rub and swipe-style touch features for sensor arrays.
• Button — tap, double-tap, hold and press tracking from digital button input.
• utils/ — reusable helpers for smoothing, thresholds, mapping, timing, and sensor support.

This library is made for people who want meaningful sensor features, not raw numbers. Instead of reading raw acceleration or touch values, you can get:

• a jab intensity score
• shake energy that grows with movement and decays smoothly
• tilt and roll values ready for gesture use
• touch brush/rub metrics
• button interactions like taps and holds

This MIT licensed project is on GitHub.

If you’ve ever had an idea that could solve a real-world problem, not just live inside an app, but actually exist out there, this is your moment.

Across India, something exciting is happening. Makers, students, startups, and engineers are starting to move beyond software-only AI and into something far more tangible: building systems that can sense, think, and act in the real world. And Arduino^® with Robu.in (our local partner) has been right at the centre of this shift.

With accessible hardware and a growing ecosystem, Arduino has helped lower the barrier to entry for AI across India. Startups and MSMEs are now able to integrate AI into their products without needing massive R&D investment. Students are getting hands-on experience with production-ready tools. And through workshops, partnerships, and providing better access to hardware in cities and towns across India , innovation is no longer limited to just a few tech hubs.

At the same time, there’s a clear shift toward edge AI — where intelligence runs directly on devices rather than in the cloud. Together with Qualcomm Technologies, Arduino is helping developers build low-power, high-performance systems that can operate in real-world conditions. The result? A new generation of builders who aren’t just writing code, but creating complete, intelligent systems.

And that’s exactly what Physical AI is all about: combining sensors, computation, and action into systems that interact with their environment. Across India, we’re already seeing this come to life in smart agriculture, healthcare devices, industrial automation, and smart city solutions—projects built not just for demos, but for real impact.

Now, there’s an opportunity to take that even further.

The Arduino Physical AI Challenge is a free, national-level competition designed and run by Robu.in to bring this movement together and push it forward.

Learn more and register!

Robu.in invites anyone, from school students to creators and startups to build real-world AI systems using the Arduino^®UNOQ. Solo or teams of up to four, all skill levels are welcome.

What makes it exciting

30 Lakhs+ total prize pool — including special awards, so every type of builder from school students, to college teams, to women in tech and more, all have a real chance of winning something special.

Every winner and runner-up in the Robu.in Arduino Physical AI Challenge receives something that doesn’t show up in a bank account: all-expenses-paid mentorship at Qualcomm / Arduino.

For an engineering student or recent graduate, access to Qualcomm Technologies and Arduino engineers — the people building the silicon that powers AI on the edge is not a line you normally get to jump.

It’s the kind of exposure that shapes what you work on next. Whether you’re heading into a placement process, a startup, or research, “worked with Arduino engineers on Physical AI” is not a common CV line.

Key dates

Open for registration now, you’ll have the chance to submit your projects from June 15th onwards, with the final project submission deadline of July 31, 2026.

Final thoughts

India already has the talent, the creativity, and the “jugaad” mindset that makes innovation happen.

Now it also has the tools, the ecosystem and the opportunity. 

Don’t just learn AI. Don’t just watch innovation happen. Build something real. Start here!

Arduino and UNO are trademarks or registered trademarks of Arduino S.r.l

The post Build something real: Join the Arduino  Physical AI Challenge India 2026! appeared first on Arduino Blog.