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/151282Sun, 03 May 2026 08:35:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3e0d7b7c-ae77-456d-8c25-de740a722280dougwArduino Nano R4 road test demo For the full blog see:doug wongwire1arduino nano r4https://community.element14.com/products/roadtest/rv/roadtest_reviews/1907/arduino_nano_r4_road_testSun, 03 May 2026 08:34:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:606d0c29-ce69-476f-aece-a4832f7e7dfedougwIntro This is a road test of an Arduino Nano R4. I am very interested in exploring the capabilities of this product with the goal of assigning it to be a standardized platform for future projects. Once the footprint is in my CAD library and I have worked out firmware to handle all the I/O, it then becomes easy to use the module in new projects without going through all that initial development activity. The Nano R4 represents a significant increase in power and capability in the attractive Nano form factor. A couple of features make it much more attractive to me than the original Nano: The R4 has an extra I2C port on additional pins, which allows I2C devices to be used without using up analog channels. The A/D converter can capture 14 bits of resolution. The MCU is a 32 bit ARM Cortex M4 running at 48 MHz which provides much more real-time signal processing capability. There are several other great features that may come in handy as well, such as 6 PWM channels, a DAC channel, an RGB LED, CANBUS pins, 256 KB flash, 32KB RAM, floating point unit, an OpAmp, HID emulation, USB C, reset button, a Qwiic connector, an RTC and backup battery input. Test Plan The Arduino IDE includes many generic code examples and a whole suite of examples specific to Renesas RA4M1 MCUs. This road test isn't going to review these examples since they have already been done, instead I want to show how to exploit the features I find most interesting about this module. Specifically I want to use a custom PCB that includes the Nano R4, 10 switches, connectors for 8 analog inputs (potentiometers) and an LCD interface. I will design and build 3D printed housings for a control panel and the MCU with the liquid crystal display. I will figure out how to use a second I2C port to drive the LCD, how to make the A/D capture analog signals with 12 or 14 bit resolution and display all input data on the LCD. The Build It took quite a while for me to get through this project, mostly due to health setbacks, but working on this project helped to take my mind off other problems. The PCB The Case The 3D printed case features a GoPro mount and 8 button extenders. (shown in blue) The Control Panel The control panel has room for 4 rotary potentiometers and 4 slide pots. It uses popsicle sticks to retain the slide pots. The Assembly The assembly went smoothly although I had to dig deep into my stash to find enough bulkhead rotary pots. The one with the different knob had a different shaft size. Connections between the control panel and the display case are made using a breadboard as a patch panel. Amazingly the slide pot pins work directly with Dupont jumpers. The Demo The Firmware The firmware demonstrates how to force the Nano R4 to use higher resolution on the A/D (12 bits or 14 bits) It also indicates which LCD library I used to respond to a second I2C port. Discussion What I liked I really like the form factor. This module packs a lot of capability into a small package. I really like the A/D converter - 8 channels with 14 bit resolution is great. I really like the second I2C port that doesn't hijack analog pins. I like the fast and powerful MCU - rare in a 5 volt part. I like the memory resources. I also liked all the other hardware features - they make this module suitable for a wide variety of applications. What I didn't like so much The only quibble I have is that the code examples were mostly developed for other platforms such as UNO R4 or NIcla or Portenta, which have different resource mixes, however the examples are still very useful. Conclusions There is a lot to like about the Arduino Nano R4. I especially like its analog capabilities. It fills a gap by providing 8 high resolution analog channels in a small form factor, while still having enough resources to drive an I2C LCD. In addition, it includes a high speed 5V MCU with a very useful amount of memory. I wanted to put together a demo that highlighted the analog capabilities in conjunction with an LCD and the platform didn't disappoint. I did have to scrounge around for an LCD library that could handle a second I2C port, but once I found one, everything went well. I am very happy that I was chosen to road test this module. It has a great feature set for the type of project I often do and I fully expect to use it in upcoming projects. In fact I have one in the works right now. Thank you element14 and Arduino for the opportunity to explore the Nano R4. stl files Links: NanoR4 road test page NanoR4 resource pageRoadTestdougwarduino nano r4Arduino Nano, Arduino UNO R4 MinimaConnectors & CableThere were no problems with the Nano R4. I had health issues that slowed down my work on the road test.https://community.element14.com/products/roadtest/m/managed-videos/151230Sat, 25 Apr 2026 16:39:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a7c75c38-d75d-4f98-8124-d4ecfc4799bfralphjyhttps://community.element14.com/products/roadtest/b/blog/posts/arduino-uno-q---usb-audioSat, 25 Apr 2026 16:37:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:01aa4afd-5d50-46cc-b029-6344ff9032fcralphjyNow that I've got two different ways to attach USB peripherals (hub and OTG adapter) to the Uno Q, I decided to try out a couple of audio apps with a USB speaker. First I used the Sound Generator Brick to create some music. This has the feel of sound generation that I used to do with the original Uno using frequency and duration to produce music. Of course, this is much more sophisticated and can use different waveforms plus produce sounds algorithmically (synthesis). And I get to use a USB speaker ☺ . Sound Generator Fur Elise example The Brick overview has the tone data for Beethoven's Fur Elise, so I'll just play that. fur_elise = [ ("E5", 1/4), ("D#5", 1/4), ("E5", 1/4), ("D#5", 1/4), ("E5", 1/4), ("B4", 1/4), ("D5", 1/4), ("C5", 1/4), ("A4", 1/2), ("C4", 1/4), ("E4", 1/4), ("A4", 1/4), ("B4", 1/2), ("E4", 1/4), ("G#4", 1/4), ("B4", 1/4), ("C5", 1/2), ("E4", 1/4), ("E5", 1/4), ("D#5", 1/4), ("E5", 1/4), ("D#5", 1/4), ("E5", 1/4), ("B4", 1/4), ("D5", 1/4), ("C5", 1/4), ("A4", 1/2), ("C4", 1/4), ("E4", 1/4), ("A4", 1/4), ("B4", 1/2), ("E4", 1/4), ("C5", 1/4), ("B4", 1/4), ("A4", 1.0), ] I decided that it would be nice to add something to display on the LED matrix while the music was playing. The Uno Q has 13x8 matrix rather than the the 12x8 matrix used on the Uno R4, so I needed to use the Arduino Uno Q LED Matrix Animator . I created the image of a note and exported it to a json file. I am using only a single image rather than an animation. I needed to create a left justified array of 4 uint32_t integers to represent the 104 matrix bits (13x8) for the sketch. The last integer is padded with zeroes in the 3 least significant bytes. The python program controls the sound generation and playback over the USB speaker and the handshake for the LED matrix main.py from arduino.app_bricks.sound_generator import SoundGenerator, SoundEffect from arduino.app_utils import * import time # Use 'master_volume' instead of 'volume' player = SoundGenerator(master_volume=0.01, sound_effects=[SoundEffect.adsr()]) fur_elise = [ ("E5", 1/4), ("D#5", 1/4), ("E5", 1/4), ("D#5", 1/4), ("E5", 1/4), ("B4", 1/4), ("D5", 1/4), ("C5", 1/4), ("A4", 1/2), ("C4", 1/4), ("E4", 1/4), ("A4", 1/4), ("B4", 1/2), ("E4", 1/4), ("G#4", 1/4), ("B4", 1/4), ("C5", 1/2), ("E4", 1/4), ("E5", 1/4), ("D#5", 1/4), ("E5", 1/4), ("D#5", 1/4), ("E5", 1/4), ("B4", 1/4), ("D5", 1/4), ("C5", 1/4), ("A4", 1/2), ("C4", 1/4), ("E4", 1/4), ("A4", 1/4), ("B4", 1/2), ("E4", 1/4), ("C5", 1/4), ("B4", 1/4), ("A4", 1.0), ] # Start an infinite loop while True: for i, (note, duration) in enumerate(fur_elise): # Toggle between frame 0 and frame 1 frame_to_show = i % 2 # This calls the C++ setFrame function Bridge.call("setFrame", frame_to_show) player.play(note, duration) time.sleep(1) App.run() The sketch just controls the matrix. sketch.ino #include "Arduino_LED_Matrix.h" #include "Arduino_RouterBridge.h" Arduino_LED_Matrix matrix; // Define a "Musical Note" frame (13x8) const uint32_t frameA[] = { 0xfe04102, 0x8104082, 0x470e387, 0x0 }; // Define a "Bar" frame const uint32_t frameB[] = { 0x0, 0x0, 0x0, 0x0 }; void setFrame(int frameId) { if (frameId == 0) { matrix.loadFrame(frameA); } else { matrix.loadFrame(frameB); } } void setup() { matrix.begin(); Bridge.begin(); // Register the function so Python can call it Bridge.provide("setFrame", setFrame); } void loop() { // Bridge processes requests here } I did a quick check to see what USB devices were seen: It sees the hub, hub Ethernet and SD card interfaces, and the USB speaker as Device 005 and the USB drive as Device 006. I will be using the drive in the next mp3 player app. And that the audio player could ID the speaker: And a quick video: community.element14.com/.../5432.Fur-Elise-LED-Matrix.mp4 mp3 player Next I thought it would be useful to create an mp3-player app that would play music stored on the USB drive. This turned out be be a lot more challenging than I expected. This seems like it would be a simple task with a Linux OS, but the difficulty arises with implementing it in the AppLab environment. Apps in AppLab are created in a sandboxed environment that is implemented using Docker containers. I didn't initially grasp the all the ramifications of this and I did what I usually do and created a global mount point for the USB drive. Linux could see the drive which is an HP 150 32GB drive that I use to store a single MP3 file borrowed from a previous project. It was found as Bus 001 Device 006 in the previous USB scan. It is drive /dev/sda with partition /dev/sda1. So, I mounted the partition on directory /mnt/usb and set access permissions for the user (arduino). And it is initially empty except for a directory that HP puts on there by default. I used WinSCP to transfer the Christmas mp3 file from my host PC. So, I thought all was good and proceeded to install a lightweight MP3 player, mpg123. Good news and bad news about a sandboxed environment It's been a while since I've worked in a sandboxed environment, so I thought that I had done what was required to run my app. I referenced the file I wanted to play as being located in the "/mnt/usb/" directory and called the system subprocess "mpg123" to play it. Quick test import subprocess import os # Point to your mounted USB path MUSIC_PATH = "/mnt/usb" def play_song(filename): full_path = os.path.join(MUSIC_PATH, filename) # '-a hw:1,0' specifies the USB speaker (Card 1, Device 0) # '--quiet' keeps the logs clean process = subprocess.Popen(["mpg123", "-a", "hw:1,0", "--quiet", full_path]) return process # Simple test: Play the first mp3 found files = [f for f in os.listdir(MUSIC_PATH) if f.endswith('.mp3')] if files: print(f"Now playing: {files[0]}") player = play_song(files[0]) else: print("No MP3 files found on the drive.") The program did not run in the AppLab environment because it could not find /mnt/usb or mpg123. This is a feature of a sandboxed environment that I hadn't considered. The sandbox is created to isolate the app from the host Linux environment so that a misbehaving app cannot crash the system. One of the ways that it does this by restricting file and process access to within the sandbox, so it could not access either of these elements that I had created in the system environment. What is somewhat confusing is that the system can see and access the app file structure. You can see the files in the mp3-player app in the WinSCP window. There are probably many ways to solve the file problem. One way is to create a directory in the app file structure (music in this case) and just copy files from the /mnt/usb. Or you can mount the USB drive directly to the music directory. I've tried both and they both work (python code stays the same) One thing that does not work in the sandbox is a symlink to /mnt/usb. Depending on your development requirements you might try other solutions. To solve the process/program problem I needed to install mpg123 in the sandbox python environment since it isn't installed by default. The only way to currently install python programs in AppLab is to use requirements.txt This requires that a package wheel is available for the program that you want to install. It turns out that there is not a wheel currently available for python 3.13.5 which is installed in AppLab. And there is currently not the capability to build a binary from source (lots of tools missing). So, I ended up searching for a different MP3 player and decided on pygame which is a bit more capable and resource heavy than mpg123. With these changes the app worked. Volume control Since I have a Modulino Knob, I decided to add volume control and display the volume level on the LED matrix. I initially intended to display the level as a "VU" meter style bar graph, but the 13 "pixel" horizontal resolution of the matrix is too coarse so I ended up just displaying the volume level as 0-100% in text. This post has been way too long, so I'll just include the code and the demo video. sketch.ino #include #include #include ModulinoKnob knob; ArduinoLEDMatrix matrix; int lastVolume = -1; void setup() { Bridge.begin(); Monitor.begin(); Modulino.begin(Wire1); knob.begin(); matrix.begin(); knob.set(50); } void loop() { int vol = knob.get(); if (vol > 100) { vol = 100; knob.set(100); } else if (vol < 0) { vol = 0; knob.set(0); } if (vol != lastVolume) { Monitor.print("VOL:"); Monitor.println(vol); Bridge.notify("volume", vol); matrix.beginDraw(); matrix.clear(); // This is the fix for the "ghost digits" matrix.stroke(0xFFFFFFFF); matrix.textFont(Font_4x6); //matrix.beginText(0, 1, 0xFFFFFFFF); //matrix.print("V"); // Small adjustment for positioning // If it's a single digit, move it right so it's centered if (vol < 10) { matrix.beginText(9, 1, 0xFFFFFFFF); } else if (vol < 100) { matrix.beginText(5, 1, 0xFFFFFFFF); } else { matrix.beginText(1, 1, 0xFFFFFFFF); } matrix.print(vol); matrix.endText(); matrix.endDraw(); lastVolume = vol; } delay(50); } main.py import os import time import pygame from arduino.app_utils import App, Bridge pygame.mixer.init() current_dir = os.path.dirname(os.path.abspath(__file__)) MUSIC_PATH = os.path.join(current_dir, "music") # 1. This function only handles the volume updates def update_volume(vol_data): try: new_vol = float(vol_data) / 100.0 pygame.mixer.music.set_volume(new_vol) print(f"Volume updated to: {vol_data}") except Exception as e: print(f"Volume error: {e}") # 2. This function starts the song and returns immediately def start_playback(): songs = [f for f in os.listdir(MUSIC_PATH) if f.endswith('.mp3')] if not songs: print("No music found!") return pygame.mixer.music.load(os.path.join(MUSIC_PATH, songs[0])) pygame.mixer.music.play(-1) # -1 means loop forever print(f"Playing: {songs[0]}") # Register the volume callback # Every time the MCU calls Bridge.notify("volume", val), this runs print("Registering 'volume' callback.") Bridge.provide("volume", update_volume) # Start the music start_playback() print("Starting App Service...") # App.run() keeps the script alive and listens for Bridge events App.run() community.element14.com/.../3302.MP3-Player.mp4RoadTestarduino uno qUSB speakersound generator brickUSB audio fileshttps://community.element14.com/products/roadtest/m/managed-videos/151224Sat, 25 Apr 2026 13:59:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:1a65b6eb-6b8f-4278-971a-80c0d055e0d5meera_hussienThis video is about unboxing of the Nordic Thingy:91 X #iot #nordic #thingy #maker #unboxingmakernordiciotunboxinghttps://community.element14.com/products/roadtest/rv/roadtest_reviews/1906/arduinos_uno_q_-_the_new_single-board_computerFri, 24 Apr 2026 09:37:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e9b6fa15-a770-4da0-b83e-7734e68f2a40amgalbuOverview The Arduino Uno Q is best described as a hybrid development board: a single-board computer running Linux paired with a dedicated microcontroller for compiled C++ execution. Rather than positioning itself as a raw performance competitor in the SBC market, it can be more seen as a versatile development platform, which integrates the determinism of embedded programming with the flexibility of a general-purpose Linux environment. Let's go quickly through the hardware specifications, because, as I said, this is not the thing this board shines for Hardware Specifications Main processor (Dragon SoC) A Qualcomm Dragonwing QRB2210, which features four ARM Cortex-A53 cores and an Adreno GPU, handles the Linux environment. The board ships in two configurations — 2 GB RAM / 16 GB storage and 4 GB RAM / 32 GB storage — giving it enough computational power for light desktop use, data processing, local web servers, and running small inference models. Microcontroller The onboard MCU is a STM32U585, which sports a Arm Cortex M33 with a clock up to 160 MHz. This MCU runs C++ executables on Zephyr OS, which is really forward-looking approach to real-time subsystems. The application, thanks to this lightweight and deterministic OS, can leverage real-time access to hardware peripherals. Power consumption Idle power sits around 2–2.5 W, rising to approximately 4–5 W under full load. This is notably lower than competing SBCs, making battery-powered deployments — like portable sensor nodes — feasible without complex power management. Connectivity A single USB-C port handles power and data. For desktop use, a PD-capable USB hub is necessary to connect a keyboard, mouse, HDMI display, and any USB peripherals simultaneously. Despite the Arduino docs suggests to use the board as a "PC replacement" (i.e. with display and keyboard), I think you get the most out of this board if you use App Lab and a console. Running a fully-fledged desktop environment pits too mush load on the CPU, and causes slow downs and (sometimes) unexpected reboots. At least, this is what I experienced with my 2 Gb version. Hopefully, the 4 Gb version is more usable and stable Connectors The board features, beside the typical digital and analog signals on the Arduino Uno headers, high-speed expansion connectors on its underside for cameras, displays, and audio modules, plus a quick connector for common peripheral hookups. Form factor The Arduino Uno Q has a Uno-compatible footprint, meaning existing Uno shields should work — an important consideration for anyone with an existing parts collection. To be honest, I don't expect any of the Uno shields to work with Arduino Q. Arduino Uno was a 5V-compatible microcontroller, whereas the Qualcomm CPU runs at 1.8V and the STM32 MCU runs at 3.3V. Happy to be proven wrong, but just this simple consideration makes me very doubtful about the compatibility statement. Anyway, here are the compatible shield according to the Arduino website https://docs.arduino.cc/hardware/uno-q/#compatibility LED Matrix The board also features a programmable LED matrix, which is somehow scenographic but I don't think it's really useful. First of all, if you mount a shield all the LEDs will not be visible. Second, the information you can show on LED matrix are limited. Considering the cost of the components (resistors and LEDs) and the cost of manufacturing, a tiny 2.8" OLED display would have been cheaper to install Performances To be clear and direct, Uno Q is not, as other general-purpose SBC, a desktop replacement. Light web browsing and text-based tasks are usable; YouTube playback is sluggish. Any comparison with Rapserry Pi 5 purely in terms of raw Linux performances will see the Raspberry as the absolute winner. Regarding performances, I found this interesting comparison In summary: Idle power draw 0.5 W Maximum simulated power draw (stress-ng --matrix 0) 1.9 W During Geekbench multicore benchmark 2.5 W During top500 HPL benchmark 3.5 W In terms of number crunching capabilities, the Arduino Uno Q is comparable to a Raspberry Pi 4 (an SBC relased in 2019) In terms of efficiency, results are much better As we can see, Arduino Uno Q is not the best in class in terms of performance or even efficiency, but this point of view misses the product's intent. The Uno Q should be considered as a microcontroller-based board that happens to run Linux, not a Linux computer with GPIOs. The absence of a heatsink, the default boot into AppLab rather than a desktop, and the Uno form factor provides an idea of the product the development team had in mind. However, if the focus was on creating a maker-friendly hybrid system, in my opinion the board is missing the ability to keep only the MCU running and wake up the Linux processor only when something "interesting" is detected. This feature could have opened a whole branch of battery-based intellingent sensors. The Microcontroller Advantage Having a microcontroller introduces a significant differentiator: determinism. When you control GPIO through a Python script running on Linux, you are only suggesting the desired timing to the OS scheduler. Other processes (like network handling, display rendering, or memory management) can prevent OS scheduler from meeting the deired timing because they all may introduce unpredictable latency. The onboard MCU executes each instruction with predictable, repeatable timing. This matters significantly for a wide range of sensors and peripherals that can be easily integrated into the Arduino sketch Motor control and encoders: precise PWM generation and encoder interrupt counting require consistent response times measured in microseconds, not milliseconds High-speed sensor polling : protocols like SPI or bit-banged UART can break down if there's jitter in the read loop Audio signal generation : the 12-bit DAC can produce a true analog voltage between 0 and 3.3 V without PWM artifacts, which is a meaningful advantage for any audio or signal-processing application ADC access : many Linux SBCs lack a native ADC entirely, but Arduino Uno Q has an ADC on the MCU. This eliminates the need for an external I²C/SPI ADC module AppLab IDE Let's now see how one can develop its own projects on Arduino Q. The central piece of software is AppLab, which greatly simplify the integration of software running on Linux, real-time Arduino application running on MCU and the web interface that allow users to interact with the application itself. AppLab runs either directly on the Uno Q's Linux environment or, more comfortably, on a host computer connecting to the board via USB or local network. Here are the connections required for the two different, called, in the Arduino documentation, "Standalone mode" and "PC Hosted mode" A typical project in AppLab contains: A `.ino` / `.cpp` sketch file for the microcontroller A Python script for the Linux side Optional HTML, CSS, and JavaScript files for a local web UI (a common pattern for Uno Q projects) A `YAML` manifest that AppLab manages automatically as you add bricks Python scripts and the optional web UI runs in docker container. When you run a project, you will see in the terminal familiar log messages of docker downloading images from docker repositories. The containerisation means dependencies are isolated and the brick simply exposes an interface to your code. Importantly, the user does not need to manage Docker directly; AppLab handles deployment automatically. One thing that makes me wonder whether the development team has selected the right approach for application deployment: Docker images are downloaded to the so-called "root" partition, which stores all the critical Linux system files. I would have preferred the user data and application to be downloaded in a separate partition. This solution has some benefits the root partition can be mounted as read-only, thus improving board reliability in case power is disconnected the root partition will never run out of space because of a huge docker images Regarding eMMC partitioning, I worth noticing that that are an incredible number of partitions, but only three are really mounted It's not clear to me what all those partitions are for, but the finally effect is that you only have 13 Gb available out of 16 Gb Bricks Bricks are the most distinctive AppLab concept. They are pre-packaged functional modules — not just libraries — that run as separate processes (often in Docker containers) alongside your application. Examples include weather API fetchers, voice keyword detection, sentiment analysis, and YOLO object detection. This architecture means a single project file can orchestrate Python business logic, a C++ hardware loop, and a Docker-hosted ML model The bridge system The bridge system is what ties the two processors together. A library (called ArduinoBridge) is available as both Python and Arduino library. By invoking the methods of the Bridge class, the application that runs on Linux and the Arduino sketch can exchange data. For example, the `bridge.notify()` call in the microcontroller sketch passes data across to the Python process — cleanly abstracting what would otherwise require a raw UART or USB serial handshake. Hands-on project It's time to get our hands dirty and create a simple project to assess Arduino Q performs in the real world. I will create a project that captures video using a USB webcam, detects the position of a person and moves a servo to keep the person in the center of the camera frame. Running App Lab The App Lab can be run in three different ways: Onboard : There’s a copy that runs directly on the Linux partition of the Arduino Uno Q itself USB Connection : Connect the Arduino Uno Q to a computer via USB-C Network Connection : Connect to the board over a local area network One crucial concept to understand is that app files reside on the Arduino Uno Q itself, not on your local PC. The App Lab doesn’t make a local copy – it edits files directly on the board. You’ll find these files in the Linux partition at /home/arduino/ArduinoApps/. Even when you run App Lab on your computer, it’s connecting to and editing files that live on the Arduino Uno Q. This is an important distinction from traditional Arduino development. AppLab has a good example to start from: the face detection example. This example uses ML models to detect faces in the scene. Let's make a copy of this project and start tinkering with the code. The object detection is implemented by a brick, where several parameters can be adjusted to fit your needs. Among the other things, the object detection supports different models, even custom models created on Edge Impulse The example project I started from does not include any Arduino sketch. When you create a new project, AppLab takes care to generate the complete folder hierarchy, but, in this case, the "sketch" folder was missing. The only workaround I found was to copy the "sketch" folder from another sample project. The sketch have just to get face coordinates left or right to try to keep the face at the center of the scene. To let Linux processor and MCU communicate, AppLab provides a library called ArduinoBridge. The ArduinoBridge implements the following functions Calling Python functions from C++ Calling C++ functions from Python Exchange of data between both processors To implement the MCU side of the bridge, you need to initialize the bridge and declare which functions can be invoked by the processor Note that the move_servo may be executed independently from the loop() function. This may cause undesired race conditions when the function interacts with functions, like digitalWrite() . If you want the move_servo function to be executed in the context of loop() function, user provide_safe instead. On the processor side, import the Bridge class from the Python arduin.app_utils library, and invoke Bridge.call to send a request to the sketch Bridge.call invokes a function and wait for the function to complete. If you want to just invoke a function without waiting for completion, the Bridge.notify method is available. Load of details about the bridge are available at the following links https://docs.arduino.cc/tutorials/uno-q/routerbridge-multilanguage/ https://docs.arduino.cc/tutorials/uno-q/user-manual/#bridge---remote-procedure-call-rpc-library Use Case Assessment After a couple of weeks playing around with the Arduino Uno Q board, I realized which projects this board is fit for Perfect fit Small-scale robotics where a dedicated motor controller (MCU) and an onboard compute node (Linux) are both needed on a single, low-power board Projects requiring local web dashboards to visualise sensor data — the radar visualisation demo in AppLab replaces a setup that previously required a separate PC running Processing IDE Computer vision applications — YOLO deployment via AppLab brick was notably straightforward compared to alternative SBC setups Educational/classroom environments where students need a self-contained, connectable dev board Not so perfect fit Projects that are purely Python or purely C++: the Uno Q can do both, but a dedicated SBC or a standalone microcontroller may offer a tighter solution for single-paradigm work Completely unfit Any application demanding strong desktop Linux performance (media consumption, heavy compilation, desktop software) Projects where relevant tasks can't be offloaded to the MCU Conclusions The Arduino Uno Q provides a clean hardware solution for all the projects that need both real-time hardware control and a capable compute environment in one compact, low-power package. AppLab significantly lowers the integration complexity that you may expect when coping with an hybrid (CPU + MCU) solution. Also, the integration with Edge Impulse is a plus that should be considered when approaching a ML-based project. PROS Integration between Linux and MCU, and with external platforms like Arduino Cloud and Edge Impulse Examples are complete and a good starting point Documentation is quite accurate Power consumption allows you to integrate advanced vision and ML processing in a battery-based device CONS AppLab misses some editor feature you expect from a modern IDE. Also, AppLab seems a bit immature. For example, adding custom libraries can be difficult and some libraries may not install correctly. After installation, the interface doesn’t always refresh properly. Despite the missing features and some annoying bugs, I appreciated the concept: handdling and deploying all the components (web frontend, python application and sketch) of an hybrid system in a single tool is really uncommon in the embedded world, where tools fragmentation is the norm. Containers are deployed in the same partition as the root filesystem. This may cause reliability problems (wouldn't have been better to mount the rootfs partition in read-only mode to preserve critical files from corruption) and store all user-related files into another partition?) No support for advanced shields (JMEDIA and JMISC connectors). For example, there is not support for a CSI camera. You can use a USB camera with a hub, but this removes the benefit of having a small, all-in-one device. For robotics, adding a USB hub and camera makes the board much less useful Debugging limitations: I hoped to find an Integrated Debugger in AppLab, but my expectations have been disappointed: there are no debugging capabilities built-in in AppLab. You’ll need to rely on good old logs and serial output for troubleshootingRaspberry Pi (as far as the Linux OS is concerned), Latte Panda (as hybrid system)Development Boards & ToolsNo problems: it's very easy to get started and start creating your own project. Tutorial and manuals are very clear and guide you throughhttps://community.element14.com/products/roadtest/rv/roadtest_reviews/1904/review_of_the_ams_osram_as1170_high_power_led_and_vertical_cavity_surface_emitting_laser_vcsel_evaluation_kitThu, 23 Apr 2026 18:45:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e08e7baa-14c0-49a2-92bc-71ed8830c311rscReview of the ams OSRAM AS1170 High Power LED and Vertical Cavity Surface Emitting Laser (VCSEL) Evaluation Kit I received the following so far: ams OSRAM AS1170 WL EVM EB Evaluation Kit, including: ams OSRAM AS1170 EVK 2 x ams OSRAM IR LED Break-out board ESP32 S2 DevKit M1 1m USB 2.0A to USB2.0 Micro-B Cable I did not yet receive: 2 x OSRAM OSLON Black SFH 4726 BS A01 LEDs 2 x OSRAM SYNIOS P2720 SFH 4795BS LEDs I downloaded and installed ams AS1170 PC GUI Software V1.1 Here is the kit. The initial attempt at evaluating the kit was a bit frustrating. The AS1170-GUI PC software has a few problems. It works sometimes, sometimes not at all. To diagnose what the problem is, I need to dive deeper into the software interface. The AS1170 IC is a LED driver with two outputs that can source up to 1A on each output. The basic AS1170 IC block diagram is shown below. The AS1170 is controlled using the I2C bus by loading various registers per the following table. The AS1170-GUI PC program talks to the ESP32 through the USB serial interface using read and write commands, and then the ESP32 transfers the register data to/from the OSRAM board via the I2C bus. I soldered up a small interface board to plug into the OSRAM board via the 8-pin header so I could connect some visible LEDs and disconnect the IR on-board LEDs. My intent is to eventually connect the OSRAM AS1170 board to some CNC laser modules. Below is the current CNC laser driver board. The AS1170 user manual isn't totally clear as to how the register settings control the driver output modes. In the AS1170 EVK manual there are a few example configurations. AS1170_EVK_QG001040_2-00.pdf \ https://look.ams-osram.com/m/1ad89354fc528e75/original/AS1170-EVK-QG001040-Guide-2-00.pdf In the AS1170 IC datasheet there is much more information about all the registers and values. AS1170-High-current-LED-VCSEL-driver.pdf https://look.ams-osram.com/m/360a4e139e632474/original/AS1170-High-current-LED-VCSEL-driver.pdf To give myself a jumpstart on how the OSRAM GUI PC app was configuring the board, I used wireshark to monitor the USB bus and log the data transfers. To help figure out the correct software flow, I started writing a Matlab app to interface with the ESP32 directly through the USB serial port and parse the output similar to the AS1170-GUI program. The basic configuration protocol is as follows: Connect to the ESP32 through a USB serial port interface. The ESP32 side Arduino GUI code and the AS1170 GUI PC executable are available online https://github.com/ams-OSRAM/AS1170-GUI Program what mode you want the IC to be in: Standby/Off - Control register 0x06 bit 3 Indicator Mode - Control register 0x06 bits 0 and 1 and Indicator/PWM register 0x09 Assist Mode - Control register 0x06 bits 0 and 1 Flash Mode - Strobe register 0x07 bits 6 and 7 Strobe Mode - Strobe register 0x07 bits 6 and 7 If Indicator Mode: Only bits 0-6 are used on registers 0x01 ad 0x02 to set the LED currents If Assist mode: Bits 0-7 are used on registers 0x01 ad 0x02 to set the LED currents If Flash or Strobe Mode: Set LED on timer value register 0x05 There is also a current boost register 0x81 used with a password register 0x80 for an extra %11 current output drive (I haven't tried this yet - an external power supply must be used for this because normal USB ports can't source high currents) There are several fault protection circuits inside the AS1170 and the fault codes can be read from register 0x08 Under_voltage Over_Voltage LED_Short Flash_Timeout Over_Temp Here's my Matlab code so far: Now that I understand better how the AS1170 registers are configured, my next project is to use the OSRAM board and the ESP32 to trigger a PIV camera and control a scanning laser module in the lab. I'll write up another blog for that project. If the other OSRAM IR LEDS arrive, I will evaluate them with the EVK.Most high power laser modules have a driver board, however, they don't allow user configuration and control to this level.Evaluation BoardsA lack of basic code flowchart and an AS1170 state diagram made it difficult to follow the software functions at first. The AS1170 GUI PC app is ok as a start, but can be frustrating when it doesn't work properly.not included 2 x OSRAM OSLONTm Black SFH 4726 BS A01 LEDs not included 2 x OSRAM SYNIOSTm P2720 SFH 4795BS LEDshttps://community.element14.com/products/roadtest/m/managed-videos/151218Wed, 22 Apr 2026 05:17:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:cff8d716-1a43-40e7-9f44-938766519f5fralphjyhttps://community.element14.com/products/roadtest/rv/roadtest_reviews/1905/arduino_nano_r4_reviewSat, 18 Apr 2026 05:33:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:536d742d-4bc9-44ea-b40d-77d8e25cd6ecneerajrd82Section: Unboxing, Initial Setup & Failure Analysis – Arduino Nano R4 1. Unboxing & First Impressions The Arduino Nano R4 was received in standard Arduino packaging with the board securely enclosed in an anti-static cover. Package Contents: Arduino Nano R4 board Berg strip headers (unsoldered) Initial Observations: Compact Nano form factor retained High-quality PCB finish Clearly labeled pinout USB Type-C interface for modern connectivity The inclusion of unsoldered headers allows flexibility depending on application (breadboard vs embedded use). 2. Header Soldering Procedure To prepare the board for testing, the supplied Berg strip headers were manually soldered. Tools Used: Temperature-controlled soldering iron Lead-free solder wire Flux (for clean joints) Procedure Followed: Headers were aligned with PCB through-holes Board was placed on a flat surface to maintain perpendicular alignment Each pin was soldered carefully to ensure: Proper wetting No cold joints No bridging between adjacent pins Result: Clean and mechanically stable solder joints Board ready for breadboard and test setup integration 3. Initial Power-Up & Arduino IDE Detection After soldering, the board was connected to the system using a USB Type-C cable . Expected Behavior: Automatic USB detection COM port visibility in Arduino IDE Board ready for programming Observed Symptoms: No COM port visible in Arduino IDE Device shown as “Unknown USB Device” in Windows Device Manager Upload attempts failed completely No LED indication of bootloader activity At this stage, the board appeared non-functional and inaccessible 4. Initial Diagnosis Using Community Reference To investigate the issue, the following troubleshooting resource was referred: Element14 Community guide on USB detection issues on this link: https://community.element14.com/products/arduino/b/blog/posts/arduino-uno-r4-minima-troubleshooting-unknown-usb-device Key Insight: USB failure is commonly caused by: Improper firmware initialization Clock misconfiguration Bootloader not executing Engineering Interpretation: Since USB depends on correct timing: Any misconfiguration in system clock or startup code can completely disable USB communication. 5. Attempt to Restore Bootloader Mode Method Used: Double-press reset button to force bootloader entry Expected Outcome: Board should enumerate as a valid USB device COM port should reappear Actual Result: Bootloader entry was inconsistent USB remained unstable or undetected 6. Bootloader Recovery Attempt Using Official Procedure Next, the official Arduino recovery guide was followed: Arduino Nano R4 Bootloader Flashing Procedure on given link: https://docs.arduino.cc/tutorials/nano-r4/bootloader-flashing/ Intended Goal: Reprogram bootloader Restore USB functionality Re-enable Arduino IDE connectivity 7. Practical Challenges Encountered No Active Communication Interface USB stack was non-functional No serial interface available Result: Bootloader flashing could not proceed Limited Hardware Access No exposed SPI/ISP interface (unlike classic Arduino) SWD/JTAG not readily accessible This prevented low-level recovery Documentation Limitations The official guide assumes: Functional USB connection Arduino IDE workflow It does not fully address: Bare-metal firmware corruption Complete USB failure scenarios 8. Root Cause Analysis Based on experimentation, the failure was attributed to: Clock Misconfiguration Incorrect system clock setup disrupted USB timing Bootloader Interference Custom firmware may have overridden bootloader execution USB Stack Failure USB requires precise timing → deviation leads to “Unknown Device” 9. Key Engineering Insight The Arduino Nano R4 behaves like a professional MCU platform, but without equivalent recovery infrastructure. Parameter Observation USB dependency High Recovery ease Limited Bare-metal tolerance Sensitive Debug accessibility Restricted 10. Lessons Learned For those Engineers who use Arduino IDE without any other options: Avoid modifying critical startup configuration without validation Preserve bootloader region Maintain backup firmware 11. Switching over to SWD debug access to recover the target chip R7FA4M1AB3CFM mounted on Arduino Nano R4 board: Now, i would like to refer to official schematics of Arduino Nano R4 given on this link: https://docs.arduino.cc/resources/schematics/ABX00142-schematics.pdf Here are 3 important observations about above picture are given below required for SWD bebug access: 1. MD pin of MCU given on JP1 connector pin no 13. -> This pin should be connected with SWCLK pin of debugger. 2. RESET pin of MCU given on JP2 connector pin no 3. -> This pin should be connected with RESET pin of debugger. 3. VUSB pin of MCU given on JP1 connector pin no 12 -> This pin should be given +5VDC from debugger USB power supply. Here are some important observations about above picture are given below required for SWD bebug access: 1. P108_SWDIO & P300_SWCLK are required to connected with any compatible debugger -> Jlink / CMSIS-DAP / Renesas made Emulator 2. Very-very important point : P300_SWCLK & MD pin of MCU given on JP1 connector pin no 13 should be shorted with each other & connected to SWCLK line from debugger side. Again by chance, i already possess this evaluation kit made by renesas: This board already have onboard Jlink OB lite debugger mounted on this kit. So, i decided to connect this debugger to Arduino Nano r4 while totally disconnecting on board target chip. Now, referring to schematics of this kit which are found in ek-ra2l1-v1-designpackage.zip , these are important points everybody needs to consider for connections given below: Please! download ek-ra2l1-v1-designpackage.zip from Renesas website. Now, given below is important section of debugger to get connected with external target chip Important Note: all jumpers shown in this diagram needs to taken out totally, to cut off the onboard target chip for debugger connections. J13 connector shown above is not populated in actual kit, so all the connector pads are exposed which were directly soldered for debugger connection with Arduino Nano r4 board. In above picture, 5V power supply can be easily seen which was connected with Arduino Nano R4 board to get power up using debugger USB power supply. J-link Commander after getting correct connection from debugger will give below message corresponding to Arduino Nano R4 board: Device "R7FA4M1AB" selected. Connecting to target via SWD InitTarget() start Identifying target device... SWD selected. Executing JTAG -> SWD switching sequence... Initializing DAP... DAP initialized successfully. Low power mode detected. Waking device from low power mode. InitTarget() end - Took 14.5ms Found SW-DP with ID 0x5BA02477 DPIDR: 0x5BA02477 CoreSight SoC-400 or earlier Scanning AP map to find all available APs AP[2]: Stopped AP scan as end of AP map has been reached AP[0]: AHB-AP (IDR: 0x24770011, ADDR: 0x00000000) AP[1]: APB-AP (IDR: 0x44770002, ADDR: 0x01000000) Iterating through AP map to find AHB-AP to use AP[0]: Core found AP[0]: AHB-AP ROM base: 0xE00FF000 CPUID register: 0x410FC241. Implementer code: 0x41 (ARM) Found Cortex-M4 r0p1, Little endian. FPUnit: 6 code (BP) slots and 2 literal slots CoreSight components: ROMTbl[0] @ E00FF000 [0][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7 [0][1]: E0001000 CID B105E00D PID 003BB002 DWT [0][2]: E0002000 CID B105E00D PID 002BB003 FPB [0][3]: E0000000 CID B105E00D PID 003BB001 ITM [0][4]: E0040000 CID B105900D PID 000BB9A1 TPIU [0][5]: E0041000 CID B105900D PID 000BB925 ETM [0][6]: E0042000 CID B105900D PID 002BB908 CSTF [0][7]: E0043000 CID B105900D PID 001BB961 TMC [0][8]: E0044000 CID B105F00D PID 001BB101 TSG Memory zones: Zone: "Default" Description: Default access mode Cortex-M4 identified. So, SEGGER J-FLASH LITE was able to program Arduino Nano r4 board successfully, below picture demonstrates that: So, SEGGER J-FLASH LITE was able to erase Arduino Nano r4 board successfully, below picture demonstrates that: I m showing the picture of actual physical connections with debugger & Arduino Nano R4 board given below: Important observation noted: I was able to recover original preloaded program which was actually loaded in Arduino Nano R4 at time of arrival using jlink debugger. 12. Switching over the development of target chip R7FA4M1AB3CFM mounted on Arduino Nano R4 board from Arduino IDE into Keil MDK ARM : Here you have to use Renesas smart configurator with Output configured for Keil MDK ARM. Select the clock settings given below in Renesas smart configurator in given screenshot: Select Board : Custom User board (Any Device) as shown in screenshot given below: Pin function select is shown in given screenshot : BSP options are shown in below screenshot: In bsp options, just select bare metal & No RTOS to include. Also select "Generate Project option" option to generate Blinky program in this configurator as shown below: Below given picture demonstrates the output given by Renesas smart configurator for Keil MDK ARM: To run this program correctly, Please! do the following steps: Search & comment this line given below: FSP_HARDWARE_REGISTER_WAIT(R_RTC->RCR2_b.RESET, 0); -> This line is found in bsp_clocks.c Important observation: Debugger gets stuck on above line. Update on 31/03/2026: Keil screenshot on C/C++ tab: Keil screenshot on Asm tab: Keil screenshot on Linker tab: Configure the below settings in Flash download of keil as shown screenshot given below: Apply the above settings, then follow the below given steps: Generate the hex file. Completely erase the chip. Then program the chip using download button in keil. Expected result: You should be able to RGB LED as single white LED glowing brightly but without blinking. Now, after resolving settings issues, renesas flash programmer is also working, screenshots are given below: Programming messages by Renesas Flash Programmer are given below: Loading File (E:\Arduino-nano-r4\led.hex) CRC-32=8D56F9F1 Target device : RA Connecting the tool J-Link Firmware: J-Link OB-S124 compiled Dec 10 2025 15:52:46 Tool : J-Link (SEGGER J-Link-OB-S124), Interface : SWD Connecting to the target device Connecting to the target device Communication speed : 6.0 MHz Signature: Device: RA Device Code: 00160447 Erasing the selected blocks [Code Flash 1] 0x00000000 - 0x0003FFFF size : 256 K [Data Flash 1] 0x40100000 - 0x40101FFF size : 8 K Erasing the selected blocks [Code Flash 1] 0x00000000 - 0x0003FFFF size : 256 K [Data Flash 1] 0x40100000 - 0x40101FFF size : 8 K Writing data to the target device [Code Flash 1] 0x00000000 - 0x0003FFFF size : 256 K [Data Flash 1] 0x40100000 - 0x40101FFF size : 8 K [Config Area 1] 0x01010008 - 0x01010033 size : 44 Verifying data [Code Flash 1] 0x00000000 - 0x0003FFFF size : 256 K [Data Flash 1] 0x40100000 - 0x40101FFF size : 8 K [Config Area 1] 0x01010008 - 0x01010033 size : 44 Setting the target device Disconnecting the tool Operation completed. Important observation: This tool should be used to production programming rather than for development. 13. Build the whole project in keil bypassing Renesas smart configurator If you do not want to use code generated by Renesas smart configurator -> then it is still long learning curve, but some how i managed to reduce the number of files to taken from smart configurator & managed to write in register direct format. Also i have followed the steps given just above this section. End result of above exercise is shown below screenshot: Of course, result was fabulous: I was able to blink RGB LED & AMBER LED independently bypassing the HAL library as mandated by Renesas. Final Verdict: When the Arduino Nano R4 loses USB functionality due to low-level firmware issues, recovery becomes complex and not be achievable using standard Arduino tools alone. It requires the assistance of JLINK/ CMSIS DAP / Renesas EMULATOR to recover from all types of firmware issues. Also this board requires the erase of whole chip to prevent the hang-up. The Arduino Nano R4 delivers powerful Renesas-based performance, but its recovery mechanisms need significant improvement to support advanced embedded development workflows. Renesas flash programmer is not reliable at all, it does not connect with Jlink reliably to sense the chip. There is steep learning curve for bare metal development on register direct access bypassing HAL layer by Renesas. Renesas needs to improve on all these parameters. MY SINCERE THANKS FOR ELEMENT 14 Community to give me to chance to test the arduino nano R4 board.STM32F373CCT6,MK40DX256VLK10,ATSAM4LC8C,EFM32GG11B420F2048GL64Evaluation BoardsComplete USB failure – Board not detected (no COM port), blocking normal development via Arduino IDE Ineffective standard recovery methods – Bootloader reset and typical Arduino fixes did not work Complex root cause – Clock misconfiguration impacting USB initialization required deep MCU-level analysis Limited low-level documentation – Insufficient clarity on register-level configuration and clock dependencies for debugging such failures Shift to hardware-level debugging – Required use of SWD + J-Link, full chip erase, and reflash to recover the system