{"slug": "show-hn-tinyml-ai-a-new-architecture-to-control-embedded-intelligence", "title": "Show HN: TinyML AI – A New Architecture to Control Embedded Intelligence", "summary": "Developer Nazmul published a Show HN post introducing TinyML AI, or the Pluto Engine, a natural language model he says runs directly on an Espressif ESP32 microcontroller without third-party APIs or models. The demonstration pairs an ESP32 dev board (Xtensa LX6, CH340 USB-to-UART, USB Type-C) with an external HC-06 Bluetooth module over UART2 at 9600 baud on GPIO 16 and 17, a choice made to conserve flash memory and RAM, and a Flutter chat app that translates Bengali input to English online before sending it to the engine, which supports only English. The post is split into four sections covering overview, engine functionality, training and limitations, and applications, and links the Flutter app source code for review.", "body_md": "# TinyML AI - (Pluto Engine): A natural language model designed for general intelligence that can directly control microchips.\n\nImportant\n\n**This is an entirely different AI model.**\n\nIt does not utilize any third-party APIs or models. It features a unique architecture (Pluto Engine) that differs from conventional pattern-based models.\n\nNote\n\nTo provide a detailed explanation of how our new model functions and its internal structure, the entire presentation has been divided into 4 sections:\n\n**01 — Overview**\n\nAn overview of how TinyML AI (the Pluto Engine) operates within a microchip, including further details.\n\n**02 — Engine Functionality**\n\nA discussion on how the Pluto Engine functions.\n\n**03 — Training & Limitations**\n\nHow the Pluto Engine is trained, and the limitations of its capabilities when running on a microchip.\n\n**04 — Applications & Industries**\n\nPotential applications and sectors where the Pluto Engine can be utilized.\n\n## 01 — Overview (This section provides a detailed walkthrough, including experiments using an ESP32 device.)\n\nNote\n\nMy language is Bengali; I write articles in Bengali first and then translate them into English. If you have any trouble understanding something, please feel free to send me a direct message on LinkedIn. [https://www.linkedin.com/in/nazmul-agi/](https://www.linkedin.com/in/nazmul-agi/)\n\nWarning\n\n**Bluetooth Configuration and Flash Memory Optimization**\n\nIf you have watched the video above, you might have noticed that an external Bluetooth module (HC-06) is used, even though the ESP32 module comes with built-in Bluetooth.\n\nThis approach was taken to conserve the ESP32's flash memory and RAM. Using the built-in Bluetooth would consume a significant amount of these resources, leading to a memory shortage for the 'Pluto Engine.' Consequently, a separate Bluetooth module was used instead.\n\nThe HC-06 communicates with the ESP32 through UART2 using the following configuration:\n\n```\n#define RX2_PIN 16\n#define TX2_PIN 17\n\nSerial.begin(115200);\nSerial2.begin(9600, SERIAL_8N1, RX2_PIN, TX2_PIN);\n```\n\n**Code explanation:**\n\n- `RX2_PIN 16` : ESP32 GPIO 16 receives serial data.\n- `TX2_PIN 17` : ESP32 GPIO 17 transmits serial data.\n- `Serial.begin(115200)` : Initializes the USB serial interface for debugging.\n- `Serial2.begin(9600, SERIAL_8N1, RX2_PIN, TX2_PIN)` : Initializes UART2 at 9600 baud with 8 data bits, no parity, and 1 stop bit.\n\n**Note:** These are UART pin definitions and serial initialization settings, not timer configurations.\n\nA lightweight Flutter chat application is used to communicate with the 'Pluto' engine on an ESP32. User-entered text is sent to an HC-06 Bluetooth module, while text generated by the Pluto engine is received back in the Flutter app. Only the phone's Bluetooth functionality is utilized for this process.\n\nThe application performs three primary functions:\n\n1. **Bengali-to-English Translation:** Bengali or another language is taken as input, and then that text is converted into English via the internet.\n2. **Transmission:** The translated text is then sent to the HC-06 module from the phone via Bluetooth. (Pluto Engine) supports only the English language.\n3. **Text Reception:** The text generated via feedback from the system (Pluto Engine) is received in the Flutter app through an HC-06 Bluetooth module.\n\nThe Bluetooth connection between the phone and the ESP32 does not itself require an internet connection. However, the translation feature requires internet access.\n\nThe source code for the Flutter application has been uploaded to this repository for review, allowing developers to examine and verify the code.\n\nTinyML engine (Pluto) runs on an ESP32 development board featuring a CH340 USB-to-UART interface and USB Type-C connector.\n\n| Specification | Details | \n|---|---|\n| Development Board | ESP32 Dev Board | \n| USB Interface | USB Type-C | \n| USB-to-UART Bridge | CH340 | \n| Microcontroller Family | Espressif ESP32 | \n| CPU Architecture | Xtensa LX6 | \n| CPU Cores | Dual-core (2 cores) | \n| Maximum CPU Frequency | Up to 240 MHz | \n| Internal SRAM | 520 KB (chip-level specification) | \n| ROM | 448 KB (chip-level specification) | \n| Flash Storage | 4 MByte (32Mbit) | \n| Wi-Fi | 2.4 GHz, IEEE 802.11 b/g/n | \n| Bluetooth | Bluetooth Classic and BLE (original ESP32) | \n| GPIO | Up to 34 GPIOs on the original ESP32 chip; board availability varies | \n| ADC | 12-bit SAR ADC | \n| DAC | 2 × 8-bit DAC (original ESP32) | \n| PWM | LED PWM controller, up to 16 channels | \n| General-Purpose Hardware Timers | 4 (original ESP32) | \n| High-Resolution Software Timer API | `esp_timer` , 1 µs time resolution | \n| Communication Interfaces | UART, SPI, I²C, I²S | \n| Programming Platforms | Arduino IDE, ESP-IDF | \n| USB Programming | CH340 USB-to-UART bridge | \n\nThe current TinyML AI device (Pluto Engine) includes the following features, though some are limited.\n\n- **GPIO** — Digital HIGH / LOW input and output\n- **PWM** — Variable duty-cycle control for LEDs, motors, and other devices\n- **I²C** — Communication with sensors, displays, memory, and peripheral devices\n- **SPI** — High-speed communication with compatible peripherals (Limited)\n- **Servo** — Position control and movement sequences\n- **Analog I/O** — Reading analog sensors and generating hardware responses\n- **Timers / Frequency** — Hardware timing, pulse and frequency generation\n- **Sensors** — Processing sensor data and using it in conditional decisions\n\nThe Pluto firmware is evaluated in three configurations: the Hardware Control Layer, the Pluto TinyML Engine, and the complete integrated firmware.\n\n| Memory / File Type | Total Capacity | Used | Usage (%) | Remaining | \n|---|---|---|---|---|\n| Hardware Control Layer — Flash | 1,310,720 bytes (1.25 MiB) | 378,948 bytes (≈ 370.1 KiB) | 28% | 931,772 bytes | \n| Hardware Control Layer — RAM | 327,680 bytes (320 KiB) | 31,100 bytes (≈ 30.4 KiB) | 9% | 296,580 bytes | \n| Pluto TinyML Engine — Flash | 1,310,720 bytes (1.25 MiB) | 806,788 bytes (≈ 787.9 KiB) | 61% | 503,932 bytes | \n| Pluto TinyML Engine — RAM | 327,680 bytes (320 KiB) | 69,564 bytes (≈ 67.9 KiB) | 21% | 258,116 bytes | \n| Complete Firmware — Flash | 1,310,720 bytes (1.25 MiB) | 1,174,724 bytes (≈ 1.12 MiB) | 89% | 135,996 bytes | \n| Complete Firmware — RAM | 327,680 bytes (320 KiB) | 100,380 bytes (≈ 98.0 KiB) | 30% | 227,300 bytes | \n| `pluto_ML_AI.ino.bin` — Firmware Binary | — | 1,148 KB (reported) | — | — | \n\n```\nSketch uses 378948 bytes (28%) of program storage space.\nMaximum is 1310720 bytes.\n\nGlobal variables use 31100 bytes (9%) of dynamic memory,\nleaving 296580 bytes for local variables.\nMaximum is 327680 bytes.\n```\n\nThe Hardware Control Layer manages hardware-facing functions such as Bluetooth communication, GPIO, I²C (SDA/SCL), and other supported peripheral operations.\n\n```\nSketch uses 806788 bytes (61%) of program storage space.\nMaximum is 1310720 bytes.\n\nGlobal variables use 69564 bytes (21%) of dynamic memory,\nleaving 258116 bytes for local variables.\nMaximum is 327680 bytes.\n```\n\nThe Pluto TinyML Engine provides the core instruction-processing functionality. Its reported memory usage represents the engine configuration tested in this build.\n\n```\nSketch uses 1174724 bytes (89%) of program storage space.\nMaximum is 1310720 bytes.\n\nGlobal variables use 100380 bytes (30%) of dynamic memory,\nleaving 227300 bytes for local variables.\nMaximum is 327680 bytes.\n\npluto_ML_AI.ino.bin = 1148 KB\n```\n\nThis build report represents the integrated firmware containing the hardware control layer and Pluto TinyML Engine.\n\nWarning\n\n**Memory Measurements and Build Configuration**\n\nThe memory information provided above was obtained by compiling the hardware control layer, the Pluto TinyML engine, and the complete firmware under various configurations.\n\nPluto's overall memory footprint depends on:\n\n1. **Microcontroller capabilities:** Available Flash, RAM, CPU architecture, and processing capacity.\n2. **Hardware control functions:** The number and type of supported functions, including Bluetooth, GPIO, I²C, and other peripherals.\n3. **TinyML engine configuration:** Adding more control-layer functions can increase the size of the overall system and its supporting code, potentially affecting the TinyML engine's implementation and resource requirements.\n\nAll reported values are specific to the tested ESP32 hardware and build configurations.\n\nThis benchmark compares a conventional ESP32 I²C address scan with Pluto processing a natural-language instruction to identify connected I²C sensors.\n\n```\nCheck how many sensors are connected to I2C SDA GPIO 21 and GPIO 22 (SDA - SCL)\n```\n\n**Pluto's response:**\n\n```\nOne address is found here (0x76)\n```\n\nThe detected I²C address was `0x76`.\n\n| Metric | ESP32 Pure I²C Scan | Pluto Engine | \n|---|---|---|\n| Execution scope | Direct I²C address scanning | Natural-language processing and task execution | \n| SDA pin | GPIO 21 | GPIO 21 | \n| SCL pin | GPIO 22 | GPIO 22 | \n| I²C clock | 100 kHz | 100 kHz | \n| Addresses checked | 1–126 | Determined by Pluto's implementation | \n| Devices detected | 1 | 1 address reported | \n| Average execution time* | ~18.801 ms | ~110.133 ms | \n| Relative execution time | 1× | ~5.86× | \n\n* An average value is presented here for the ESP32; during testing, the same command was checked 50 to 100 times.\n\nIn this context, the ESP32 I²C scanner directly checks the addresses of connected devices or sensors to determine which ones are responding.\n\nAn important point to note here is that the Pluto engine performs several preliminary tasks—such as interpreting language commands, establishing internal structures, and generating instructions for the control layer—before proceeding.\n\nNaturally, the Pluto engine’s operation involves more overhead compared to a direct I²C scan. However, this does not imply that the Pluto engine is five times slower. Furthermore, these figures are not definitive, as the time required depends on various factors, such as the complexity of the tasks being executed and the processor speed.\n\nThe following code measures the elapsed time of each Pluto function call over 50 iterations.\n\n```\nfor (int i = 0; i < 50; i++) {\n\n    int64_t startTime = esp_timer_get_time();\n\n    pluto(\"Check how many sensors are connected to I2C SDA GPIO 21 and GPIO 22 (SDA - SCL)\");\n\n    int64_t endTime = esp_timer_get_time();\n\n    int64_t elapsedUs = endTime - startTime;\n\n    Serial.printf(\n      \"Test %03d | %lld us | %.3f ms\\n\",\n      i,\n      (long long)elapsedUs,\n      elapsedUs / 1000.0\n    );\n}\n```\n\nThe measured time shown here begins before the main function is called and ends only after the main function has finished its execution.\n\nThis has been done solely for testing purposes; the recorded time includes not only the duration taken by the Pluto engine but also the overhead associated with the underlying hardware.\n\n**1. Different benchmark scopes**\n\nA standard ESP32 scanner measures the process of directly scanning for I²C addresses, whereas the Pluto engine performs additional tasks, such as text processing and managing the control layer. While these metrics are useful for understanding end-to-end latency, they do not provide a direct comparison of the hardware-level scanning performance between the two systems. For a better understanding, please refer to the architecture diagram below.\n\n**2. Results depend on configuration**\n\nExecution time may vary based on factors such as the ESP32 board, Arduino core version, compiler optimizations, I²C clock frequency, active control functions, and the number of addresses or devices being tested. In short, hardware specifications play a significant role here.\n\n**3. RAM usage is not reported in this benchmark**\n\nThis benchmark only estimates the Pluto Engine processing time; it does not provide data regarding RAM usage. This is because the model retains certain information—such as task/layer details and historical runtime data—which makes it impossible to directly determine the exact amount of RAM consumed while the Pluto Engine is running.\n\nAssessing memory usage would require a separate memory benchmark. Such metrics should be measured and reported independently of execution time.\n\n**4. Results are specific to the tested configuration**\n\nThe values mentioned here describe the results of the provided ESP32 tests and the Pluto configuration. These should not be considered as performance benchmarks applicable to other supported microcontrollers or different versions of Pluto.\n\nIn the examples provided above, a standard ESP32 I²C scan took approximately 18.8 milliseconds to complete, whereas the entire instruction-processing workflow of Pluto required about 110.1 milliseconds.\n\nThis additional time reflects the scope of the Pluto engine's operational processing. Therefore, this duration should be evaluated in the context of Pluto’s hardware-control capabilities, memory requirements, and the complexity of the instructions.\n\nIt’s quite simple: on August 24, 2006, Pluto was removed from the list of planets. Since then, it has been all but forgotten, which is why I’ve named this (TinyML AI) project \"Pluto,\" so that the name might be heard once again.\n\n**1. Sentence Filter Layer:**\nThe Pluto Engine is written entirely in pure C++. User-input text first enters the \"Sentence Filter Layer,\" which determines the maximum number of words that can be processed at once. This limit is configured based on the specific microchip—its processor, ROM, and RAM capacity—as well as the features supported by the hardware on which the Pluto Engine is running.\n\nThe Pluto Engine has been implemented on platforms including Arduino Mega, STM32, the ESP32 series, and Raspberry Pi Pico W.\n\n**2. Text Section Layer:**\nIn this layer, the text is assigned a specific, compact ID.\n\n**3. GPIO Layer:**\nThis layer handles alerts and buzzer functions. It defines the operational scope; for instance, if PWM (Pulse Width Modulation) is integrated, the system generates a detailed, numerical \"hidden layer\" specifying how to produce the PWM signal, the required number of cycles, and the supported GPIO pins. This data is then fed into the Pluto Engine.\n\n**4. Main Engine:**\nThe core Pluto Engine operates through various hidden layers or sections. It employs multiple \"emotion sections\" to emulate human mechanisms—though this does not mean the engine actually possesses or retains emotions. The Pluto Engine’s architecture differs significantly from conventional models, as it is designed to mirror human cognitive mechanisms through a variety of distinct functional sections.\n\n**5. Generative Section:**\nThis section does more than just generate content; it aggregates data from various other sections to produce two distinct final outputs: the generated text and the instruction data for the hardware control section.\n\n**6. Hardware Control (Tree) Layer:**\nA visual representation of this layer is provided below. The final instructions generated by the Pluto Engine consist of three key components:\n\n**A:** This (Tree) layer begins with an address—or, depending on requirements, multiple addresses—where each address carries distinct information.\n\n**B:** Next is the \"Instruction GPIO\" section, which contains data specifying the function of each GPIO pin.\n\n**C:** FIET (Feedback Instruction Engine - Thinking): This is a critical component of this layer. There can be multiple instances of FIET. Its function is to provide feedback on how GPIO pins are being utilized (as inputs or outputs) and to notify the Pluto Engine about ongoing tasks. Furthermore, it receives instructions from the Pluto Engine and implements necessary adjustments within the Hardware Control (Tree) Layer. This process is distinct from the Pluto Engine’s initial instruction generation; it functions much like the mental deliberation a human undergoes before taking an action—the Pluto Engine performs this \"thinking\" process, and the resulting information is transmitted via FIET.\n\n*Decoding within this layer occurs internally. When the CPU is in operation, it interacts exclusively with the Hardware Control (Tree) Layer, effectively bypassing the processing stages of the Pluto Engine. The various processing layers are only activated when new instructions are received from the user, which significantly enhances the CPU's performance.*\n\nA distinct approach is employed for training the Pluto Engine. It utilizes a custom C++ architecture—centered around a \"master\" Pluto Engine—that is tailored to the specific capabilities and features of various microchips. Rather than relying on parameter- or pattern-based learning, it mimics the human learning process.\n\nDuring the model training phase, the system is trained using a variety of input-output features and their associated details. Based on this data, it automatically generates hidden layers—incorporating specific features—which are then integrated into the Pluto Engine designed for the respective microchip.\n\nImportant\n\n**Providing a brief answer as to where the Pluto Engine can be used might be a subject of debate.** While the example above shows the Pluto Engine running on an ESP32, this does not imply that it is restricted solely to microchips like the ESP32 or STM; it is, after all, written in C++.\n\nThe core strength of any model lies in its architecture. With a robust architecture, a model can be implemented across various environments—whether in C++, Python, or on a server.\n\nThe scope of the Pluto Engine extends beyond merely controlling hardware through natural language. Its primary strength lies in its unique approach to learning and internal processing. Unlike systems that rely on recognizing familiar patterns, the Pluto Engine’s learning and processing mechanisms closely mirror those of the human brain. Consequently, the logic and reasoning occurring within the Pluto Engine operate in a manner distinct from current AI paradigms.\n\nAs for its potential applications, the Pluto Engine could be installed directly onto various devices, chips, or robotic systems. This would enable robots to think and behave much like humans—without the need for an external server—potentially elevating our existing hardware technology to an entirely new level.\n\nWe conducted the following test using only the Pluto main engine. It was not physical hardware, but rather a computer simulation. The objective was to evaluate Pluto’s performance based on specific conditions and logic-driven tasks. Further details on this will be provided, including live sessions or through a real-world project.\n\n**However, I can share a few details:**\n\nIn this setup, the 'Pluto engine' manages the wheels via servo signals sent through specific pins. Its primary function is to use a front-facing sensor to detect objects; upon detecting one, it issues signals to the wheel pins according to a set of instructions. That said, there is quite a bit more going on under the hood.\n\nThe Pluto Engine is currently in the research and development phase. I am working on this project independently, without company funding or investors.\n\nAt this stage, I am not distributing the C++ source code, internal architecture, or executable files directly. However, if you would like to test the Pluto Engine yourself, I can provide an **ESP32-S3 module with the >Pluto Engine pre-installed**, shipped to your address.\n\nYou can order the hardware unit here:\n\nThe price covers the hardware and associated costs, including shipping. A portion of the proceeds will help fund my ongoing research, testing, and future development of the Pluto Engine.\n\nI am developing this project independently, and every purchase helps me continue working on it. I also welcome technical feedback and suggestions from experienced engineers and developers who are interested in evaluating the project.\n\nThank you for your interest and support.\n\nNote\n\n**Seeking Technical Feedback**\n\nI would greatly appreciate advice, suggestions, or technical feedback from experienced engineers and professionals to help improve and strengthen the Pluto Engine. Your insights would be valuable in guiding its future development and updates.\n\n🌐 **Website:** [Visit us](https://dibsoftiot.com/)\n\n💼 **LinkedIn:** [Follow LinkedIn](https://www.linkedin.com/in/nazmul-agi/)", "url": "https://wpnews.pro/news/show-hn-tinyml-ai-a-new-architecture-to-control-embedded-intelligence", "canonical_source": "https://github.com/dib-artificial/pluto-flash", "published_at": "2026-10-20 15:33:09+00:00", "updated_at": "2026-10-20 15:46:52.777410+00:00", "lang": "en", "topics": ["artificial-intelligence", "machine-learning", "natural-language-processing", "ai-tools"], "entities": ["TinyML AI", "Pluto Engine", "ESP32", "Espressif", "HC-06", "Flutter", "Nazmul", "CH340"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/show-hn-tinyml-ai-a-new-architecture-to-control-embedded-intelligence", "markdown": "https://wpnews.pro/news/show-hn-tinyml-ai-a-new-architecture-to-control-embedded-intelligence.md", "text": "https://wpnews.pro/news/show-hn-tinyml-ai-a-new-architecture-to-control-embedded-intelligence.txt", "jsonld": "https://wpnews.pro/news/show-hn-tinyml-ai-a-new-architecture-to-control-embedded-intelligence.jsonld"}}