https://community.element14.com/products/roadtest/The element14 RoadTests are an extensive collection of detailed product reviews for engineers that are written by members of the group. The reviews cover a wide range of new B2B products used for in the engineering design and development process. Product ren-USTelligent Community 12https://community.element14.com/products/roadtest/m/managed-videos/151516Tue, 07 Jul 2026 17:43:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:6299f15d-4c63-489f-9b97-8cbcd340fdd2AngelSotohttps://community.element14.com/products/roadtest/rv/roadtest_reviews/1922/pic16f13145_curiosity_nanoSat, 27 Jun 2026 19:53:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:5812d2c1-601b-4bdd-9fd2-0e81baeaed27misazI welcome you to my detailed review of PIC16F13145 MCU and its evaluation board called Curiosity Nano. In stores you can find that board under EV06M52A product code. In this review, I will briefly describe board, it's features, capabilities and some mine options. Most of these apply to any Curiosity Board in the family. Then I will move to explain and review MCU specific for this particular board including reviewing overall development ecosystem. Curiosity Nano family This board is part of Curiosity Nano evaluation board family which Microchip makes for evaluating their MCUs. They started producing these boards many years ago and since that they make one new board every time they introduce new MCU family to the market. While originally intended for evaluating new MegaAVR generation of MCU, later they start making same boards for 32-bit ARM Cortex-M SAM, 8-bit and 16-bit PICs, dsPICs, and recently PIC32 family also become covered by Curiosity Nano board. My current “collection” contains 5 of these: In this review I will focus the smallest bottom one. All Curiosity Nano boards have some common properties. All of them have on board programmer with USB port on left side, so you do not need to own any external one. But they differ for allowing evaluating unique features of evaluated MCUs. For example, AVR DU one has MCU with USB controller, so it has USB port on right side for evaluating this feature. AVR DB support multiple voltages, so there is one more pinhead for providing different voltage to part of pins. Some very interesting features are common. I will highlight few of my favourites: Adjustable Voltage Regulator One feature which I really like on these boards is digitally adjustable voltage regulator. Nowadays MCUs are quite flexible. PIC on board covered by this review support power voltage in range 1.8 - 5.5V which spawns several commonly used voltages: 5V, 3.3V and for even more modern electronics: 1.8V. But you do not need to limit yourself to these common voltages, if you want to run your design on 2.36V, you can set it. Basically, any voltage with approx. 5 - 10 mV resolution is supported. Accuracy is quite good. Let's see how to set it. For AVR boards used with Atmel Studio (or Microchip Studio if you like up to date terminology, but I know it as Atmel Studio), you can do it in Device Programming Tool (chip with yellow flashlight icon on menu): But this does not work with PICs because Atmel Studio do not support PICs. For long time I thought that MPLAB X do not support it because I never find such similar tool in GUI, but later I found video on Microchip website showing that it is actually doable in project settings and programmer will apply it on next program loading (or reading). There is one more alternative which works only for common voltages 0V, 3.3V and 5V. You can write file with specific text to mass storage which pop up when you connect to your PC. Then board change voltage accordingly. See board manual for exact details. While you likely do not want to run MCU at 2.36V in production, it can be useful in development time. For example, for testing how circuit behaves when battery discharges. Onboard debugger Another cool feature is onboard debugger. You do not need own any external one. When I was child, starting MCU development basically meant not only buying MCU (in DIP package typically) and accessories (breadboard, wires), but also buying very expensive (for children at least) programmer. And it was also tiered by capabilities. My first programmer which I paid approx. 30 USD back in time, did not support breakpoints. Just loading and possibly reading MCUs. With curiosity boards and similar situation is nowadays much better. Competition on the market caused that even lowest cost development kit typically contains debugger on board and its pretty capable one. As I mentioned, you can place breakpoints in IDE, you can use stepping, it seems that even data breakpoints are supported (did not try it, but see it in GUI). Limitation differs per MCU. Likely AVR has different limitations compared to the PICs. For PIC 16F13145 covered in this review, 3 program breakpoints, 3 data breakpoints and 3 data capture breakpoints are supported. Solderless Pin Header While it may look confusing at the first look, board fits breadboard. Every other pin is shifted a little, but shift is very small so pin header fits it. When pushing pin header into it, this shift makes it harder to push into. You need to use force. But after that pins do not fell of and contact is good. It is another nice feature very limiting entry level cost. You do not need to solder anything to use the board on breadboard. Despite that I always solder them. I feel better when pulling it out from breadboard then. PIC 16F13145 Curiosity Nano Specifics The one thing which I do not like is that some Curiosity Nano boards do not populate crystal oscillator. It is case of PIC 16F13145 board. There is space for it, but you need to solder it yourself and rework some jumpers which are quite tiny. By default, pins are exposed to pin header, so maybe THT one connected there will also work. Since MCU is small, board is also small. Compared to other Curiosity Nano button is less convenient to press, because it is very tiny there as well. Now let's go to microcontroller itself PIC 16F13145 Microcontroller PIC 16F13145 is the most comprehensive unit from 16F13 family. It is typical that Microchip uses the most advanced unit on Curiosity Nano boards. It is typically easy to scale down if you need to save some money for production device afterwards. You can scale down in two dimensions: pin count and memories. RoadTested unit has 14KB of program flash and 1KB of SRAM. Scaling down in term of memories remains all the peripherals exactly same, just program memory and RAM go down to half (16F13144) or quarter (16F13143). Scaling down in terms of pin count means feature cuts, but it is not that strong. You can scale down to 14 or even 8 pin options. Pin scaled down options contains some peripheral constraints. Obviously, 8-pin can't offer more than 8 ADC channels. But generally offered peripheral are the same except pin count constraints. Curiosity board comes with most comprehensive unit in 20-Pin VQFN package. CLB Unique peripheral which you will likely select this family for is Configurable Logic Block (CLB). It is mini-FPGA containing 32 cells. Microchip call cells BLE - Basic Logic Element. I will call it cell to do not interfere with Bluetooth, which is not offered by this 8-bit MCU. Each cell contains input multiplexers, 4-to-1 LUT, and D flop. Each part of cell can be optionally eliminated if needed. But synthetiser tool does all these configurations for you, so you do not need to worry about it much. I developed WS2812 bus driver using it. Normally you need to bit bang it which has some timing and interrupt usage constraints, or you can use SPI preferable with DMA to generate timing sensitive signal. All of these bring some constraints to firmware and resource utilization. I tried to offload all these into CLB and I managed to do that successfully. Microchip offers tool which can synthetise some Verilog or graphical design. It is available in MPLAB X, or you can access the same tool online at https://logic.microchip.com/clbsynthesizer/ even without having board in hands. It is good idea to test if your design idea fit it in advance. Here is how graphical designer look like: Internally CLB structure is constrained. Not every cell output can be connected to all cell inputs. Similarly, some external outputs are available only on subset of elements. Synthetiser tool handles it for you but it brings some surprises. For example, I had design which utilized 28 / 32 cells, so I was happy about it. But it did not work, so I tried to expose one internal signal to GPIO to see what’s going on. And unluckily after adding that debug signal overflown design. This signal likely was not easily routable to particular GPIO pin I selected, so synthetiser likely needed to duplicate lot of logic or waste some cells just from one part of mini-FPGA to another. And this simply overflown capacity of 32 cells. Design tool is big black box. When design overflow, it does not tell you much. It even does not tell you if synthetises failed because of exhausting resources or because it contains some real error. Another caveat from similar group is that it seems that tool evolve over time and for example my design which synthetised well few months ago, now with new version of synthetiser fails to synthetize for some reason. That is disadvantage if you run synthetiser tool as on online app. Structure of CLB interconnection is documented, so with some engineering feeling you can try and guess changes needed to do to fit design. For example, in case when I had 28/32 utilization which later failed just by exposing one signal to GPIO, I tried just changing it to other GPIO without any other change of internal circuit structure. It magically successfully synthetized with utilization 31/32. There are no RAMs or other dedicated helper block around cells known from standard FPGAs. Only dedicated hardcoded part is 3-bit counter. You can bring "counter stop" and "counter reset" signals and you have 8 outputs indicating one of 3-bit counter state. You can use any or multiple of these in your design. Can be good for some sequencing in design. You can use this counter for anything you want. In my WS2812 driver, I used it for integer division of clock. Bitstream to this FPGA is loaded externally and you can't change it at runtime from PIC CPU core. Despite structure of mini-FPGA is mostly publicly described in datasheet, format of bitstream or interface used for programming it is not described at all. But there is guy on the internet who reverse engineered it, so you can read about it on https://mcp-clb.markomo.me/. He also has python library which can generate bitstream. So, if you want to have 32 cells under absolute control and do not want surprises, this is the way. For interoperation with software on CPU core, there are 4x 8-bit registers which maps to 32 signals inside FPGA parts. One caveat (or actually feature if you know about it) is that registers are synchronized and writes only when last (clbswinL) is written. If you write only clbswinH, it never gets updated on FPGA side. Benefit is that you can write all four and their update on FPGA side atomically. It is not explicitly written in register description, so I wasted some time investigating why my register value propagation do not work. It is explained in functional description section in datasheet. For communication in other direction (FPGA to CPU) you can use interrupts. There are 4 signals which can trigger interrupts in CPU. Except direct "communication" with CPU, you can also trigger ADC measurement and various operations with timers. On input sides, you can process outputs from many peripherals (UART, SPI, PWM, clocks, timers...). You can see them all online in synthetiser tool by adding pin to graphical design. Finally, despite bitstream is not settable from firmware, CLB can be at least enabled and disabled from software. This is most unique peripheral of this MCU so I was bit verbose. Not let's briefly look at others peripherals. Analog 10-bit ADC is offered. 8-bit DAC is offered. Analog comparator is offered. And finally, voltage reference with 1.024V, 2.048V and 4.096V options is offered. Peripherals are quite modern. Nothing impressive but for general purpose apps should be enough or at least it is at the same level where competitors are with similar MCUs. Digital Interfaces SPI and I2C are covered by shared peripheral. Sadly, there is only one instance so you can use only one of it at time. But pin mapping is extremely flexible on PIC, you can route any peripheral signal to any pin you want and you can change it in runtime. If you screw up and swap SDA and SCL on I2C, you can just update firmware in this PIC case. Additionally, as a benefit, with this MCU you always have very nice PCB layout. You can also utilize this flexibility for actually using both I2C and SPI in design despite there is only single peripheral. You can work in a way that you use SPI, then reconfigure peripheral and remap it to different pins and use it for I2C, then swap again, etc. I made demo project with I2C sensor and SPI display (connected to different wires). Firmware simply did transaction on I2C bus to sensor, then changed pin mapping, reconfigured peripheral to SPI mode and transferred rendered screen to display. It is doable, just can't transfer both at the same time. The biggest issue I see is that firmware is far more complex and MCC code generator (MCC code generator is explained later in this review) tool absolutely do not take such use case in mind. It allows you to always generate driver only for one of them. I hacked it by copying generated output folder with I2C driver under different name, then reconfigured to SPI and generated source. Need to clean code to remove some duplications and still need to make my own logic for Deinitialization/Initialization when swapping buses and of course need to manually reconfigure pin mapping. It worked at the end, just was not convenient. UART has dedicated communication block. It is easier to use since compared to hybrid peripheral above. There is only one instance though. But you can do the trick with remapping pins as well and use it multiple time as well. And if you run out of available peripherals, you can always make some using CLB. SW Ecosystem MPLAB X IDE MPLAB X IDE is classic IDE for PIC. It is NetBeans based which bring some technological historical limitations. For example, on my monitor it is blurry because it does not support high DPI. It follows proprietary project system which may be inconvenient for nowadays developers using "open folder" feature instead of complex project configurations. However, it works pretty reliably and XC8 compiler and other is pretty well integrated. Debugger mostly works. HW resource utilization is nicely visualized for both build time properties (for example, flash memory utilization) as well as runtime resources when debugging (for example, maximum allowed breakpoint count). There is code generator tool which is bound to all projects by default which I do not like. I think it is not necessary for 8-bit MCUs which are not that comprehensive compare to nowadays blazingly complex ARM MCUs where are these generators handy. Drivers it generates does not seem very useful to me. To me it seems that it more or less wraps registry write/reads with minimal logic around. XC8 compiler often then complains that there is function compiled, but unused. I personally more like Atmel Studio which works faster, despite based on old Visual Studio, still do not suffer some legacy issues like high DPI issue, work faster on nowadays hardware, do not force using any code generator, and many things seem simpler and more straightforward to me. MPLAB Extension for VS Code Except MPLAB X IDE there is pretty new integration to VS code. It is pack of extensions. Since it is new, there are quite a lot of bugs. But it gets better over time. For example, when I started with it, it shown every few seconds popup that some communication with AI service failed because of credentials issue. This got fixed in some update since then. Code generator tool integration is worse. It is hard to find how to create project and how to do operations on top of it. After I somehow integrated it manually, it still generates sources to wrong folder then I expected and did not find way where to set it. Because it is more modern there are no longer issue with legacy base. High DPI works fine there. Some operations feels faster and overall responsiveness of VS Code is better than MPLAB X. One problem I see is that many vendors try to integrate into VS code nowadays and everybody do it slightly differently and there are collisions between extensions. I had to uninstall Modus Toolbox extensions which I used for Cypress/Infineon PSoC development because I had hitting infinite stream of notifications that something is misconfigured. Configuring it broken something else. it was not clear if IntelliSense errors come from Microsoft C++ extension, Clang extensions which some other extension bring as dependency or if it comes from error parsed from XC8 output. I recommend using VS code instance with only one MCU ecosystem. As far as I know nowadays VS code do not support environments like original VS supported via "instances". XC8 compiler is integrated much worse compared to MPLAB X IDE. Code completion has no idea how compilation works. It reports error like wrong includes, missing functions, etc despite compilation succeed. I suspect it is partially because my project was misconfigured because I had some tweaks to structure after creating it, but still did not manage to fix completion in reasonable time. Completion also has no idea about any Microchip proprietary thing like pragmas. Very similar issues are around debugger. Microchip somehow integrated their debugger into VS code, but there are lot of situations when it does not work, things get out of sync, breakpoints often get missed, sometime code steps on wrong lines even with disabled optimization. Stopping debugger sometimes fails and VS code thinks it still runs. Many times, I clicked continue, in VS code it looked like still stuck on breakpoint, but code actually run and miss several breakpoints afterwards. It is very frustrating when these things do not work and failures are heavily random. In MPLAB X they worked mostly fine except some Java exceptions which happens in both. I think there is even ton of bugs inside VS code core which are not caused by Microchip because I have similar experience with other MCU ecosystems integrated to VS code. But since everybody implement VS integration slightly differently, bugs in debuggers in every ecosystem are slightly different as well. To sum SW section up, MPLAB VS code integration is likely future, but nowadays I recommend stick with MPLAB IDE. However, it may change soon, because they update VS Code extensions pretty often. Documentation Documentation is very good. Very few things are missing, datasheet is clear, Curiosity Board had manual and schematics. There were few minor points like mentioned lack of explanation of synchronized write when transferring data to CLB, but generally, I consider Microchip’s documentation very good. Compared to many competitors, it is also very easy to find documents on their webpage. Conclusion My personal TLDR verdict: It is great board and MCU but unless you need CLB, it is higher pleasure to work with AVRs.AVR Curiosity Nano boards, STM32 Discovery and Nucleos, PSoC 62 Kit and few otherDevelopment Boards & ToolsUnstable software (new version of CLB designer fails to synthetize previously working design, early VS code integration bugs, Java Exceptions in debugger)https://community.element14.com/products/roadtest/f/forum/57040/is-there-a-place-we-can-request-roadtest-products/236236Thu, 25 Jun 2026 20:23:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:26ea360e-f58d-4edf-b04c-df4711d25ccbDABAll of engineering are working within limits. You have to adapt and overcome these limitations if you are going to become a good engineer.https://community.element14.com/products/roadtest/f/forum/57040/is-there-a-place-we-can-request-roadtest-products/236228Thu, 25 Jun 2026 00:02:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:f9e525db-d71c-4c0b-82f0-4b358dddf8f2MATRIX7878Limits? We don't need no stinkin' limits!https://community.element14.com/products/roadtest/m/managed-videos/151498Wed, 24 Jun 2026 19:29:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:887a5705-f194-4e4e-a0c8-6b9981019570Shishirhttps://community.element14.com/products/roadtest/rv/roadtest_reviews/1921/review_of_osram_as1170_evaluation_kitWed, 24 Jun 2026 17:33:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:afdfa1f7-5520-4619-be1f-5c3c5f00a402arvindsaWhat Is the AS1170? High-current LED drivers are not rare. TI, Diodes Inc., and Maxim each offer dozens of parts that push current into an LED at a fixed ratio of some input reference. What makes the AS1170 interesting is its scale and its architecture. The AS1170 is a single-chip inductive DC-DC boost converter paired with two independent constant-current sinks. Each sink delivers up to 1000 mA, giving you a combined 2000 mA of LED drive current from a 2.7–4.4 V supply. That is not LED driver territory in the conventional sense - it is VCSEL territory, camera flash territory, high-power illuminator territory. You are not running a status LED. You are running something that gets hot if you hold it on too long. The architecture matters because most drivers at this current level are either dumb - a fixed sense resistor and a control pin - or require an entire evaluation ecosystem before you can get anything running. The AS1170 occupies an interesting middle ground: fully I2C-configurable, all parameters software-writable, yet small enough to disappear into a WL-CSP13 package under a board. The two current sinks (LED_OUT1 and LED_OUT2) can run independently, load-balanced, or cascaded. Current steps at 3.5 mA per LSB across an 8-bit register, giving you 0 to roughly 892 mA per channel in 256 steps. Clean. The EVK Kit The OSRAM AS1170 EVK Kit gives developers a way to evaluate the chip before committing to a BOM and to validate firmware against a known-good AS1170 circuit. This review approaches it from the perspective of an engineer choosing between LED drivers - someone who needs to get up and running quickly and with minimal friction. Evaluation is structured around four areas: Getting started experience Depth of functionality Software usability Quality of guides and troubleshooting documentation What Is in the Box The kit ships with: ams OSRAM AS1170 WL EVM Evaluation Board - the main board carrying the AS1170 IC and an 8-pin header Two IR LED breakout boards - for connecting to the EVK header ESP32-S2 DevKit M1 - the host MCU that bridges USB to I2C One 1 m USB 2.0-A to USB 2.0 Micro-B cable The pairing is intentional. The AS1170 EVK board exposes its I2C lines - SDA on E1, SCL on D1, STROBE on E2 - through the 8-pin header. The ESP32-S2 sits between USB and I2C: it receives commands from the PC, translates them into I2C register writes, and reports back. The PC software never communicates with the AS1170 directly; it talks to the ESP32. The LED breakout boards are small, purpose-built daughterboards. Each mounts one OSRAM high-power LED and routes its anode and cathode to a connector that matches the EVK's LED_OUT1 and LED_OUT2 terminals. They spare you the work of hunting down appropriately rated LEDs and wiring your own test setup from scratch. The hardware itself is physically solid. The EVK PCB is well laid out, components are clearly labelled, and the I2C address - 0x30 on this board, with A-SELECT pulled low - is called out in the documentation. The kit contained everything it was supposed to. One Gap: The Power Profile One evaluation that could not be completed was a thorough power profile of the daughter board - specifically, the current ramp behaviour, actual current draw under load, and thermal response over time. To do this properly, additional LEDs beyond what were supposed to be provided along side the kit would have been necessary. The two breakout boards cover basic functional bring-up, but characterising output behaviour across different load conditions requires a broader set of test devices. That data is absent from this review, and it is a genuine gap for anyone evaluating the AS1170 in a high-current illuminator or flash context where knowing the actual versus programmed current curve matters. The Software: Where the Frustration Begins ams OSRAM provides a PC GUI application (AS1170-GUI, V1.1) with the kit. The idea is straightforward: plug in the ESP32 via USB, open the GUI, select the serial port, and get a complete graphical interface for configuring all AS1170 registers without writing a single line of code. No installation required - a genuinely useful thing to offer with an evaluation kit. That promising start did not last. The host computer was missing drivers for the CP2102 USB-to-serial converter on the ESP32 board. Installing them was quick, but there is no clear guidance on this anywhere in the getting-started material. The answer eventually turned up not in the official guide but on a random documentation page, buried in an image. The GUI launched and showed a connected MCU, then prompted navigation to the configuration screen - which is the only thing in that initial view. That intermediate step adds nothing; the application could simply open to configuration directly. The configuration screen itself is functional but low-contrast and not particularly accessible to users with low vision. Those are fixable issues. The critical problem was not: the Chip ID never registered as detected. After trying reconnection, different cables, and a different computer, the result was the same. There is no troubleshooting guide to consult. Digging into the firmware source in the same repository as the GUI ( https://github.com/ams-OSRAM/AS1170-GUI/blob/main/ESP32/AS1170_i2c_v0.ino ) revealed this: An SD card. A CSV file. Neither exists in the repository, and the EVK board has no SD card slot. That raised immediate doubts about whether the firmware shipped on the ESP32 was correct - or present at all. Rather than debugging an unknown firmware state, a custom firmware and matching GUI were written from scratch, modelling the interface closely on the original. A basic I2C scanner at startup detected nothing. Checking pin assignments against the EVK schematic revealed that the board does not use the ESP32's default I2C pins - it uses GPIO 12 and 13. After updating the firmware accordingly, the scanner still detected nothing. The root cause turned out to be hardware: pull-up resistors R2 and R3 were not populated on the board. Once soldered in, everything worked. Whether this was a board assembly defect or an undocumented user step, the documentation makes no mention of it either way. The vendor software is a starting point you will quickly outgrow. For any serious evaluation work, you will want firmware you control. The approach taken here was an Arduino driver for the AS1170 running on the ESP32-S2, exposed as a JSON serial bridge, with a Python/Tkinter GUI on top. Review of the Chip Once I2C communication was established, the AS1170 was tested across all documented operating modes and register functions. It is a well-designed part. What follows is a functional breakdown based on direct register-level testing. Operating Modes The four modes - Shutdown, Indicator, Assist, and Flash - are selected via a 2-bit field in the Control register and behave exactly as documented. Shutdown (0b00) cuts the boost converter cleanly. I2C continues to respond and registers retain their values. Current draw drops to the expected standby level. This is useful for applications that need the chip present on the bus but consuming nothing while idle. Indicator mode (0b01) runs a 31.25 kHz PWM with the lower 6 bits of the current register active. The output is stable at low brightness settings and the frequency is high enough to eliminate visible flicker. This mode is well-suited for status indicators and always-on pilot lighting where continuous low current is acceptable. Assist mode (0b10) opens 7 bits and sits between Indicator and Flash in both current range and intended use. It behaves predictably as a mid-power operating point - useful for applications that need more drive than an indicator but where full flash timing is not required. Flash mode (0b11) is where the AS1170 is at its most interesting. Full 8-bit current, the boost converter running at full capacity, and a hardware timer that cuts the output automatically when the programmed timeout expires. The self-clearing of the mode bits and out_on bit on timeout expiry is behaviour worth paying close attention to in firmware: if your code polls the mode register after a flash, it will read back zero. This is correct operation, not a fault. Plan your state machine around it. Current Control The 8-bit current register with 3.5 mA per LSB gives 256 steps from 0 to approximately 892 mA per channel. The resolution is practical - steps are small enough that the difference between adjacent values is not visible in most optical applications, and the range covers everything from low-power indicator use through full flash current. Both channels were tested independently and the matching between them was good. The two channels can be driven simultaneously with independent current settings, which is useful for applications that need two LEDs at different intensities or are driving two different emitters from a single driver. The Flash Timer The flash timeout register (0x05) is not linear, and understanding its encoding matters in practice. Values below 0x7F map to (value + 1) ms. Values above 0x7F map to (value − 127) × 8 + 256 ms. The result is a two-segment scale covering 1 ms to roughly 1152 ms. All values tested across the full register range behaved as the formula predicts. At short timeouts (single-digit milliseconds), the output cut cleanly with no observed overshoot. At the longer end of the range, the timer remained accurate. For strobe and illuminator applications, the covered range is more than adequate. The Current Boost Register Register 0x81 implements a current boost of approximately 11% above the nominal full-scale value. Accessing it requires writing 0xA1 to the password register at 0x80 first, and that unlock is valid for exactly one subsequent I2C transaction. The mechanism works as designed. Write the password, immediately write the boost bit, and the boost activates. Any other I2C transaction between the password write and the boost write locks the register again. This is not a security measure in any meaningful sense - it is a write-protection guard against accidentally enabling a mode that exceeds the nominal current specification. The behaviour is clean and predictable once you know the one-transaction rule. The 11% increase was measurable in testing. For applications operating close to the thermal ceiling, this register should be used carefully and with appropriate attention to duty cycle limits. I2C Behaviour The chip responded reliably to I2C at 0x30 throughout all testing. No missed ACKs, no register corruption across repeated writes, no unexpected state after mode transitions. The Chip ID confirmed correctly and matched the datasheet value. The register map is exactly what the documentation describes with no undocumented surprises encountered. Verdict on the Chip The AS1170 is a well-executed part. The register architecture is logical, the operating modes cover a genuinely useful range, and the flash timer hardware offload is a real convenience for time-critical applications where relying on software timing would introduce risk. The current boost guard mechanism is thoughtfully designed. The two independent channels are cleanly matched. The only unanswered question - through no fault of the chip itself - is how it behaves under realistic high-current load with a proper characterisation of the output current ramp, actual versus programmed current at different supply voltages, and thermal behaviour under sustained duty cycles. That data requires load conditions and additional LED hardware that were not available for this evaluation. It is the one gap that remains before this part could be recommended without qualification for a production design in a high-current flash application. For the use cases this part is designed for - camera flash, high-power IR illuminators, VCSEL drive - the register-level behaviour inspires confidence. The chip does what it says it does. Verdict on the EVK The getting started experience was genuinely difficult - and that matters more than it might seem. When you are evaluating multiple EVKs in parallel, your time per board is limited, and first impressions carry weight. A missing pull-up resistor, firmware that references an SD card that does not exist, driver installation steps buried in an unrelated documentation page, and a GUI that silently fails to detect the chip all stack up fast. Taken together, they do not read as minor oversights - they read as a kit that was not validated end-to-end before shipping. The honest risk is this: if I had been moving quickly across several competing parts, I would have put this board down and questioned whether the AS1170 itself was the problem. The chip is not the problem. But the EVK makes it very easy to think it is, and in a competitive evaluation that can be enough to lose a design win before the chip ever gets a fair test. Getting started experience - 2/5 Depth of functionality shown - 4/5 (GUI shows all possible function, just that it dint work for me) Software usability - 4/5 (assuming the firmware is to be blamed) Quality of guides and troubleshooting documentation - 2/5 A personal Note: I am bit disappointed that my first RoadTest review had to be on the critical side. But I am giving my honest review of how it worked out for me. You can find the ESP32 Firmware and the GUI I made here: https://gitlab.com/arvindsa/as1170-evk-companion . Hopefully other Developers running into the problem might find the solution here.LM3644/LM3643 (TI), AL3644 (Diodes Inc.), and MAX20360 (Maxim) — the TI parts are the most direct comparison, better documented but lower peak current; the MAX20360 competes at the high-current end but is a significantly more complex integration.Connectors & CableMissing pull-up resistors that are never mentioned in documentation, ESP32 firmware that references hardware not present on the board, and a getting started guide with enough gaps that every problem required going outside the provided materials to solve.The EVKit contained everything correctly. But for proper evaluation of the daughter board, additional LEDs was supposed to be given but was nothttps://community.element14.com/products/roadtest/rv/roadtest_reviews/1920/roadtest_of_arduino_uno_q_4gb_ram_32_gb_emmc_storage_-_single_board_computerWed, 24 Jun 2026 15:38:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:64e571af-38c0-49e4-b1f2-f3f0a6afeedbShishirIntroduction The Arduino UNO Q is a hybrid system containing Qualcomm's Dragonwing QRB2210 MPU which comes with Debian Linux and an STM32U585 microcontroller running Zypher OS, a real time OS on the same board. Unlike normal Arduino boards, this hybrid allows both high-level Linux applications and real-time microcontroller code to work simultaneously and communicate with each other through the built-in RPC (Remote Procedure Call) bridge. This allows a Python script running on the Linux MPU to seamlessly request data from an Arduino sketch running on the MCU, and vice versa, without writing complicated serial protocols. The Microprocessor Unit(MPU) handles heavy data computations, running Python scripts, executing AI machine vision models, and controlling Wi-Fi or Bluetooth stacks. The Microcontroller Unit(MCU) does the deterministic, real-time hardware control i.e. where precise timing and minimum delay is required. This architecture addresses a common problem encountered in many embedded projects. When using a traditional SBC, direct analog input capability, pwm etc. absent, requiring additional ADC hardware or a microcontroller to be used as a middleware. Conversely, while microcontrollers excel at real-time hardware control, they lack the computational power and software ecosystem available on Linux. The UNO Q attempts to combine the strengths of both approaches into a single development platform. Hardware Overview {gallery}Overview Overview Front Back Processor Architecture The board consists of two major processing domains: SBC Side 64 bit Quad-core ARM Cortex-A53 clocked up to 2.0 GHz Adreno 702 GPU running at 845 MHz Debian Linux 13 (Trixie) 4 GB LPDDR4 RAM 32 GB eMMC Storage Dual-band Wi-Fi 5 (2.4/5 GHz) 802.11a/b/g/n/ac , Bluetooth 5.1,GNSS Supports OpenGL ES 3.1, Vulkan 1.1, and OpenCL 2.0 18-bit Dual Image Signal Processors supporting up to 25 MP Supports two concurrent 13 MP cameras at 30 fps MIPI-DSI output up to 1080p @ 60 fps Guaranteed hardware long-term support until May 2032 MCU Side STM32U585 Arm Cortex-M33 up to 160 MHz - Modern and Efficient Embedded FPU, MPU(Memory Protection Unit) and DSP instructions 14-bit ADC and 12-bit DAC , Integrates CORDIC for trigonometric math and a Filter Math Accelerator (FMAC) Low-power operation Real-time peripheral control One of the key advantages of the Arduino Uno Q is that analog peripherals remain directly accessible through the MCU while Linux applications can access them through RPC. Another important consideration when working with the UNO Q is the presence of different voltage domains. The STM32 microcontroller operates using 3.3V GPIO logic, while the high-speed expansion headers connected to the SBC side operate at 1.8V logic levels. Care must therefore be taken when interfacing external hardware. Power Options The board supports multiple power input methods, including USB-C power and a 7–24V DC input, increasing deployment flexibility in embedded applications. {gallery}My Gallery Title Input power options Power block diagram UNO Q supports dual power inputs: a USB-C port and a 7-24V DC input. Over USB Power Delivery, it requests only the 5 V / 3 A contract and does not request higher-voltage PD profiles. Use a supply and cable rated for 5 V at 3 A to avoid undervoltage during short activity peaks such as wireless bursts or display initialization. A regulated external 5 V DC source can also be used to supply power to the board via the 5 V pin on the JANALOG header. For proper power supply and connectivity, a Multicomp Pro travel adaptor(with three different region pins) (5V/3A, 9V/3A, 12V/2.5A, 15V/2A, 20V/1.5A ; Max 30W), a 240W ERP(Extended Power Range) cable and a TP link USB type C 9-Port hub(also used for SBC mode) was also provided for this roadtest. {gallery}Power adaptor and cable Adaptor Cable Type C Hub Through the USB-C VBUS Connector t he board communicates via USB Power Delivery (PD) but specifically requests a 5 V / 3 A contract only. It does not request higher-voltage (9 V/12 V/20 V) profiles. USB-C VBUS and the 5 V output of the 7-24 V buck are diode-OR combined onto the system 5 V bus (5V_SYS). From 5V_SYS, the design derives the 3.8 V pre-regulator node and, subsequently, the 3.3 V. The PMIC, powered by 5V_SYS, derives the 1.8V rail. The Diode-OR circuit is designed to connect multiple inputs so that if one fails, the other takes over instantly without dropping power to the board. Diode Oring also provides reverse polarity protection as the diode on the lower-voltage source becomes reverse-biased, preventing power from back-feeding into that source. LED Matrix The Arduino Uno Q features a built-in 8x13 (totaling 104 individual LEDs) LED matrix on its surface. Instead of wiring up hundreds of pins or using a massive external driver chip, Arduino engineered this matrix using a highly efficient circuit design trick called Charlieplexing. Charlieplexing is an advanced electronic multiplexing technique that utilizes the tri-state logic of microcontroller pins to control a massive number of LEDs using very few input/output (I/O) pins. Standard digital pins only have two states: HIGH (5V/3.3V) and LOW (GND). Microcontrollers like the Uno Q's STM32 have a hidden third state: High-Impedance (INPUT mode). In this third state, the pin acts as an open switch or an "invisible" wire, meaning no electricity can flow in or out. By exploiting this third state and connecting pairs of LEDs in parallel with opposite polarities (back-to-back), we can selectively light up one specific LED while leaving all others completely disconnected. The mathematical formula for Charlieplexing is: Max LEDs = N X (N-1) (Where N is the number of microcontroller pins used) To control 104 LEDs individually using standard matrix rows and columns, we would normally need 8 + 13 = 21 dedicated pins. With Charlieplexing, because 11 × (11 - 1) = 110, the board only needs 11 pins from the STM32 MCU to address the entire 104-LED display. By condensing 104 LEDs down to just 11 physical lines internally, the board avoids consuming all of its own GPIO header pins. That leaves us plenty of free analog and digital pins left over to connect with our own sensors, motors, and shields. Software Environment One of the most interesting aspects of the UNO Q platform is App Lab. Traditionally, developers would need to separately write Linux software and microcontroller firmware, then implement a communication layer between them. App Lab abstracts much of this complexity by treating both processors as parts of a single project. Under the hood, communication is handled through the RPC bridge, allowing developers to focus on application logic rather than communication protocols. By condensing 104 LEDs down to just 11 physical lines internally, the board avoids consuming all of its own GPIO header pins. An App in App Lab is a hybrid composition package that runs across both processors simultaneously. Every App consists of: 1.The Python Side : High-level scripts that execute natively on the Qualcomm MPU's Debian Linux OS. This side handles computer vision, AI model execution, networking, or web interfaces. 2 . The Sketch Side : C++ code ( .ino ) running on a real-time operating system (Zephyr OS) on the STM32 microcontroller. This handles low-latency hardware, PWM, timers, and sensor reading. 3.Orchestration Configuration : An app.yaml file defines the metadata, hardware permissions, and startup configurations of the dual-system application. {gallery}App Lab Board Not Detected Board Detected App lab also includes some example apps to showcase how the MPU and MCU interact via the internal RPC Router bridge. We can connect to app lab via wired (cable) and wireless (network) connections. For wired connection we connect a single USB-C data cable from the computer directly into the board . The desktop client of Arduino App Lab on the PC auto-detects the board over the serial/virtual network interface . For initial configuration we require a wired connection between computer and arduino uno q. Once Wi-Fi configurations store successfully on the board, we can entirely sever the USB debugging cord. The board boots up independently using a wall adapter or external battery input. The desktop Arduino App Lab app on the computer uses local network multicast discovery ( mDNS ) to scan the router space. When found, the board appears in the interface marked with a green "Network" tag . Some of the latest features of App lab are: Dual Editors : The IDE features dual side-by-side tabs containing a Python editor and a C++ code editor, removing the need to bounce between Arduino IDE and VS Code. Built-in Terminal : A button in the lower-left corner instantly spawns a secure remote shell ( >_ ) straight into the Uno Q's Linux environment ( arduino@unoq ). System Monitors : The bottom status bar shows real-time resource utilization indicators tracking eMMC Flash storage space, RAM usage, and active CPU loads on the board. Arduino App CLI : Advanced users can completely bypass the graphical interface and use the terminal command-line tool to manage, start, update, and toggle Apps on the fly. Run at Startup : A toggle switch in the UI registers your app to launch automatically when the board receives power, allowing you to deploy headless field devices. Development Experience Initial Setup The initial setup was short and simple, we are required to connect the arduino uno q to the computer and after being detected we set wifi credentials and username / password for our sbc. After the first setup the board automatically updates itself. One issue I faced before updating App Lab was that the offline examples threw errors after uploading. However, once I updated both Zephyr packages and App Lab to the latest version, the issue was resolved. The updated App Lab interface was also noticeably improved compared to earlier releases, with a cleaner layout and more accessible logging functionality. Basic Blink Test The first test performed was the classic LED blink program. Although simple, it serves as a useful verification of the complete upload chain and confirms that the STM32 subsystem is functioning correctly. The sketch uploaded successfully and operated as expected, confirming reliable communication between the development environment and the microcontroller. MCU Testing Usually, from App Labs, we run applications written as Python scripts on the microprocessor , which interact with the microcontroller running the .ino sketch. The microcontroller comes preloaded with firmware that continuously listens for requests from the microprocessor and responds when invoked through the RPC bridge. However, the microcontroller section of the UNO Q can also be programmed independently, just like a standard Arduino Uno. The microcontroller used on the UNO Q is the STM32U585 . To program the microcontroller, we need Arduino IDE version 2.3.6 or later . In the Arduino IDE: Go to: Tools → Board → Boards Manager Search for: "Arduino UNO Q" and install Go to: File → Preferences In "Additional Boards Manager URLs", add: https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json Go to: Library Manager→ "Arduino_RouterBridge" library Install Go to: Tools → Board → Boards Manager Search "STM32 MCU based boards" → Install Go to: Tools → Board Select: "Arduino UNO Q" (under STM32 MCU based boards) Set Port: Tools → Ports → Select COM number An interesting observation is that, once Wi-Fi has been configured, the Arduino UNO Q appears as both a standard physical COM port and a Network Port in the Arduino IDE, provided that the board and the laptop are connected to the same network. Now we can upload simple blink sketch: {gallery}Code Upload Arduino Bridge Library Not Installed Successful Code Upload Log Programming traditional STM32 microcontrollers usually requires deep embedded systems knowledge. It is one of the reasons many hobbyists do not touch them easily because of their reputation of being hard to program. We need to configure register-level settings, HAL, clock configuration, use tools like STM32CubeIDE and connect debuggers like an ST-Link. The Arduino Uno Q bypasses all of this complexity by abstracting the difficult parts into the friendly Arduino ecosystem. The board package pre-configures all clocks, timers, and internal settings the moment the board boots up. If we want to use the high-performance 14-bit ADC, we do not need to initialize registers; we simply type analogRead(A0). Analog Performance ADC Testing The STM32U585 provides a 14-bit ADC. A 10 kΩ potentiometer was connected to A0. Initial testing produced only 10-bit values because the ADC resolution must be explicitly configured: analogReadResolution ( 14 ); After enabling 14-bit mode: The 14-bit ADC of Arduino Uno Q gives us 16,384 distinct values, which is exactly 16 times more resolution than a standard 10-bit ADC which only gives 1,024 values. LDR Testing A light-dependent resistor was connected to the ADC input. The board correctly produced varying readings according to illumination level. I was planning to evaluate the output of an MQ135 gas sensor using the UNO Q. However, the sensor's heater circuit requires a 5 V supply for proper operation, and I was concerned that the analog output voltage could potentially exceed the UNO Q's 3.3 V ADC input limit. To avoid any risk of damaging the board, I abandoned the MQ135 testing. DAC Testing DAC to ADC Loopback The STM32U585 includes a true hardware 12 bit DAC. For testing the DAC, I did not had a suitable amplifier circuit available, nor was I able to build one at the time. Therefore, I looked for alternative methods to evaluate the DAC capabilities of the UNO Q. I found that the board's ADC can be used to measure the output of its own DAC, creating a simple loopback test . In this setup, the DAC output is connected to an ADC input, allowing the generated analog voltage to be read back and verified by the microcontroller. I then implemented this loopback test to evaluate the DAC's functionality and performance. DAC (A1) ↓ ADC (A0) The measured voltages closely tracked the expected DAC outputs, confirming correct DAC operation. I 2 C OLED DisplayTesting A 0.91-inch 128×32 OLED display connected with Uno Q. Initial attempts using Adafruit SSD1306 libraries resulted in compatibility issues. The display worked correctly after switching to the U8G2 library. The U8G2 implementation is more portable and compatible with the Zephyr-based Arduino environment used by UNO Q. The display successfully rendered text and refreshed normally. {gallery}My Gallery Title 1 2 PWM and Servo Control SG90 Servo Test PWM functionality was tested using an SG90 servo motor. The standard Servo library did not function correctly.Instead, the dedicated Arduino_HardwareServo library was required. The servo was powered from an external regulated 5 V source. Initially no movement occurred. The issue was resolved after I remembered that a common ground between the UNO Q and the external power supply needs to be made to set a reference between the two. Linux Benchmarking While the microcontroller handles real-time peripherals, the SBC side is responsible for Linux workloads. The Governor is Linux kernel driver that depends the speed and performance control of processor cores. It dynamically manages the operating frequency based on workload, increasing frequency when heavy load is detected and reducing speed on low load to conserve power and maintain temperature. The term governor is taken from the physical governor that were earlier used in automobiles to keep the engine speed constant. Governor has different modes for different purpose: 1. performance : Locks the CPU at its maximum rated speed permanently. It never drops down, even if the system is idle. 2. userspace : Kernel stops managing the CPU speed automatically, it allows a user with root privileges (or a specific background daemon) to manually set and lock the CPU to a specific, fixed frequency. 3. ondemand : Dynamically adjusts the CPU speed depending on how hard the system is working, constantly checks the CPU usage. If the workload hits a certain threshold, it instantly jumps the CPU to its maximum clock speed. As the workload decreases, it slowly lowers the clock speed back down. 4. schedutil : The modern standard. Unlike ondemand , which guesses workload by looking backward at CPU utilization statistics, It integrates directly with the Linux kernel scheduler. It calculates the exact frequency needed to handle current tasks smoothly For benchmarking purpose and measuring raw speed, we require the governor to be in performance mode. After setting it, following are the benchmarks to analyze the performance CPU Performance {gallery}Versions, Governor and other stats OS version, Cpu details Setting Governor to performance Sysbench Single-thread result: 407.60 events/sec Multi-thread result: 1589.16 events/sec Performance scaling was close to four times the single-thread result, indicating efficient utilization of all available CPU cores. Compression Benchmark 7-Zip Benchmark Single-thread total rating: 1910 MIPS Multi-thread total rating: 6560 MIPS The substantial increase in performance under multi-threaded operation further demonstrates the effectiveness of the quad-core Cortex-A53 architecture. Key Scores: Storage Performance Used dd utility to evaluate storage throughput Write test: 602 MB/s Read test: 1.6 GB/s So this indicate that storage throughput is not likely to become a bottleneck for typical SBC applications. Cryptography Performance AES-256 ~942 MB/s SHA-256 ~837 MB/s RSA-2048 Sign: 185 ops/sec Verify: 6862 ops/sec Hardware acceleration and ARM cryptographic extensions indeed provide strong performance. Thermal Testing This test evaluates the system stability and thermal dissipation capabilities of the Arduino Uno Q SBC Qualcomm MPU. The Arduino Uno Q has 10 hardware thermal zones to closely monitor heat layout across different parts. I selected zones 0,3,4 and 7 to focus on CPU and GPU Evaluation Phase MAPSS (Zone 0) CPU0 (Zone 3) CPU1 (Zone 4) GPU (Zone 7) Idle Baseline 39.1 °C 41.0°C 41.3 °C 38.8°C Stress Peak Max 62.4°C 68.9°C 68.3°C 60.8°C Sustained Delta +23.3°C +27.9°C +27.0°C +22.0°C Cool-Down Baseline 37.9°C 39.1°C 38.5°C 37.9°C I did the test without heatsink or any active cooling. Standalone vs Desktop vs Remote Mode {gallery}My Gallery Title Essentially the Arduino Uno Q can be used in three ways or configurations: being connected with desktop, remote desktop and stand alone single board computer. Desktop Mode This is the default out-of-the-box configuration and is highly recommended for first-time setup and initial prototyping. In this mode, Arduino App Lab is installed directly on a laptop or desktop computer, and the UNO Q is connected via its USB Type-C interface. After the initial Wi-Fi and credential setup, the board can also be accessed wirelessly through network mode using App Lab. In this configuration, the desktop handles the computationally intensive tasks, such as compiling Arduino sketches and processing Python scripts. When the Run button is pressed, App Lab uploads the compiled firmware to the STM32 microcontroller over USB while simultaneously launching the companion Python applications on the Linux-powered Qualcomm microprocessor. This is the simplest operating mode, requiring only a single USB cable to connect the UNO Q to a desktop or laptop computer. Network Mode Once the initial configuration is complete, the physical connection between the desktop and the UNO Q can be completely removed while retaining full programming and management capabilities. After the board is provided with the local Wi-Fi credentials, it becomes an active node on the local network through mDNS discovery. Arduino App Lab then connects securely to the board over the network using an automated SSH connection. This mode provides true desktop freedom, allowing the UNO Q to remain mounted inside a robotics chassis, installed in an automation panel, or placed elsewhere in the workspace while still being fully accessible from a laptop or desktop computer. Firmware updates can be uploaded to the microcontroller, Python applications can be deployed, and AI models can be modified without requiring a direct USB connection. This mode is particularly useful for hackathons, demonstrations, events, and projects where quick remote access to the board is important. It also eliminates the hassle of carrying extra cables and repeatedly connecting and disconnecting the board from a computer. SBC Mode In this configuration, the Arduino UNO Q moves beyond the traditional "development board" role and functions as a full-fledged Linux desktop computer. For this use case, the 4 GB RAM variant is recommended. The board is powered using a dedicated 5 V / 3 A USB Power Delivery supply. To expand its connectivity, a USB-C hub is connected to the Arduino UNO Q. Using the hub's power pass-through feature, the board can be powered while simultaneously taking advantage of its multi-role USB-C interface for additional USB peripherals and Ethernet connectivity. Thanks to the onboard ANX7625 bridge chip, the UNO Q's USB-C port also supports DisplayPort Alt Mode. This enables the board to output Full HD (1080p) video directly to a compatible monitor, allowing it to be used much like a conventional desktop computer. In this mode, Arduino App Lab runs natively on the board's Linux environment, utilizing the onboard quad-core Arm processor, LPDDR4X memory, and eMMC storage. The UNO Q effectively becomes a self-contained edge computing platform, capable of operating without a host PC. This configuration is particularly well suited for deployment scenarios where the board must capture camera feeds, perform local AI inference and graphics processing using the Adreno 702 GPU, and simultaneously control real-time hardware through the STM32 microcontroller and its associated I/O headers. By combining Linux-class computing with dedicated microcontroller-based control, the UNO Q can handle both high-level application workloads and low-latency hardware interactions within a single compact system. From a performance perspective, and to fully utilize the resources available on this SBC variant, I prefer using it in standalone SBC mode. However, when it comes to convenience and ease of access, network mode is the clear winner. Once the board is connected to the same network and powered on, it can be accessed from anywhere within the network range. This eliminates the need for a direct physical connection and makes remote management straightforward through SSH. One of the most practical use cases I can imagine is keeping the board powered in a fixed location, such as a lab, workstation, or even inside a bag, and simply connecting to it remotely whenever needed. This reduces cable clutter, minimizes the hassle of handling the exposed and relatively delicate PCB, and makes the overall setup much cleaner. Wire management is greatly simplified, while the flexibility of accessing the board remotely remains intact. Arduino Uno Shields Most of the Arduino Uno Shields are designed to work on 5V logic while the Arduino Uno Q works primarily on 3.3V though some of its pins are 5V tolerant. Digital integrated circuits on older shields are often designed to recognize specific voltage thresholds to distinguish between 'high' and 'low' signals, many older chips require a minimum input voltage to reliably register a 'high' state. Because the Uno Q outputs a 3.3V signal, it frequently falls below this required threshold, leading to unreliable communication or complete failure of the shield. While the risk of hardware damage is generally low, these mismatched logic levels create an unpredictable environment where signals may be misinterpreted by the shield, making it essential for users to check the datasheets of their specific shield components. I had this L293D Motor driver shield for Arduino Uno, containing two L293D motor driver ICs and a 74HC595 shift register. It is capable of driving 4 servo motors or 2 stepper/servo motors. I was planning to use this shield with the Uno Q SBC for a 4 wheel drive. However, I wasn't sure whether it could damage the board before I had fully reviewed it, so I decided to postpone testing the shield. I'll update this with a link to the project once I've completed it. Things That Could Be Improved Documentation for creating custom App Lab bricks remains limited. At the time of writing this review, the app.yaml file of example apps cannot be edited, even the copy of examples do not allow it. The code block part of the app lab UI kind of feels stuck/unscrollable, stopping the scroll in between if clicked on the block. More detailed offline documentation related to bricks would benefit users working without internet access. Out of the 4 Spacer utility holes on the pcb, the one between Power button and Digital Pins Header appears to be too close to the headers, stopping and obstructing the M3 header nut of spacer to be fitted. However the small head screws fits perfectly. {gallery}My Gallery Title Conclusion The Arduino UNO Q is not simply another Arduino board, nor is it merely another Linux single-board computer. Instead, it represents a hybrid architecture that combines a high-performance microprocessor and a real-time microcontroller within a single platform. For years, developers and hobbyists have built similar systems by combining separate microprocessor-based SBCs with external microcontroller boards. The UNO Q integrates both approaches into a single device, with the microprocessor handling computationally intensive workloads such as Linux applications, networking, AI inference, and multimedia processing, while the microcontroller manages precise, deterministic, and real-time hardware control tasks. While the software ecosystem is still evolving and certain areas of the documentation could be improved, the UNO Q offers a compelling platform for developers seeking the flexibility of Linux alongside direct hardware access and real-time control. By bringing together capabilities that traditionally required multiple boards and complex integration, the UNO Q simplifies development while retaining the strengths of both computing worlds in a single compact unit. From the Linux side, the board demonstrated respectable perfor m ance throughout benchmarking. CPU performance scaled well across all four Cortex-A53 cores, storage throughput was more than sufficient for typical SBC workloads, and cryptographic performance was strong enough for secure networking and IoT applications. During extended stress testing, the board remained stable under sustained CPU and GPU load, suggesting that it is capable of handling continuous workloads rather than only short benchmark runs. However, Linux performance alone is not what makes the UNO Q interesting. Many SBCs can offer similar or even higher benchmark numbers. The real distinguishing feature is the integration of the STM32U585 microcontroller alongside the Linux processor and the communication bridge that connects them. The board's 14-bit ADC and 12-bit DAC are particularly valuable additions. Potentiometer and LDR testing demonstrated the increased analog resolution compared to traditional Arduino boards, while DAC loopback testing confirmed the functionality of the onboard analog output hardware. For users coming from platforms such as Raspberry Pi, having high-resolution analog capabilities available without additional hardware is a significant advantage. Peripheral compatibility was generally good. I²C communication was verified using an OLED display, PWM generation was tested using a servo motor, and standard GPIO functionality operated as expected. While a few libraries required platform-specific alternatives due to the Zephyr-based architecture, suitable replacements were available and functioned correctly once identified. One of the most useful discoveries during testing was the flexibility provided by App Lab and the RPC bridge. Traditionally, a project requiring Linux processing and real-time hardware control would involve at least two separate boards communicating through serial links or custom protocols. The UNO Q eliminates much of that complexity. The Linux processor can focus on networking, user interfaces, AI inference, or data processing while the STM32 handles sensor acquisition and timing-sensitive operations. App Lab further simplifies this arrangement by managing deployment and communication between both processors, allowing developers to concentrate on application development rather than infrastructure. The board also serves as an accessible introduction to STM32 development. Many hobbyists are aware of STM32 microcontrollers but are often discouraged by the complexity of HAL libraries, low-level peripheral configuration, and vendor-specific tooling. By supporting the familiar Arduino development workflow, the UNO Q lowers the barrier to entry while still exposing users to industrial-grade STM32 hardware. The hardware itself also presents several thoughtful design decisions. Support for both USB-C and 7–24V DC power input increases deployment flexibility, while the apparent use of multiple power rails and protection circuitry suggests that considerable attention has been given to power management. The ability to access the board remotely over the network proved especially convenient during development, reducing cable clutter and making the board feel more like a miniature server than a traditional development board. Ultimately, the Arduino UNO Q should not be viewed solely as an Arduino board, nor solely as an SBC. It occupies a space somewhere between the two. Users looking only for maximum Linux performance may find faster SBCs elsewhere, while users interested only in simple microcontroller projects can find cheaper alternatives. The UNO Q becomes most compelling when a project requires both worlds simultaneously. For robotics, industrial monitoring, IoT gateways, data acquisition systems, edge AI applications, sensor-rich projects, educational environments, and rapid prototyping, the combination of Linux computing and STM32 real-time control on a single board is extremely powerful. Rather than replacing existing platforms, the UNO Q brings together capabilities that would normally require multiple devices, making it one of the most interesting and versatile development boards currently available in the Arduino ecosystem. The UNO Q may still be a young platform, and its software ecosystem continues to evolve, but its underlying concept is strong. After evaluating both its SBC and microcontroller capabilities, it is clear that the board offers far more than benchmark numbers alone. Its greatest strength lies in how effectively it combines two traditionally separate development environments into a single cohesive platform, enabling developers to build complex connected systems with considerably less hardware and software overhead than would otherwise be required. This was my first RoadTest, so I approached it by performing the standard benchmarks and evaluations that I found commonly used in other SBC reviews and RoadTests. Reading those reviews gave me an understanding of how such evaluations are typically conducted, but carrying out the tests myself proved to be an entirely different learning experience. Working directly with the hardware taught me far more than theory alone could have. From finding compatible backports of benchmarking utilities and understanding CPU governors and their operating modes to interpreting system logs and troubleshooting unexpected issues, every challenge helped me gain practical knowledge and hands-on experience. Throughout this review, I have tried to keep the content simple and easy to follow while covering the board's features and capabilities. I would like to sincerely thank the entire Element14 and Arduino teams for selecting me as a RoadTester and providing me with the opportunity to evaluate this excellent hybrid SBC platform. As this was my first RoadTest, I did extend the schedule slightly while learning the review process, but I made every effort to perform meaningful tests and present accurate observations. I hope this review proves useful to anyone considering the Arduino UNO Q and meets the expectations of both the RoadTest program and the community. Thank you for taking the time to read it to the very end. I would greatly appreciate any feedback, suggestions, or comments, as they will help me improve my future reviews.Raspberry Pi, Banana Pi, Hybrid systems(SBC+MCU)Development Boards & ToolsUnderstanding the concept and working of dual brain architecture and how things were being executed under the hood. The new feature of creating custom bricks is also a bit hard and needs more documentation.https://community.element14.com/products/roadtest/f/forum/57040/is-there-a-place-we-can-request-roadtest-products/236219Wed, 24 Jun 2026 12:16:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:519c6ede-d3ce-4bc1-b80f-ac387f09829ecstantonMaybe a bit of creativity, part of engineering is working within limits, right?https://community.element14.com/products/roadtest/f/forum/57040/is-there-a-place-we-can-request-roadtest-products/236212Tue, 23 Jun 2026 16:32:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:6b3cd1aa-bf43-4993-b863-855ef9699ab1MATRIX7878Oh man, very well. I looked and could not find anything similar to test. Hopefully it is not too far into the future that it goes up.https://community.element14.com/products/roadtest/f/forum/57040/is-there-a-place-we-can-request-roadtest-products/236211Tue, 23 Jun 2026 15:50:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:7b2efbd5-2f25-4e66-9b86-b7a2b88e4e18OwainMI'm sorry that the current limit doesn't cover what you'd like to test, as your plan sounds interesting. At the moment, unfortunately, the product value does have to stay at or under the $175 limit. It's possible that this could increase in the future however.https://community.element14.com/products/roadtest/f/forum/57040/is-there-a-place-we-can-request-roadtest-products/236210Tue, 23 Jun 2026 15:27:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:fe9816e5-b969-41d0-97f4-afc8b8ac511fMATRIX7878Hey OwainM , I would do the open call, but the device I'm looking to test is over the max price set on the open call. It would cost more than $175 USD (anywhere from $120-$350 more). I was planning on doing the RoadTest based on what I get, then create my own custom PCB as the host board because what I am looking for is a daughter board that can be interchanged and then do a review of it on my custom board. Of course, it would take quite some time to design the board and also have built and would update my review at that time. Essentially, I would make a two-part review. Is the price capable of going up? The only other boards that I would want that are similar are not available on any Avnet company sites. Thank you though for this updatehttps://community.element14.com/products/roadtest/f/forum/57040/is-there-a-place-we-can-request-roadtest-products/236209Tue, 23 Jun 2026 15:03:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:6da66766-d585-400d-9ada-2136487813fcOwainMHey MATRIX7878 , We've had an idea based around your thread in the works. How about applying for our RoadTest Open Call ?https://community.element14.com/products/roadtest/f/forum/56742/are-there-any-products-you-own---that-you-d-like-to-write-a-roadtest-review-for/236208Tue, 23 Jun 2026 14:57:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:5028405f-561d-4918-aeb6-f2efdb3ee504OwainMAnnouncement! We've had a little something in the works based around this idea for a while now, take a look over at our RoadTest Open Call !https://community.element14.com/products/roadtest/rt/roadtests/722/roadtest_open_callTue, 23 Jun 2026 14:48:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:9c4bccf7-f4e5-426e-8fd3-69251a59f765JoRatcliffeHas there ever been a product that you wanted to test and review but it has not been featured in another RoadTest here on the community? Now is your chance! Submit an application to review any product of your choosing under $175 (USD) on the Newark / Farnell / element14 online stores . The ten best applicants will receive their requested product for FREE and get to keep it in return for writing a review. How To Apply Click the button on the right to enroll by putting in your application. Here is an idea of what to include in your application: The product you want to review and why you have chosen it The details of the test plan or review you plan on carrying out A brief description of your background, general experience level, and familiarity with the technology (embedded systems / microcontrollers / programming / prototyping etc.) A more innovative and/or thorough review of a new or overlooked product is more likely to give you a chance of being selected, as long as the ambition of your review matches up with your experience level and familiarity with the technology. Example Product Review Possibilities So, what kind of product could you review? A single board computer (eg. Arduino Uno Q) An all-in-one kit (eg. development kit, motor control kit, optical, wireless transceiver kit) Bench equipment (eg. power supply, oscilloscope, soldering station) Once you know the product you want to receive and review, what sort of review could you write? The only limit is your imagination but here are a few examples: The out-of-the-box experience of a product - Do an unboxing, power the product up, check any pre-programmed options or features, and follow the user guide. Performance test - Measure accuracy and see if the product is faster/slower than specifications Cybersecurity evaluation - Test for security holes and vulnerabilities Test a product to destruction! - Show how a product holds up in hazardous conditions such as high temperatures or rugged environments. Important Dates Enrollment period: 23rd June - 30th August Enrollment deadline: 30th August Units ship: 4th September You begin reviewing: 11th September Post your review by: 11th October Terms & ConditionsTech Reviewelectronics reviewerRoadTesthardware review open callelectronic reviewelectronic testingtech review competitionelectronic product reviewnew electronic reviewroadtest-open-callopen call opportunitieselement14 Communityhttps://community.element14.com/products/roadtest/m/managed-videos/151490Tue, 23 Jun 2026 12:22:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:eefba9f3-dff0-4d5c-a402-2e1fcdac989dsaramichttps://community.element14.com/products/roadtest/m/managed-videos/151489Tue, 23 Jun 2026 12:22:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e9fdc998-6ccf-4661-9de7-5ecdc4a1cee4saramichttps://community.element14.com/products/roadtest/rv/roadtest_reviews/1919/foil_headwave_aluminium_attenuator_devkit_-_reviewTue, 23 Jun 2026 12:20:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e5d5bb40-6665-4c56-b2c3-db1e2448281dsaramicThe Package Arrives There are road tests, and then there are road tests . When element14’s April 1st offering landed in my inbox — the element13 Foil Headwave Aluminium aTtenuator DevKit — I was, naturally, all in. Element 13 on the periodic table is aluminium. I should have known. The kids’ faces said it all. There is a special kind of disappointment when you have built up “electronics delivery” energy and the box contains thirty pre-cut sheets of kitchen foil. Was the foil packaging something? No. The foil was the thing. Still — a devkit is a devkit. I decided to take the brief seriously, pulled out some lab equipment and a Jupyter notebook, and went to work. What Did We Actually Receive? Thirty sheets of aluminium foil, pre-cut to a consistent size. First observation: the cutting is genuinely precise. All five sheets I measured came in at 299×273 mm ±0.25 mm — better tolerance than most craft cutters manage. Whatever tooling produced these, it is not scissors. I think this had a level of novelty for me, as I am used to rolls of aluminium foil and having to cut them myself. Oh and there were stickers - I was so excited about the foil, I forgot to put the stickers in the shot Material Characterisation Thickness: A Tale of Three Methods The nominal spec for Aluminium foil is a thickness of 16 µm. I tried three approaches to verify this. Released caliper jaw (20-layer stack, 6 sections): 15.0–19.5 µm per sheet, mean 17.6 µm. Too high — air gaps between the stacked layers inflate the reading. Firm caliper press (same stack): 10.5–13.5 µm per sheet, mean 12.1 µm. Too low — cheap digital callipers might flex under some jaw force, pulling the reading down. The two failure modes bracket the truth from opposite sides, which is itself a useful result. Mass method — five sheets, two weighings each, three bundle weighings: method mass/sheet thickness Δ from nominal individual mean 3.160 g 14.34 µm −1.66 µm bundle mean 3.157 g 14.32 µm −1.68 µm (−10.5%) The foil is 14.32 µm — 10.5% thinner than the 16 µm nominal predicted. The mass method has no air-gap or frame-flex problem. Uncertainty is dominated by the ruler measurement of sheet area ( ±0.25 mm on 299 mm ≈ 0.17% ), giving thickness uncertainty of ±0.02 µm . The caliper method, by contrast, had ±4.5 µm spread from air gaps alone. Lesson: for thin compressible stacks, weigh them — don’t measure them. Tensile Strength A 10 mm wide strip, tape-reinforced at each end, hung from a fixed point with a cup of water added incrementally until failure. Three trials: trial failure load UTS 1 997 g 68.3 MPa 2 1,004 g 68.7 MPa 3 1,010 g 69.1 MPa mean 1,004 g ± 6 g 68.8 ± 0.4 MPa Only 12.6 g spread across three trials — 1.3% variation. The mean UTS (Ultimate Tensile Strenght) of 68.8 MPa is below the ~80 MPa often quoted for aluminium foil; that figure assumes work-hardened material. This product is clearly O-temper (fully annealed), standard for kitchen foil: softer, more foldable, 65–75 MPa typical. The ±0.4 MPa standard deviation confirms very uniform material throughout the roll. HCl Dissolution Hardware-store muriatic acid, diluted 1:3 in water. A half-sheet piece ( 1.58 g ) dropped into a tared beaker. Mass tracked every 30 seconds as H₂ escapes. Reaction: 2Al + 6HCl → 2AlCl₃ + 3H₂↑ Stoichiometry shortcut: Al dissolved (g) = H₂ lost (g) × 9 Phase 1 — cold outdoor conditions, undisturbed: 74% of the foil dissolved in 9.4 minutes Rate slowed because part of the foil was sitting above the liquid line The interesting result came when I added more acid, impatient with the remaining 26%. The exothermic reaction had already warmed the solution slightly; fresh acid tipped it into thermal runaway . Rate jumped from ~0.01 g/min to >0.5 g/min over two minutes; the solution heated visibly and fumed. Of the 5.5 g total mass lost in Phase 3, only ~0.046 g was H₂ from the remaining aluminium — the other 5.5 g was HCl vapour and water evaporating from the hot solution . This autocatalytic loop cold start → slow reaction → exothermic heat → faster reaction → more heat is a neat demonstration of why temperature control matters in wet chemistry, and why you do this outdoors with safety glasses. It also explains why two of my three attempts were too vigorous to measure cleanly. TIP: For a clean kinetics curve: smaller piece (~0.4 g), larger volume (~150 mL), room temperature. Should complete in 3–5 minutes with no runaway. RF Attenuation — 433 MHz A continuous-carrier 433 MHz transmitter (FS1000A module, DATA pin held HIGH — a two-line Arduino sketch), the TinySA Ultra as receiver, fixed 30 cm apart with foil layers added one at a time. The theoretical basis: skin depth of aluminium at 433 MHz is 3.94 µm . The foil is 14.32 µm thick — 3.6 skin depths — which the plane-wave skin-depth model predicts gives 31.6 dB attenuation per layer . A single sheet should be close to opaque. Measured results — 24 layers, 30 cm indoor, TinySA Ultra: layers dBm attenuation 0 −33.9 0 dB 1 −38.9 −5.0 dB 5 −40.4 −6.5 dB 10 −44.4 −10.5 dB 15 −52.4 −18.5 dB 20 −58.9 −25.0 dB 24 −63.9 −30.0 dB The measured slope is approximately −1.25 dB/layer — about 25× less than the theoretical 31.6 dB/layer. The result is real and reproducible, but the discrepancy needs explaining. Why so much less than theory? Three effects combine: Fresnel diffraction — at 433 MHz (λ = 69 cm), the first Fresnel zone at the midpoint of a 30 cm path has radius ~23 cm. The foil is 27 cm wide, so it covers only ~36% of that zone; signal diffracts around the exposed outer ring. Room multipath — signal reflects off walls, ceiling, floor, and nearby objects. These indirect paths arrive at the TinySA from angles the foil does not block. Only the direct path is attenuated. Near-field geometry — at 30 cm = λ/2 the coupling is partly near-field rather than a clean plane wave, making the simple skin-depth model a poor approximation. Despite the reduced per-layer efficiency, the experiment still shows a clear and measurable 30 dB total attenuation over 24 layers. The foil works; the indoor setup just can’t isolate the direct path cleanly. Outdoors at 3–5 m with the Fresnel zone properly covered, each layer would approach the theoretical value. Summary What element14 sent me was, let’s be honest, a pack of kitchen foil. But not just kitchen foil: Precisely cut to 299×273 mm, consistent to ±0.25 mm across 30 sheets 14.32 µm actual thickness — 10.5% thinner than the 16 µm nominal, but remarkably uniform O-temper aluminium — UTS 68.8 MPa, soft, annealed, consistent to 1.3% across trials Dissolves in dilute HCl with an entertaining exothermic finale if you are not careful 30 dB total attenuation at 433 MHz — measured over 24 layers indoors; theory predicts 31.6 dB for a single layer, but multipath and Fresnel diffraction reduce the effective per-layer result to ~1.25 dB in a real room The tongue-in-cheek devkit framing holds up better than expected. The material is genuinely well-characterised, the cutting is precise, and the electromagnetic properties are real. I note that you cannot seem to be able to get the same DevKit on the element14 website anymore, but the same dimentions and texture can be bought from: https://www.elpack.co.uk/shop/aluminium-foil-sheets-pack-of-500/ Future Work 2.4 GHz (nRF24L01, Zigbee) — shorter wavelength, even thinner skin depth; expect attenuation in fewer layers mmWave radar — at 24/60/77 GHz the skin depth drops to ~0.3–0.5 µm ; the 14.32 µm foil is 28–48 skin depths thick and acts as a near-perfect reflector rather than an absorber; interesting to verify with the mmWave sensor whether a single sheet registers as a hard target, and whether crumpling the foil changes the radar cross-section — a flat sheet is a specular reflector (strong return only at normal incidence) while a crumpled sheet scatters in all directions. DIY parallel-plate capacitor — two full sheets + baking paper dielectric → measure capacitance → compute ε₀ → derive the speed of light from c = 1/√(ε₀μ₀) The April Fools devkit that became a Maxwell electromagnetism experiment. All data, calculations and plots in the accompanying Jupyter notebook .chemistryattenuationrfmechanical characteristicsKitchen aluminium foil compares pretty wellElectromechanicalgetting the level of attenuation I was expecting, I really should have tried with a higher frequency to get more effective resultshttps://community.element14.com/products/roadtest/rv/roadtest_reviews/1918/psoc_edge_e84_ai_kit_from_teardown_to_doomsday_cyberdeckSun, 21 Jun 2026 19:55:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:64f761f5-e275-4a77-9169-f5a7adad2444giemme2009PSOC Edge E84 AI Kit — RoadTest Part 1: First look (unboxing, teardown, demos, toolchain) • Part 2: The Doomsday Cyberdeck (build plan) PSoC Edge E84 AI Kit RoadTest — Part 1 First look: unboxing, bring-up, teardown, demos, and the toolchain Status of this part. The hands-on work is done from my own bench: unboxing, first power-up, PC recognition, the documentation path, a microscope teardown (every part cross-checked against Infineon's kit docs), both factory demos, installing the Edge AI toolchain, and building, flashing, and running my own first project . 1. What this part covers This first part evaluates the kit as it ships: unboxing and bring-up, a microscope teardown of the board, the two pre-loaded factory demos, installing the Edge AI development tools, and building and running a first project. Part 2 then takes the same board off the bench entirely, turning it into the Doomsday Cyberdeck — a self-contained, solar-powered, air-gapped Edge AI node. 2. Unboxing The kit arrives in a compact, high-quality retail box — Infineon's "How will you bring AI to life?" packaging, small enough to sit in your palm. Inside, the board and the camera module are each held in cut black foam, together inside an antistatic bag — well protected for shipping. The two items in the box match the quick-start guide's contents list: the PSOC Edge E84 AI board and a 0.3 MP camera module. The box itself doubles as an orientation to the platform. Its back panel lays out the DEEPCRAFT ecosystem and the kit's six target use cases — artificial intelligence, voice, radar, audio, movement, and vision — and carries a QR code straight to the quick-start guide. Figure 1— Kit contents The board and the OV7675 camera module in the foam tray. Figure — Box panel The capability icons and QSG QR code on the box. 3. First power-up Following the quick-start guide, I connected the board to the PC with the USB-C cable at connector J1 . The amber power LED ( LED5 ) came on, and the green LED ( LED1 ) began blinking — the sign that the pre-loaded out-of-box demo is running. The board was live within seconds of plugging in. Figure — Powered board The board powered over USB-C with its LEDs lit. 4. Serial terminal access and PC recognition On my Windows 11 laptop the board was recognised immediately — no driver hunting. It enumerated as KitProg3 USB-UART (COM5) under Ports (COM & LPT) in Device Manager. I then opened Tera Term on COM5 (the KitProg3 USB-UART bridge), and after reset the board presented the OOB demo menu: *************** PSOC Edge E84 AI Kit OOB demo *************** 1. Voice Assistant 2. Gesture Detection Enter your choice: Selecting an option launches the matching demo. Figure — Device Manager The board shown as KitProg3 USB-UART (COM5) Figure — Boot menu The OOB demo menu in Tera Term. 5. Documentation Getting started was guided by the Quick Start Guide , reachable directly from the QR code on the box (or at infineon.com). It's a short, four-page document that walks through the kit contents, connecting and powering the board, and bringing up the UART terminal — enough to reach the demos quickly. Each code example also ships with its own README and a design/implementation document inside the project 6. Board teardown — what's actually fitted I went over the board under a USB microscope, read the markings off the major chips, and cross-checked each against Infineon's published kit documentation. Every part below is confirmed two ways: I could read it on the silicon, and it matches the kit's official feature list (and the BSP description in the tooling). The application processor — the PSOC Edge E84 itself The headline part, in the centre of the board, is marked PSE846GPS2DBZC4A — the PSOC Edge E84 MCU . It pairs an Arm Cortex-M55 (with Helium DSP) and an Ethos-U55 NPU in a high-performance domain with a low-power Cortex-M33 (with Infineon's NNLite accelerator) for always-on work, plus a 2.5D GPU for the display path. Everything else on the board exists to feed this chip. Figure — PSOC Edge E84 main MCU PSE846GPS2DBZC4A in the centre of the board. The chip under the QR label — KitProg3 Under a small QR/serial label sat CY8C5868LTI-LP039 , a Cypress/Infineon PSoC 5LP . On this board it's the KitProg3 — the onboard programmer/debugger and USB-UART (and USB-I2C) bridge: the chip behind the "one USB-C cable does everything" experience, and the same KitProg3 that showed up on COM5 in Section 4. Date code 2325 (week 23, 2025), Taiwan. Figure — PSoC 5LP under the label CY8C5868LTI-LP039 , found beneath a QR label. Wireless — Murata Type 2FY (AIROC CYW55513) The module by the antenna carries the Murata logo and a 2FY mark (internal marking SS4D27002 ). That 2FY identifies it as the Murata Type 2FY (LBEE5HY2FY) module, which carries Infineon's AIROC CYW55513 Wi-Fi + Bluetooth (BLE 5.4) combo. Both radios come from this one module at the board edge, fed by the printed antenna. Figure — Wireless module Murata Type 2FY, next to the PCB antenna. Radar — XENSIV BGT60TR13C at U5 The radar is at U5 , under the RADAR silkscreen, with an antenna icon and the antennas etched into the PCB beside it. The package marking itself was too small to read, but the kit documentation lists the radar as the XENSIV 60 GHz BGT60TR13C , so that's the part at U5, antennas built into the board. (The gesture demo in Section 8 confirms it's populated and working.) Figure — Radar at U5 The RADAR silkscreen, antenna icon, and the package at U5. Memory — 512-Mbit NOR flash + 128-Mbit HyperRAM S25HS512T (Cypress/Infineon Semper ) — the 512-Mbit Quad-SPI NOR flash for code and data. 7KS1283GAHV02 (Cypress/Infineon, S27KS family) — the 128-Mbit Octal HyperRAM (PSRAM) , the fast external working memory the processor and graphics path draw on. Figure — FlashRAM S25HS512T Figure — HyperRAM 7KS1283GAHV02 . Audio — TI TLV320DAC3100 DAC3100 with the TI mark — the Texas Instruments TLV320DAC3100 , a stereo audio DAC with integrated headphone/speaker amplifier: the output side of the board's audio path Figure — Audio DAC DAC3100 (TI). The bundled camera — OmniVision OV7675 The kit's camera is a separate module rather than a part on the main board: an OmniVision OV7675 0.3 MP (photographed in the unboxing above). Environmental sensor — XENSIV DPS368 A small sensor carrying the marking DPS368 Figure — DPS368 The barometric pressure sensor, DPS368 Microphone — MEMS (PDM) One of the board's MEMS microphones , identified under the scope by its circular acoustic port. The kit carries two PDM microphones — the pair the Voice Assistant demo (Section 7) uses — and the package marking isn't legible in the capture, so this is recorded by its port rather than a part number. Figure — MEMS microphone The acoustic port of one of the onboard mics. The verified component map Marking (read on the chip) Part Role Confirmed by PSE846GPS2DBZC4A PSOC Edge E84 MCU (M55 + M33 + Ethos-U55 NPU + 2.5D GPU) Main application / AI processor Photo + kit docs + BSP CY8C5868LTI-LP039 Cypress/Infineon PSoC 5LP KitProg3 — onboard debugger + USB-UART Photo + kit docs + COM5 enumeration SS4D27002 / 2FY + Murata Murata Type 2FY (LBEE5HY2FY), AIROC CYW55513 Wi-Fi + Bluetooth (BLE 5.4) Photo + kit docs + BSP U5 (silkscreen RADAR ) XENSIV BGT60TR13C 60 GHz radar Touchless gesture sensing Location from photo; part from kit docs; working in demo S25HS512T Cypress/Infineon Semper NOR flash 512-Mbit Quad-SPI NOR (code/data) Photo + kit docs + BSP 7KS1283GAHV02 Cypress/Infineon HyperRAM (S27KS family) 128-Mbit Octal HyperRAM (working RAM) Photo + kit docs + BSP DAC3100 ( TI ) TI TLV320DAC3100 Audio DAC + amplifier Photo OV7675 (module) OmniVision OV7675 0.3 MP bundled camera Photo + kit docs 7. Factory demo — voice assistant From the boot menu I selected the Voice Assistant. The demo announces itself as "PSOC Edge MCU: Voice Assistant Demo," with the wake word "Okay Infineon" and a fixed command set aimed at controlling a light — on/off, enable/disable, brighter/dimmer, set brightness to a percentage, toggle, and change state. The blue user LED tracks the interaction: solid while waiting for the wake word, then breathing once the wake word is caught and it's listening for a command, and solid again after the command runs. In use, the demo caught the wake word and resolved each spoken command to a named intent, printed live in the terminal. For example, "switch on the light" resolved to TurnOnLight , "switch off the light" to TurnOffLight , and "change the light state" to ToggleLight — each shown as a "Wake word detected! / Command detected / Intent name" block as I spoke. The voice path exercises the board's onboard PDM microphones identified in the teardown. Figure — Voice assistant demo The command list and wake-word prompt. Figure — Commands recognized The terminal showing detected commands and their intents, with the user LED lit. 8. Factory demo — radar gesture detection The second demo is gesture detection, which the terminal identifies as a DEEPCRAFT Ready Model . Its on-screen instructions are to stand the board vertically (no tilt) and perform Push, Swipe Left, Swipe Right, Swipe Up, or Swipe Down at roughly 60 cm in front of the radar, with the RGB LED blinking red on a successful detection. Running it, the board recognized the push and all four swipe directions, printing each one to the terminal as I performed it — a continuous stream of SwipeLeft , SwipeRight , SwipeUp , SwipeDown , and Push lines. Because the sensing is done by the radar at U6, the demo runs with nothing else attached, which also confirms the radar is populated and working on the board. Figure — Gesture demo instructions The DEEPCRAFT Ready Model gesture screen. Figure — Gestures recognized The terminal log of detected gestures. 9. Edge AI tooling Infineon's development flow uses two pieces: ModusToolbox (the embedded toolchain and Eclipse-based IDE) and DEEPCRAFT Studio (the Edge AI / ML model tooling). Both are installed through the Infineon Developer Center, and the one prerequisite is a free myInfineon account — I had to register before the downloads would start. I chose the standard installation. The install. ModusToolbox is installed via its setup tool (ModusToolbox Setup 1.4), which pulls the standard package set automatically: ModusToolbox Tools Package 3.8.0 Arm GNU Toolchain (GCC) 14.2.1 ModusToolbox Edge Protect Security Suite 1.7.0 ModusToolbox Programming tools 1.8.1 ModusToolbox CAPSENSE and Multi-Sense Pack 1.5.0 DEEPCRAFT Studio (version 5.12) installs alongside and sets up its own environment — Visual C++ Runtime, Cygwin, Python, and ml-coretools — which is the slower part of the process (the installer warns it "might take a while"). First project — choosing the BSP. In Eclipse for ModusToolbox, the Project Creator (2.70) walks you through selecting a board support package. The board is listed under PSOC Edge BSPs as KIT_PSE84_AI (device PSE846GPS2DBZC4A, LBEE5HY2FY Wi-Fi/BT). Usefully, the BSP's own description doubles as a confirmation of the teardown — it lists the same PSE846GPS2DBZC4A MCU, 512-Mbit QSPI flash, 128-Mbit Octal RAM, LBEE5HY2FY module, KitProg3, R-Pi-compatible MIPI-DSI, analog and digital microphones, 6-axis IMU, 3-axis magnetometer, pressure and humidity sensors, and radar. The example library. What stands out is the breadth of ready-made template applications offered for this board, grouped by area: Getting Started — Empty Application, Hello World Audio — DEEPCRAFT Voice Assistant (and its deployment) Machine Learning — DEEPCRAFT Data Collection; Deploy Audio / Motion / Radar / Vision; Ready Models; Face ID Demo; Profiler Graphics — LVGL demo, single/double buffering, WebRTC + AI Vision Sensing — Sensor Hub IMU; OV7675 + BGT60TR13C USB and Wi-Fi streaming Peripherals — PDM-to-PCM, LittleFS, UART-with-DMA, emUSB device, watchdog, RTC, serial-flash XIP, and more Security — basic/encrypted secure boot, SHA-256, protect bootloader, OTA update, SRAM loading Bluetooth / Wi-Fi — BLE FindMe, Wi-Fi onboarding over BLE, MQTT, HTTPS client/server, secure TCP, web server The factory voice and gesture demos I ran earlier correspond to the DEEPCRAFT "ready model" examples in this list, so the path from "the demo that shipped on the board" to "the same thing as a project I can open and modify" is clear. Figures — Tooling 1 ModusToolbox Setup downloading the toolchain Figures — Tooling 2 DEEPCRAFT Studio installing its environment Figures — Tooling 3 Project Creator with the KIT_PSE84_AI BSP 10. First project: building and running an example To check the full development loop — not just installing the tools but getting something onto the board — I created and ran the Hello World example. Starting Project Creator in Eclipse for ModusToolbox, the connected board was auto-detected (listed under "Detected Devices" as KIT_PSE84_AI), so I didn't have to choose the BSP manually. From New Application → Getting Started I selected PSOC Edge Hello World , a simple example that prints a "Hello world" message over UART and blinks a user LED from the Cortex-M33. One thing this example makes clear is the architecture of a PSOC Edge E84 application. Each app has a dual-CPU, three-project structure : a CM33 secure project (SPE), a CM33 non-secure project (NSPE), and a CM55 project. At reset a secure boot flow runs from ROM with the device's secure enclave as the root of trust, hands off to the secure CM33, then to the non-secure CM33 — which initialises clocks, pins, and the retarget-io UART — which in turn enables the CM55. The debug UART reaches the PC through the KitProg3 virtual COM port, and User LED1 blinks once a second. I built the project (toolchain validation passed, GCC_ARM), programmed it to the board over KitProg3, and opened Tera Term on COM5. The terminal showed the expected output: *************** PSOC Edge MCU: Hello world *************** Hello World! For more projects, visit our code examples repositories: https://github.com/Infineon/Code-Examples-for-ModusToolbox-Software So the complete flow — install → auto-detected BSP → create project → build → flash → verify on the terminal — works end to end. The DEEPCRAFT machine-learning examples (Section 10) are the natural next step from here. Figures — Hello World The auto-detected BSP; the Hello World template selected; the example open in the editor; and the "Hello World!" output in Tera Term. Coming in Part 2 — The Doomsday Cyberdeck Part 1 took the kit as far as it goes on the bench: unboxed, torn down, demoed, and running my own first project. Part 2 (below) takes the same board off the bench entirely and turns it into a self-contained, solar-powered, air-gapped Edge AI node — the Doomsday Cyberdeck . The plan adds four things to the board — a 4.3-inch MIPI-DSI display , an OPEN-SMART SPI microSD card, a Rii 518BT Bluetooth keyboard (with physical buttons as the robust fallback), and a 3000 mAh+ protected LiPo with solar charging — so the device boots from its own battery, recharges from the sun, shows its own dashboard, keeps its own logs, and runs its AI with no PC, no mains, and no network. PSoC Edge E84 AI Kit RoadTest — Part 2 The Doomsday Cyberdeck: a self-contained, solar-powered, off-grid Edge AI node What this part is. A build plan , not a finished build. Everything below is design intent and the open questions I still have to settle on the bench — nothing here is reported as a tested result. Part 1 covered the kit as it ships (teardown, factory demos, toolchain, a first project). This part takes the same board off-grid. 1. The idea The premise is simple: take the PSOC Edge E84 AI Kit and turn it into a device that needs nothing else — no PC, no wall power, no network. A single board that boots from its own battery, recharges from the sun, shows what it's doing on its own screen, takes input from its own keys, keeps its data on its own card, and runs its AI entirely on-device . A self-contained edge-AI node you could set down anywhere and leave running. This is what I'm calling the doomsday cyberdeck — "doomsday" in the sense of fully self-reliant and air-gapped , not as a gimmick. The design target is an instrument that keeps sensing, deciding, and logging when there is no cloud, no Wi-Fi, and no mains. The E84 is a surprisingly good fit for this: The Cortex-M55 + Ethos-U55 NPU runs neural models locally — the whole point of an offline node. The low-power Cortex-M33 can stay awake for always-on duties while the heavy compute sleeps. The board already carries a rich sensor suite (identified in Part 1's teardown): a 60 GHz radar , PDM microphones , a DPS368 pressure/temperature sensor, an SHT40 humidity sensor, a BMI270 IMU, a BMM350 magnetometer, and the OV7675 camera. That's most of an environmental + presence + vision sensing stack already on the board. It's low power and runs from 1.8 V / 3.3 V rails off a single Li cell (via the onboard boost/bucks), which is exactly what a solar-fed device needs. 2. System overview The board is the brain and the sensor array; the four added parts give it a face (display), a memory (microSD), hands (keyboard/buttons), and a heart that never needs the wall (solar + battery). 3. Bill of materials # Part Role Interface to the board — PSOC Edge E84 AI Kit Compute + sensing core — 1 4.3-inch MIPI-DSI display On-device screen / UI MIPI-DSI connector (R-Pi-compatible) 2 OPEN-SMART microSD breakout Local mass storage SPI on the expansion I/O header 3 Rii 518BT Bluetooth keyboard Input / navigation Bluetooth (CYW55513) 4 3000 mAh+ protected LiPo + solar panel + Li solar charger Off-grid power Cell → J3 (3–5 V); solar → charger → cell 4. The screen — 4.3-inch MIPI-DSI display Role. The deck's face. Instead of a serial console on a laptop, the unit renders its own dashboard: current mode, live sensor readings, AI output, alerts, and battery/solar status. Connection. The board exposes an R-Pi-compatible MIPI-DSI connector (confirmed in the BSP description in Part 1), which is the intended path for a 4.3-inch DSI panel. The E84's 2.5D GPU drives the display, and the LVGL graphics example ("PSOC Edge Graphics LVGL Demo", plus the single/double-buffering example) is the starting point for the UI. UI plan. An LVGL layout with a status header (mode, battery, solar in/out), a live sensor panel (pressure trend, temp/humidity, compass heading, radar presence), an AI-output area (voice intent / vision result), and a few menu screens the keyboard or buttons can drive. Power. Roughly 1.0–1.3 W with the backlight on — the backlight dominates, so PWM dimming and blanking the panel when idle are the main power levers. Open question. 4.3-inch DSI panels differ in resolution (commonly ~480×800 or 800×480) and in the DSI bridge/controller they use. The panel has to either match what the PSOC Edge graphics stack already supports or need a panel-init/driver written for it. Confirming panel compatibility is the first display task. 5. The memory — OPEN-SMART SPI microSD Role. Mass storage for an off-grid node: time-series sensor logs, captured events (audio/radar/vision), AI model files, and offline reference data (maps, field guides, manuals) that can be browsed on the display. The onboard 512-Mbit QSPI flash is tiny by comparison; a microSD card adds gigabytes of removable, non-volatile storage. Connection. The OPEN-SMART breakout is a plain SPI SD-card adapter. It wires to the board's SPI on the expansion I/O header — SCK , MOSI , MISO , CS , plus 3V3 and GND (exact pins per the BSP pin map). The card runs in SPI mode with a FatFs filesystem (FAT32), so a card pulled from the deck reads on any PC. Log format (illustrative). A field-logging record might look like: timestamp,mode,channel,value,unit,note 000001,env,pressure,1007.2,hPa, 000002,env,humidity,57.0,%RH, 000003,radar,presence,1,,approach@~1m 000004,voice,intent,TurnOnLight,,wake=OkayInfineon 000005,power,battery,3.91,V,solar=charging . 6. The hands — Rii 518BT keyboard For input I have two paths, and for a self-reliant device the robustness trade-off matters more than comfort . Rii 518BT over Bluetooth. The board's AIROC CYW55513 (BLE 5.4 + Classic BT) would act as a Bluetooth HID host , accepting the keyboard's key (and touchpad) events. This gives full text entry and a pointer — nice for menus and labels. Open question — this is the biggest software unknown in the build. Receiving a keyboard requires a BT HID host profile on the device side; having the radio is not enough. Infineon's AIROC BT examples lean toward HID device and specific profiles, so HID host support has to be confirmed. It also depends on how the Rii 518BT pairs: a BLE HID (HOGP) host is far more tractable than a Classic-BT HID host. This gets validated before anything is built on top of it. 7. The heart — 3000 mAh+ protected LiPo + solar The voltage works out nicely. The board has a battery input — connector J3 , rated 3–5 V — that takes a single lithium cell directly, and the board makes its own 5 V / 3.3 V / 1.8 V rails from that input via the onboard boost and bucks. A LiPo at 3.0–4.2 V sits right in range, so no separate boost-to-5 V module is needed . The one catch (from Part 1): J3 is an unpopulated rework header , so a JST connector has to be soldered to it first. The cell. A 3000 mAh+ protected LiPo — protected meaning an over-/under-voltage and over-current PCB on the pack (essential for an unattended, solar-charged device). Solar. A small panel (e.g., 6 V, ~2–5 W) feeds a Li-ion solar charge controller — an MPPT-class charger such as a CN3791 or CN3065 is a better match for a solar source than a plain TP4056, because it holds the panel near its maximum-power point. The controller does CC/CV charging to 4.2 V; the protected cell is the safety backstop. Charging-while-running needs a load-sharing arrangement so the deck can draw from the panel and top up the cell at the same time. Power budget (estimate — to be measured on the bench): Subsystem Approx. draw Board: M55 + NPU + M33, radar, mics ~0.6–0.8 W 4.3" display + backlight ~1.0–1.3 W microSD writes + Bluetooth link ~0.2 W Total, screen on + AI + radar active ~2 W (≈0.5–0.7 A at the cell) Runtime and the solar question. At ~2 W continuous, a 3000 mAh cell gives roughly 4–5 hours before a safe cut-off. But a doomsday node should rarely run flat-out: with the M33 awake for always-on sensing and the M55 + display gated (radar/voice wake the heavy compute only on an event), average draw can fall to a fraction of a watt, stretching the cell to days . Sustained ("indefinite") operation is then a solar-harvest-vs-load equation, and I'd rather give the math than a promise: A ~2 W panel at ~4 useful sun-hours ≈ 8 Wh/day harvested. A duty-cycled node averaging ~0.3 W ≈ 7.2 Wh/day consumed → net positive , runs indefinitely. The same node held at ~2 W continuous ≈ 48 Wh/day → solar cannot keep up; the battery is just a buffer. So the design rule is: aggressive duty-cycling + event-driven wake is what makes the solar path actually self-sustaining. Panel wattage and real-world sun hours then size the margin. Open questions. Mounting the J3 connector; getting the load-sharing path right so it runs while charging; and sizing the panel against the chosen duty cycle and local sun. Thermal is also on the list — M55 + NPU + display under load inside a sealed enclosure needs either headroom or duty-cycling. 8. What the deck actually does (offline) Every mode below runs on-device , using sensors already on the board — no network. This is where the E84's NPU and sensor suite pay off for an off-grid node: Offline voice assistant — the DEEPCRAFT voice model (the same family as the Part 1 factory demo): wake word + commands, fully local. Hands-free control with no cloud. Radar presence & motion (BGT60TR13C) — detects approach and movement in total darkness and through thin materials, with no camera. Ideal as a low-power perimeter/wake trigger: the radar runs always-on and only wakes the M55 + display on an event. Weather & environment (DPS368 + SHT40) — barometric-pressure trend as a storm/weather-change warning (a sharp pressure drop precedes bad weather), plus temperature, humidity, and a pressure-derived altitude estimate — all logged to the card. Compass & orientation (BMM350 + BMI270) — magnetometer heading for a compass, IMU for tilt/motion/impact — a basic navigation aid. Vision (OV7675 + a DEEPCRAFT vision model) — optional object/person detection; higher power, so reserved for on-demand or event-triggered use. Audio alerts (TLV320DAC3100 → small speaker) — tones/voice prompts for storm warnings, presence, and low battery. Field reference + logs (microSD) — browse stored maps/guides on the display and review the captured time-series, all offline. Everything surfaces on the 4.3" LVGL dashboard , is driven by keyboard , persists to microSD , and is powered by solar + battery — with radios off (true air-gap) except for the optional Bluetooth keyboard. 9. Enclosure A 3D-printed rugged case housing the board, the display (front window), the battery, the charger, and the button cluster, with the solar panel on the lid or on a short lead. Ports/cutouts for the panel input, the USB-C (J1, for charging/programming when available), and microSD access. The design has to balance ruggedness against the thermal need for some airflow under AI load. 10. Build phases Display bring-up — LVGL on the 4.3" MIPI-DSI panel; confirm panel compatibility; build the dashboard layout. Storage — integrate a FatFs-over-SPI SD driver; wire the OPEN-SMART breakout; write/read a log file. Input — Rii 518BT BT HID-host. Power — fit the J3 connector; run from the protected LiPo and measure real current + runtime ; add the solar charger and load-sharing; validate charge-while-run. AI integration — wire the offline voice + radar-presence + environmental logging into the dashboard, event-driven to protect the power budget; add vision on-demand. Enclosure + field test — print the case, assemble, and run it untethered on solar. 11. Open questions to close on the bench The concept is settled; these are the real unknowns the build has to resolve, in rough order of risk: Bluetooth HID host for the Rii 518BT — supported on the CYW55513 stack' DSI panel compatibility — does the 4.3" panel come up on the PSOC Edge graphics stack, or does it need a custom panel driver? SD-over-SPI — integrating a FatFs SPI driver cleanly (the examples target onboard flash, not SD). Power path — J3 rework connector, load-sharing while solar-charging, and panel sizing vs. duty cycle. Thermal — M55 + NPU + display under load inside the enclosure. PSOC Edge E84 AI Kit RoadTest — PSOC, XENSIV, AIROC, DEEPCRAFT, ModusToolbox are trademarks of Infineon Technologies.Rugged Raspberry Pi cyberdecks, custom STM32N6 + external NPU boards, or Meshtastic + sensor nodes. This kit stands out for tight integration of 60 GHz radar + dual PDM mics + environmental sensors + dual NPU (Ethos-U55 + NNLite) on one low-power MCU with native DSI and rich expansion. Fewer failure points than multi-board stacks.Development Boards & ToolsSetup was exceptionally smooth. Board recognised immediately as KitProg3 USB-UART on Windows 11. Only prerequisite was a free myInfineon account. First build/flash of Hello World worked end-to-end. The unpopulated J3 power header is noted as a feature for deliberate, field-repairable power architecture.https://community.element14.com/products/roadtest/f/forum/57040/is-there-a-place-we-can-request-roadtest-products/236180Sun, 21 Jun 2026 01:55:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:830b9ac3-d571-4406-8d8f-2f2800b11f91MATRIX7878Alright, I think I found something: SM-K26-XCL2GC AMD, SYSTEM-ON-MODULE, ARM, CORTEX-A53 | Newark Electronics .https://community.element14.com/products/roadtest/f/forum/57040/is-there-a-place-we-can-request-roadtest-products/236179Sun, 21 Jun 2026 00:31:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:f1a44130-7342-4955-a76b-7a7058e2d50bMATRIX7878Unfortunately, I do not think so. I would have that that since Avnet/Farnell are European countries Trenz would be a manufacturer as it is German. Oh well. Perhaps there are other things.