software-developmentembedded-systemsidegitai-agent

Tantalum Project: The Hardware Platform I Wanted To Use

RKK Vishva Kumar

June 26, 2026 · 12 min read

Tantalum Project: The Hardware Platform I Wanted To Use

In December 2025, I got the idea for Tantalum while we were working on one of our hardware projects. We had to work with multiple development boards at the same time, and honestly it was not smooth at all. Managing boards was hard. Detecting boards was frustrating. I had to try each port again and again just to find which port belonged to which board. OTA updates were also not easy. Arduino needed a subscription for some workflows, and many open source tools were powerful but too complicated to set up quickly. Another thing I noticed was Git. Most hardware IDEs did not make Git feel like a normal part of the workflow. Because of that, many people did not use version control for hardware code unless they really needed to.

At the same time, we were also using agentic coding inside our project. That gave me another thought. What if hardware development also had one proper platform where I could code, manage boards, detect ports, compile firmware, push OTA updates, sync projects, use Git properly, recover board source code, and use AI agents in the same place? That was the moment Tantalum started in my mind.

Back in December, during the flood in Sri Lanka, I started experimenting with this idea. I researched the existing tools and checked whether this was actually possible. The result was a green flag. Then I started learning Electron, because I wanted Tantalum to be a desktop IDE that could talk to local files, serial ports, Arduino CLI, and cloud services.

Tantalum later became more than just an IDE. It became an ecosystem with three parts. Tantalum IDE is the desktop application. Tantalum Web is the cloud portal and admin dashboard. Tantalum Mobile is the companion app for WiFi provisioning. The IDE is built with Electron, React, TypeScript, Monaco Editor, Arduino CLI, serialport, Appwrite, OpenCode SDK, and other tooling. The web app is built with Next.js 15, React 19, TypeScript, Appwrite, and Lucide icons. The mobile app is built with Flutter and Android native bridges for ESP32 provisioning.

The biggest feature I wanted first was better board detection. Normal board detection is not enough when multiple boards are connected. So Tantalum combines Arduino CLI board list data with USB serial metadata. It checks serial numbers, VID, PID, PnP ID, location ID, and physical port identity. On macOS it also handles the difference between /dev/tty.* and /dev/cu.* paths. For ESP boards, it can use esptool chip_id to identify the exact chip and convert a vague ESP family match into a proper FQBN. If the board is still confusing, Tantalum can use an Appwrite board-detection function with an AI fallback and cache the result.

For firmware builds, I did not want to reinvent Arduino compilation. Tantalum uses Arduino CLI, but wraps it with a better workflow. Before verify, upload, or OTA release, the IDE creates a temporary sketch workspace. If cloud runtime is enabled, it injects TantalumCloudRuntime.h, board ID, API token, Appwrite endpoint, firmware version, MQTT settings, TLS certificates, provisioning proof, and OTA mode. The user sketch stays clean. The user still writes setup() and loop(), but Tantalum wraps them so runtime tasks like WiFi, heartbeat, MQTT, OTA, telemetry, and provisioning can run together.

OTA was another main reason I built this. I wanted firmware updates to feel normal, not like a separate painful process. In Tantalum, the desktop compiles firmware, calculates a SHA 256 checksum, uploads it to Appwrite storage, creates a firmware document, and then deploys it through the board-admin function. Boards can get updates by polling device-gateway, by MQTT push commands, or by both. MQTT uses a Mosquitto broker with TLS, and commands are signed with HMAC SHA 256 so boards can verify that the update command is real.

One feature I really cared about was View Code. I wanted this because we had faced this problem many times after flashing boards. After a few days or weeks, we sometimes forgot the exact code we had uploaded. Sometimes we overwrote the old code with a new version, and later we needed to know what was actually running inside the board. For small Arduino sketches with one or two files, using Git for every tiny dynamic change felt too much at that time. But without Git, we had no easy way to see the exact source code inside the board. This became a real headache for our team many times, and we saw the same issue in other teams also. So I wanted Tantalum to solve this properly. I did not want to fake decompilation, because compiled firmware cannot be turned back into exact Arduino code. Instead, Tantalum saves source snapshots before upload or OTA release. It creates a zip with tantalum-source-manifest.json, stores it in firmware_source_bucket, and injects a marker into the firmware. Later, when View Code runs, the IDE reads the board flash using tools like esptool or avrdude, finds the marker, downloads the matching source zip, verifies the checksum, and restores the real source files. This made code recovery honest, practical, and very useful for real hardware work.

Provisioning was also important because WiFi passwords should not go through the cloud, and boards are not always used in the same place where they were first flashed. Sometimes after taking a board to a different lab, room, or field location, we needed to connect it to a different WiFi network. Wired provisioning worked, but it was not the best experience because I wanted to reduce the need for cables as much as possible. So I added USB provisioning for the first setup, but the better long term solution was BLE or SoftAP provisioning through the mobile app. The mobile app requests a temporary provisioning window from board-admin, then sends WiFi credentials directly to the board using Espressif provisioning tools. Appwrite never receives the WiFi password, and the mobile app does not store it permanently. That privacy decision shaped the whole provisioning design.

For project sync, I wanted something smoother than manual Git. Git is a good solution, but in real work we still have to remember to commit, push, pull, handle authentication, manage access, and care about team permissions. Sometimes we forget to push the latest changes, and then when we open the project from another device, the code is not the version we expected. I faced this because I used both my laptop and desktop at the same time, and it became troubling to keep everything updated manually. So I wanted Tantalum to have a better way to sync projects across devices. Inside a team, this can become a game changing feature because everyone can keep their hardware project code backed up and available without thinking about Git every time. Even if I come back after many years, I want to pull my projects from the cloud without worrying about manual Git setup or old GitHub accounts.

Technically, Tantalum handles this using a shadow Git repository instead of touching the user’s own Git history. It scans the workspace, applies .tantalumignore, ignores things like .git, build output, and .node_modules, then copies allowed files into a shadow repo. That repo syncs with a Gitea remote. This way, Tantalum can back up and sync projects without accidentally rewriting or damaging the developer’s own repository.

I also wanted Git to be part of the IDE experience. Many hardware IDEs do not give Git support out of the box, and I feel that is one reason many people do not use version control for hardware code unless they are really forced to. In software projects, Git is normal. But in hardware projects, especially with small Arduino sketches, people often just save files, duplicate folders, or rename versions manually. I wanted Tantalum to make Git feel natural for hardware developers. That is why I added Git related tools into the agent layer and project workflow, so users can track changes, recover older work, and manage code history without leaving the environment.

The agentic AI part was another big area. I did not want the agent to only generate code. I wanted it to understand the whole IDE and the full hardware workflow. It should be able to look at the project I am working on, suggest the libraries needed for it, install those libraries, install board platforms, verify Arduino sketches, upload firmware, work with Project Sync, use Git on behalf of me, and generally handle the IDE workflow when I ask it to. Because of that, I integrated MCP support and connected the agent with Tantalum features instead of keeping it as a simple chat box.

At the same time, I was very thoughtful about responsible AI, privacy, security, reliability, safety, and transparency. By default, Tantalum AI needs manual permission for actions like creating files, renaming files, deleting files, updating code, installing libraries, installing platforms, and running important tools. Users can manually give full access if they want, but the default behavior is permission based. The IDE also scans only safe workspace files, excludes secrets like .env, keys, certificates, credentials, and .git, and keeps restore points so users can go back if the agent changes something wrongly. This made the AI assistant useful, but still controlled and safe for real hardware development. Tantalum AI is still not perfect and it still needs improvements, especially in making agent actions more reliable, more context aware, and smoother inside the hardware workflow.

I also added many small features that made the IDE feel more complete in daily use. One of them is the notification panel. It tracks important processes like verify, compile, flashing, library installation, platform installation, OTA actions, and other background tasks. If something fails, the user can open the full debug log from that notification and trace what went wrong instead of guessing from a small error message. It also keeps past notification history, so even later we can go back and check what happened before. I added settings features too, so users can configure things like Arduino storage, board preferences, cloud options, agent access, and other parts of the workflow in one place. These small features are not always the loudest part of the project, but they are the things that make the tool actually comfortable to use.

Tantalum Web was also an important part of the ecosystem. I did not want it to be only a landing page. Users can sign up from the web app, authenticate their IDE and mobile accounts, manage their account, and see their boards and project related details. But the main part I cared about was the admin panel. Through the admin panel, an admin can manage users, configure backend settings, provide AI model pool keys for Tantalum AI, and control platform level features. I worked with self hosted Appwrite for the main backend, a separate VPS for project sync using Gitea, and MQTT for fast OTA update commands. Maintaining this infrastructure manually was also a challenge, so I added support for scaling infrastructure when needed using Azure. Instead of building a complex horizontal scaling setup early, I focused on vertical scaling, where the VPS can be resized to a bigger tier when the workload increases. This made the backend more practical for an MVP, while still keeping a path to grow later.

There were many challenges. Learning Electron while building a real hardware tool was not easy. IPC security needed care, because the renderer should not get full Node.js access. Serial ports behaved differently across platforms. Arduino CLI output had to be streamed properly to the UI. Board detection had many edge cases. Runtime injection had to work without changing the user’s saved files. OTA needed token security, checksum validation, MQTT delivery, polling fallback, and telemetry. Source recovery needed a marker system that would not get optimized out by the compiler. Cloud sync needed to protect user projects. AI agents needed boundaries, approvals, and restore points.

Tantalum later went into pause for some time. While I was building Tantalum, I had learned a lot about Electron IDE development, and I used that knowledge to build Sonar Code Editor with the help of our Knurdz Community colleagues. Sonar is a controlled environment for coding exams and hackathons. While building Sonar, we also created two libraries called jack-file-tree and jack-editor-tab. Later I brought those libraries back into Tantalum IDE too, because they helped with the file tree and editor tab experience. After that, I came back and kick started Tantalum again. This time I worked heavily on it and used agents to speed up coding tasks. But I learned one important thing. Agents can speed up coding, but they cannot replace system design, architecture thinking, product decisions, and debugging the real world behavior of hardware.

Tantalum became the platform I wished we had when we were struggling with multiple development boards. It is not only an IDE. It is a hardware development workflow with board detection, Arduino editing, firmware compilation, OTA updates, cloud board management, WiFi provisioning, project sync, source recovery, telemetry, and an AI assistant. The main goal is simple: make embedded development less frustrating and more connected, without hiding the technical power from the developer.

Here after, I will hardly work on hardware projects like before, and maintaining Tantalum with all the infrastructure is not feasible for me anymore. So I am shutting down the infrastructure services and making this project open source. It is a little emotional for me, because this project started from a real problem we faced and grew into something much bigger than I first imagined. I hope someone will benefit from it, learn from it, or even build a better version of it. If you are interested, you can collaborate on this project. I warmly welcome contributions, ideas, fixes, and improvements. Tantalum may not continue in the same way from my side, but I still want it to be useful for someone.

Project Links:

Originally published on Medium

All posts