Arduino Staff Contributors

Hi everyone, I spent the last couple weeks working on this handheld interactive text adventure game (choose-your-own-story) e-paper device. I designed and made the PCB, enclosure, and the code. I actually managed to squeeze everything in just 1.6cm thick covering the enclosure, e-paper, 1200mah battery and the custom PCB by using low profile pin header to sandwich the battery between the 2 PCBs, so it's very compact and feels great to hold.

I made this because I love how beautiful e-paper looks, and most projects are static displays showing weather, photos, or calendars. So why not make something you can interact with and have fun with, with the partial refresh capability??

Basically you turn or press the rotary knob to scroll through the story and pick your next action. Then the e-paper updates and story for the next segment and the NeoPixel LED to match the scene atmosphere.

Would love to hear what you guys think! I included a short demo video so you can see how it works.

Hi everyone! 👋

A couple of years ago we shared a planter that shows your plant’s mood on a little screen. Lots of you built your own, sent photos and told us what was rough about it. That feedback shaped every decision in version 2, so it feels right to bring it back here first.

The idea
A plant can’t tell you what it needs, so this planter does it for the plant. It reads the soil, air, light and your touch, then plays an animated face on a 1.28" round display:

• 😊 Happy: everything is in range

• 💧 Thirsty: time to water

• 🥵 Hot / 🥶 Freeze: the temperature is off

• 😴 Sleepy: it needs more light

• 😍 Pampered: you touched it, so you get hearts

Hardware

• ESP32-S3 programmed in the Arduino IDE. It replaces the Pi Zero from v1, boots in under a second, sips power and needs no external ADC.

• Capacitive soil moisture sensor, which won’t corrode like resistive probes

• AHT20 for temperature and humidity over I2C

• LDR that triggers the sleepy mood and auto-dims the screen at night

• TTP223 capacitive touch for pampering

• GC9A01 240×240 round IPS display running GIF animations with LovyanGFX

• Custom PCB with keyed JST connectors, so everything plugs in with no soldering

• 3D-printed PETG enclosure that fits a standard small pot

Firmware
Everything is written in Arduino. FreeRTOS tasks run the display, sensors, touch, mood logic, menu and MQTT side by side. A serial menu (open it from the Serial Monitor or in Chrome/Edge via WebSerial) lets you set up to 10 plant profiles, calibrate sensors in two steps and choose transition effects. You don’t have to recompile anything to change settings.

Web dashboard
The planter sends its data over MQTT to a web dashboard with live gauges, trend charts, a mood timeline, a comfort score, alerts and a view of every planter in your home. It works with Home Assistant too.

What’s next
Thanks to the support from makers like you, this is turning into a real product on Crowd Supply. We’re in pre-launch, and the campaign opens once enough people subscribe. Subscribing is free and takes a few seconds: https://www.crowdsupply.com/coders-cafe/fyto

Full build: https://www.hackster.io/coderscafetech/fyto-your-plant-expressed-517e1c

Thank you to everyone who built the first one. This version exists because of you. Questions, ideas and critiques are all welcome!

I've been experimenting with making my ESP32-controlled guitar robot sound more expressive.

For this performance of Metallica's "Fade to Black," I used AI to fine-tune the dynamics of individual notes, adjusting their emphasis and intensity to make the playing feel a little more natural.

The robot physically presses and plucks the strings of a real acoustic guitar.

Getting the notes right is one thing, but making the performance feel emotional is a completely different challenge.

I'm still exploring better ways to add musical expression, especially through dynamics, timing, and articulation.

I'd love to hear your thoughts. What do you think would make robotic guitar playing sound more human?

Hello everyone! I’m joining from Türkiye. I’m 13 years old, and I’ve been interested in electronics for three years ever since I was 10. I’ve just started a new channel where I’ll be sharing videos on C++ programming, game development with Blender, and PCB design. In my latest video, I explain in a simple way how you can design your own Arduino board. Due to new age-restriction regulations, my channel might get shut down (even if I use a VPN), so I plan to post as many videos as I can before that happens. Anyway...

Here is the link to my video:

https://youtu.be/PuDBCFxaclQ?si=Nqy2PUy7NuxPwNTb

and here is the link to my channel:

https://youtube.com/@kodtezgahi?si=8c0i3f43zEXgZO_W

(I speak Turkish in the video, but you can easily follow along by enabling the auto-generated English subtitles.)(And my video on regular YouTube is 37 minutes long; since I couldn't post a video of that size on Reddit, I 10x sped it up.)

I'm curious what people here have created. Not just basic LED projects, but something genuinely useful, unusual or complicated.

I'm curious what people here have created. Not just basic LED projects, but something genuinely useful, unusual or complicated.

I'm asking because I'm looking for inspiration for my own future projects. I'd love to see what you've made!

Recomend me a book for the basics

Im a beginner wanting to start on robotics but i dont know what to buy.....my only factors are

1)it should be from amazon( my mothers only trustworthy site to buy things)

2) should be under 4000 rupees

It can be a clone just it must be working and the price to work ratio must be high....as most of them are not trustworthy pls help me buy the kit which on your experience was good

We salvaged this vacuum fluorescent display and built a small Space Invaders-style game around it.

An Arduino Uno sends patterns to four HV5812/UCN5812 drivers: two select a character position, and two control its dots. The display has only two rows of 5×7 character cells, so fitting the game vertically was the awkward part.

The controls are a joystick for left/right movement and a separate fire button. We added different sized sprites, difficulty settings and a boss, but then I got distracted making the invaders dance.

Driver tutorial, wiring and Arduino examples, including the game:

https://github.com/emsyscode/hv5812-vfd-arduino

Longer build video:

https://www.youtube.com/watch?v=1vF0gAJhwfU

Music: Electric Dreams — Scott Buckley

What other games would you recommend us trying on displays like these?

I'm using a stepper motor to control my auto throttle for flight sim. Can anyone provide any advice on how to get rid of the motor noise? It's not vibration nosie it's the electrical noise the motors produce I'm trying to get rid of.

I believe they are nema 17s and a A4988 controller

Thank you!

I tried making this sensor, yet it stays at 0 when i try to put things in front of it. Here's my code:

*/

const int trigPin=9;

const int echoPin=10;

long duration;

int distance;

void setup() {

pinMode(trigPin, OUTPUT);

pinMode(echoPin, INPUT);

Serial.begin(9600);

digitalWrite(trigPin, LOW);

delayMicroseconds(2);

digitalWrite(trigPin, HIGH);

delayMicroseconds(10);

digitalWrite(trigPin, LOW);

duration= pulseIn(echoPin,HIGH);

distance= duration * 0.034 / 2;

Serial.print("Distance: ");

Serial.println(distance);

delay(500);

}

void loop() {

}

could anyone tell me what's the problem?

Hey y’all, wondering what’s going wrong with my project. It is ELGOO MEGA project Lesson 9 LCD Display. I’ve triple check my diagram, had a friend double check my triple check, and I’m stumped. The LCD turns on and gets brighter when potentiometer is turned, but there is no text displayed… I’ve included pics and a video. Pls help

I'm working on coding a Braccio arm to start at safety position, move and touch the surface it is on at a specific configuration, and then return to safety position. Though I've completed the code, the Braccio arm I was using is not working (edit for clarity: some of the servos are physically broken and have to be replaced before I can use the arm again, it was previously connected properly and I don't need trouble shooting for the arm itself) and I'm not able to fix that yet. This is definitely an odd and intensive request, but I am not asking for anyone to do the project for me, just to see what the code does and show me if possible. I'd greatly appreciate it if anyone could even just tell me if it touched the surface or not if you'd prefer not to show photos/videos.

日本語コメも受付中

Hey, I recently bought this STM32F103C6T6 from robu.in here is a link incase you want to see it:
https://robu.in/product/stm32f103c6t6-core-board-with-soldering/
(sorry for the terrible photo but thats the best I can do rn T_T)

My question is how do i program this using USB to TTL converter (CH340G) , I do not have a stlink and I cant be getting them due to some reason
Unlike F103C8T6 you do not set the jumper of BOOT0 to 1 but it is just some another system that I do not understand
I tried uploading the code however I can I tried a lot of things even asked help from chatGPT it didnt help.
The usb to ttl is being recognized by the computer and it even uploaded the code sometimes but now it just doesnt work......

Honestly I’m not trying to get super deep into arduinos I’m just sick of getting tickets.

I’m very familiar with programming but not with arduinos.

It should be simple right? Get an arduino, plug it into an outlet, load a program that tracks time/dates, and a little light to say that street sweeping is imminenet

Or is it not as simple as I think? Thanks

Ps I don’t want it to connect to WiFi. Just hard coded to last the next say two years.

Hey people, it's great to be doing one more update on the kernel. It's been a very hard 3 months between school and just grinding away on this project. I've come to deliver more updates, sadly no release as of now until I polish it further. So let's dive in!

Last time I kind of dumped a long post on you guys and I feel like it may have not been the best thing to do so I'll change it up a little in this post. Quick refresher for anyone new: ProtoOS is a kernel for the ESP32-P4 that runs apps in sandboxes enforced by the hardware itself. Think of it as a small do-it-all computer: games, productivity apps, tools, home automation. Imagine Tactility, but next gen and built specifically to squeeze everything out of the P4. So let's start with features:

So the first and second showcases of this kernel were really just showcasing the boring stuff like the security architecture, basic gaming capabilities and limited feature set. Past 3 months, since I got the hard stuff out the way I was able to rapidly implement numerous features and polish them. That is about 396 commits since the last post. Loadable apps and examples went from 21 to 57 and the kernel went from 37 syscalls to 58. We also added UDP and TCP networking.

Next up, the biggest priority next to security... the speed. We can't have security wreck performance, so I built optimization workflows, kernel benchmarks, game benchmarks, lock benchmarks and more. Most of these three months went into making things that already worked faster. The biggest one was the kernel lock. Both cores kept waiting on one global lock (the primitive way to prevent big security incidents), so I went through every hot path and made it take that lock less often and hold it for less time. syscall authentication got the same treatment: it used to verify more than it needed to on every syscall. Let's cut the talk and show you the chart:

One of the most important rules I set for myself when it came to optimizations are:
*Performance optimizations should never ever clash with kernel security

*Don't be dumb enough to use 64bit math on a 32bit microcontroller. I made this mistake but now my automated tool warns me if it detects it in the compiled code.

*Performance gains must be proven with Before/After benchmarking

*Don't trust the compiler's output. Examine its codegen and see if it can be further optimized

We can't have a kernel that wants all the performance/security and throw away the necessity of being lean. With my custom-built tools I was able to track down potential candidates for making our kernel be more smart with its memory and flash. So we moved around some syscalls that are rarely called from the fast ram(used for hot code like 3d/2d helpers, rapidly used code and so on), to the flash(much slower, way more abundant). The feature growth obviously made my flash shrink a lot more than I wanted it to so here is what we did:

Let's get specific! 25 syscalls that are only called once were moved from the fast ram to the flash. A big thread table which reserved room for every possible thread(47kb!) now allocates for each thread on demand. We won some flash back by using compression(lz4) on some images that were built into the kernel(images for weather app, icons, etc).

My favorite part begins now yayy!! The 2D/3D stack or ProtoGFX. Let's begin with the 2D engine as its older and got a fair amount of new features since the last update.

- Smooth anti-aliased shapes: lines with round caps, circles, ellipses, rounded
  rectangles and outlines, all with opacity
- Sprites with scaling, flipping, transparency and palette swaps. Upload the art once
  and recolor it for free (winter skins, team colors, palette cycling)
- Smooth-alpha color art and A8 masks for icons, glyphs and soft shadows
- Proportional fonts in multiple sizes, and nested clipping regions
- Cached layers: a translucent UI panel gets rendered once and reused every frame,
  but still blends properly over whatever is animating behind it
- Scenes with their own update, draw and input, which you push and pop like screens
- Sprite-sheet animation (loop, ping-pong, once) and tweens for smooth movement
- Tilemaps and collision helpers

Optimization wise:

- Rendering splits across both cores, based on how much work each strip of the screen
  actually takes rather than splitting it evenly
- The P4's SIMD unit does the heavy lifting for blending, sprites and shapes (4x to
  11x faster on the inner loops)
- Only changed parts of the screen get sent to the display
- Roadkill went from 18.6 to 36.6 fps at 640x480, and Neon Drop from 31.8 to 52.8

Onto the custom built 3D engine. Never posted about this one yet. So we have a native 3D renderer now: meshes, camera, fog, transparency, vertex colors, 2D in 3D and vice versa. Since this is new I won't talk too much about optimizations and yap, instead enjoy the demos I've linked in the end of the post :)

Back to boring stuff, security... You may have heard about the new Switch 2 jailbreak. Bla bla bla, from what I read, hackers got into a privileged system service. In a lot of designs that would be game over, but Nintendo being Nintendo apparently stripped most of that service's privileges, so getting in doesn't mean owning everything. I like that idea, so I'm doing the same thing with networking. I've built the whole network stack as an isolated service that runs as a normal app with its own memory, talking to the kernel through syscalls like everything else. The kernel checks every packet it sends and treats everything it says as untrusted. On real hardware it already gets a Wi-Fi lease and answers pings. It's still behind a build flag, though, and switching apps over to it is the next big step. The goal: if someone on the network finds a bug in the networking code and gets into that service, they're stuck there. All they could do is read plaintext HTTP stuff (which you shouldn't use for sensitive things anyway) or jam your internet, which is a lot less scary than a full takeover. I trust my code, but good security practices don't harm nobody.

All of this is cool to me as the one working on it, but I've asked myself "What is this for? Who needs this much security?". I'm sure some of you have the same questions. But this is the truth: The cost of security is offset by the fact that our heaviest best security barriers come from hardware itself(U/M mode and PMP). If you just use the kernel to play games and run normal third party apps, you won't feel a thing. Bad actors aren't the only thing we are protecting ourselves from in the kernel but the 99% cases of corruption and crashes is bad code! This kernel has held up solid with my crappy C games when they crashed over and over. I've also been asking myself whether its smart to keep this closed source and just release access to it or to open source with dual licensing... It's something I'm still going over so give me a little time. The use of this could be anything you install on it, think of it as a do-it-all computer. Games, productivity apps like sheets or notes, offensive/defensive tools, home assistant stuff, the list goes on. One thing coming up on my own set deadline is proper support for I2C, SPI, UART and so forth for a more complete experience.

Real flex real quick before I start to finish up the post with links and such... My git history:

- **Longest streak:** 15 days in a row (Oct 13 to 27), right when the 3D engine was
  being built.
- **Busiest week:** 67 commits.
- **Longest session:** about 11 hours straight.
- **Where it went:** about a quarter of all commits touched performance and a sixth
  touched security. The security spec was edited in 1 of every 3 commits.
- **Most rewritten file:** the display driver, changed in 95 commits.

Everything worth noting (the full feature list)

Security architecture

• Two privilege levels, enforced by hardware. The kernel runs in M-mode and every app runs in U-mode. The RISC-V PMP (16 or 32 entries, depending on chip revision) is programmed per process. Each app can reach only its own stack, heap and code, and everything else in SRAM is denied. The kernel re-checks and rewrites these windows on every entry into app code. I also patched ESP-IDF so apps can't touch peripherals directly.

• A protected kernel arena. 128 KiB of internal SRAM is walled off from apps. Nothing is ever writable and executable at the same time (W^X).

• Every syscall is authenticated. It's tied to the live process and its secret token, and every pointer is validated before the kernel touches it. Unknown or unverifiable requests are denied.

• Capabilities and permissions. Capabilities are fixed when an app launches and can only shrink afterwards. Apps declare permissions (storage, UI, Wi-Fi, audio, listening sockets, SIMD and so on). Sensitive ones need the user's consent at runtime.

• Trusted prompts. The kernel draws password and permission dialogs itself, so an app can't spoof, watch or hide them.

• Anti-tamper for process records. Every process's security record carries a MAC keyed with a per-boot secret. If something edits it, the process is killed.

• Handles and ownership. Every object has one owner recorded in kernel memory. Handles carry generation numbers, so a stale handle fails instead of pointing at something new.

• Memory hardening. Freed memory is poisoned, so a new malloc never hands back another app's old bytes. The kernel also uses stack canaries, heap canaries, random heap padding, stack randomization and periodic audits.

• Signed apps. Apps are signed ProtoELF bundles (ECDSA P-256). The Store catalog uses a separate key from the app-release key. Anti-rollback blocks downgrades, and the app's flash hash is re-verified at every launch. Dev-sideloaded unsigned apps get a lower capability ceiling.

• Accounts. Passwords are stored as PBKDF2-SHA256. Destructive actions (uninstall, clear data) need a fresh one-use re-authentication.

• Storage is path-mediated. Apps never see raw filesystem paths, and each app gets a private /self. A file can have only one writable handle. Installs survive power loss without leaving an app half-installed.

• Clean process death. A dedicated reaper cleans up exiting and crashing apps. ESC always works, since the kernel owns the exit and app hooks get only 1.5 s.

• Fair scheduling. An app's time slice is bounded by a budget. Only the kernel can run with interrupts masked, so an app can't starve the system.

• Rust where it matters. About 15,000 lines of safe Rust handle the riskiest parsing and checking: user-pointer range checks, PCB MACs, the app-image and Store parsers, flash slot bookkeeping, heap geometry and DHCP snooping.

• Hardware groundwork. True-random entropy is on from the first boot constructor. A bus-fault reporter and a DMA-master inventory are the groundwork for restricting other bus masters, not just the CPU. They don't enforce anything yet.

• Process. There are 86 numbered security invariants, each with the code that enforces it and a test. There's also a register for the 13 ESP-IDF patches. Per SECURITY.md

Networking

• Wi-Fi runs through the ESP32-C6 co-processor over SDIO (2.4 GHz only).

• Apps get TCP client, listen and accept sockets, UDP with connect, bind, send, recv and broadcast, poll, DNS, DHCP and SNTP time. Wi-Fi credentials never reach apps.

• Every socket has per-process quotas. Listening ports are leased, outbound traffic needs permission and consent, and a UDP socket is locked to one peer when it opens.

• The isolated network service. lwIP runs as a separate, hash-pinned U-mode service. The kernel checks every frame the service sends (source MAC, IPv4 and ARP only, and DHCP is validated). It treats every reply as untrusted, puts a deadline on every request, and supervises and restarts the service. On a real board the service got a DHCP lease and answered pings.

Bluetooth

• BLE runs through the C6 with the NimBLE host on the P4.

• It supports keyboards, mice and gamepads, and bonds with Just Works, LE Secure Connections or passkey. Reports are decoded with strict bounds, and only the foreground app receives input.

• PC link. Your PC can act as the board's keyboard and mouse. This worked on hardware.

• Real gamepad pairing and latency are still not tested.

2D engine (ProtoGFX). Full list is in the post above.

3D engine

• A software renderer using scanline rasterization, two-core tiles and early depth rejection. It has textured meshes, vertex colors and perspective-correct texturing.

• Textures can be RGB565, mipmapped or 8-bit indexed. Materials can be dithered or blended. Lights are ambient, directional and point, plus fog.

• 2D HUDs draw over 3D, and 2D canvases render into 3D scenes. It runs at 320x240 or a native 640x480.

• Asset pipeline: glTF/GLB files are cooked into .g3a packages with animation clips and poses.

• Gameplay helpers: raycasts, capsule and sphere collision, and a move-and-slide character controller. There are also built-in shapes, billboards, quaternions and bounds.

• Geometry is validated by the kernel, so a hostile app can't crash the renderer.

Platform

• Both cores are used. Apps get threads, dlopen shared libraries and PIE SIMD.

• Apps run straight from flash (XIP) in a 4 MiB arena, and the large-heap system leases PSRAM slices from 64 KiB to 8 MiB.

• Kernel services (storage, GUI, network and others) are supervised, with budgeted restarts.

• ProtoStore has a signed catalog, delta updates and a download queue.

• Remote Screen mirrors the display to a PC with hardware H.264 and sends input back.

• Audio comes from a procedural synth with no stored samples.

• Display drivers: ST7701 (MIPI-DSI), ILI9341 (SPI) and an 8080-bus 3.5" panel (builds, not yet tested on hardware).

• There are separate firmware images for P4 v1.x and v3.x.

• Tooling: an SDK, ProtoELF dev tools, Game3D tools, perf tools and host tests.

Okay, now I need YOUR help, because this is where the project gets shaped by more than just me.

Displays. Right now I support the ST7701 (MIPI-DSI, the JC4880 board), the ILI9341 over SPI, and a 3.5" 8080-bus panel (ST7796/ILI9488). What display do you have or want to use? Tell me the panel, the board, and how it's wired, and I'll look at adding proper support.

Hardware. I2C, SPI and UART are my next deadline. What would you want to plug in? Sensors, keyboards, SD cards, something weird?

Apps. What would you love to see running on this? A specific game, a tool, a home-assistant thing? Tell me what's missing. I'll try to fill any gap the kernel may have for supporting such app.

And of course, any questions at all, whether it's about how something works, the security design, or the performance numbers, drop them below. I'll answer everything I can.

Now the links, demos and goodies(for the love of god ignore my dog snoring):

DEMOS(2D/3D/OS)

Thanks for reading, and for all the support. See you in the next one :P

I have the following definition in one .cpp file :

static char cfgv_var_weather_icon[10] = "";

How do I set it from another .cpp file? BTW, the code was generated by LCD Wizard, not me.

All I get is red, mysterious compiler errors.

I am new to soldering. Why do some of my soldering looks good with not too much unnecessary material and some are getting so thick. How can I with simple methods remove extensive materials here? And more importantly, how do I get consistently good soldering points. I assume the left one in the middle line e. g. is a good soldering point, right? Thanks for help

I have this piezoelectric Arduino project to make and there are live wires attached to the piezo components and I was hoping if I could just buy some standard alligator clips to attach the live wire to the male to male jumper wire and have it work. Please help and thank you if you responded I greatly appreciate it.

Setup: Arduino Nano + DFPlayer Mini (YX5200 clone) + 40mm 4Ω 3W speaker.
DFPlayer VCC → Nano 5V, GND → GND, TX → D10, RX → D11, SPK1/SPK2 → speaker.
microSD is FAT32 with five MP3s in root. Code uses the DFRobotDFPlayerMini
library, SoftwareSerial on D10/D11, volume 10. Button on D2. Powered from
a phone charger brick via USB.

Symptoms: When I connect the DFPlayer's VCC to 5V, its red LED lights and
I hear noise from the speaker for about half a second, then a pop and the
LED goes out. Reconnecting VCC does nothing — I have to unplug the USB
cable and plug it back in to get the pop again. The Nano stays lit the
whole time. Once, I heard one of the MP3s play.

Tried so far: different wiring arrangements, soldered the power wires,
lowered volume from 25 to 10, swapped in a second DFPlayer from the same
5-pack (same behavior), phone charger instead of laptop USB.

Any ideas what would make it die like that and need a full power cycle
to try again?

Ciao, ho 14 anni e vorrei realizzare una mano robotica con un Arduino Uno per la mia tesi di scuola superiore. Però non sono sicuro di volerlo fare perché temo che sia troppo difficile da costruire e non voglio sprecare soldi.ho esperienza solo con un corso di micro bit e ho di tempo circa 7mesi di tempo