Show HN: TinyML AI – A New Architecture to Control Embedded Intelligence

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.

TinyML AI - Pluto Engine : A natural language model designed for general intelligence that can directly control microchips. Important This is an entirely different AI model. It does not utilize any third-party APIs or models. It features a unique architecture Pluto Engine that differs from conventional pattern-based models. Note To provide a detailed explanation of how our new model functions and its internal structure, the entire presentation has been divided into 4 sections: 01 — Overview An overview of how TinyML AI the Pluto Engine operates within a microchip, including further details. 02 — Engine Functionality A discussion on how the Pluto Engine functions. 03 — Training & Limitations How the Pluto Engine is trained, and the limitations of its capabilities when running on a microchip. 04 — Applications & Industries Potential applications and sectors where the Pluto Engine can be utilized. 01 — Overview This section provides a detailed walkthrough, including experiments using an ESP32 device. Note My 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/ Warning Bluetooth Configuration and Flash Memory Optimization If 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. This 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. The HC-06 communicates with the ESP32 through UART2 using the following configuration: define RX2 PIN 16 define TX2 PIN 17 Serial.begin 115200 ; Serial2.begin 9600, SERIAL 8N1, RX2 PIN, TX2 PIN ; Code explanation: - RX2 PIN 16 : ESP32 GPIO 16 receives serial data. - TX2 PIN 17 : ESP32 GPIO 17 transmits serial data. - Serial.begin 115200 : Initializes the USB serial interface for debugging. - Serial2.begin 9600, SERIAL 8N1, RX2 PIN, TX2 PIN : Initializes UART2 at 9600 baud with 8 data bits, no parity, and 1 stop bit. Note: These are UART pin definitions and serial initialization settings, not timer configurations. A 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. The application performs three primary functions: 1. Bengali-to-English Translation: Bengali or another language is taken as input, and then that text is converted into English via the internet. 2. Transmission: The translated text is then sent to the HC-06 module from the phone via Bluetooth. Pluto Engine supports only the English language. 3. Text Reception: The text generated via feedback from the system Pluto Engine is received in the Flutter app through an HC-06 Bluetooth module. The Bluetooth connection between the phone and the ESP32 does not itself require an internet connection. However, the translation feature requires internet access. The source code for the Flutter application has been uploaded to this repository for review, allowing developers to examine and verify the code. TinyML engine Pluto runs on an ESP32 development board featuring a CH340 USB-to-UART interface and USB Type-C connector. | Specification | Details | |---|---| | Development Board | ESP32 Dev Board | | USB Interface | USB Type-C | | USB-to-UART Bridge | CH340 | | Microcontroller Family | Espressif ESP32 | | CPU Architecture | Xtensa LX6 | | CPU Cores | Dual-core 2 cores | | Maximum CPU Frequency | Up to 240 MHz | | Internal SRAM | 520 KB chip-level specification | | ROM | 448 KB chip-level specification | | Flash Storage | 4 MByte 32Mbit | | Wi-Fi | 2.4 GHz, IEEE 802.11 b/g/n | | Bluetooth | Bluetooth Classic and BLE original ESP32 | | GPIO | Up to 34 GPIOs on the original ESP32 chip; board availability varies | | ADC | 12-bit SAR ADC | | DAC | 2 × 8-bit DAC original ESP32 | | PWM | LED PWM controller, up to 16 channels | | General-Purpose Hardware Timers | 4 original ESP32 | | High-Resolution Software Timer API | esp timer , 1 µs time resolution | | Communication Interfaces | UART, SPI, I²C, I²S | | Programming Platforms | Arduino IDE, ESP-IDF | | USB Programming | CH340 USB-to-UART bridge | The current TinyML AI device Pluto Engine includes the following features, though some are limited. - GPIO — Digital HIGH / LOW input and output - PWM — Variable duty-cycle control for LEDs, motors, and other devices - I²C — Communication with sensors, displays, memory, and peripheral devices - SPI — High-speed communication with compatible peripherals Limited - Servo — Position control and movement sequences - Analog I/O — Reading analog sensors and generating hardware responses - Timers / Frequency — Hardware timing, pulse and frequency generation - Sensors — Processing sensor data and using it in conditional decisions The Pluto firmware is evaluated in three configurations: the Hardware Control Layer, the Pluto TinyML Engine, and the complete integrated firmware. | Memory / File Type | Total Capacity | Used | Usage % | Remaining | |---|---|---|---|---| | Hardware Control Layer — Flash | 1,310,720 bytes 1.25 MiB | 378,948 bytes ≈ 370.1 KiB | 28% | 931,772 bytes | | Hardware Control Layer — RAM | 327,680 bytes 320 KiB | 31,100 bytes ≈ 30.4 KiB | 9% | 296,580 bytes | | Pluto TinyML Engine — Flash | 1,310,720 bytes 1.25 MiB | 806,788 bytes ≈ 787.9 KiB | 61% | 503,932 bytes | | Pluto TinyML Engine — RAM | 327,680 bytes 320 KiB | 69,564 bytes ≈ 67.9 KiB | 21% | 258,116 bytes | | Complete Firmware — Flash | 1,310,720 bytes 1.25 MiB | 1,174,724 bytes ≈ 1.12 MiB | 89% | 135,996 bytes | | Complete Firmware — RAM | 327,680 bytes 320 KiB | 100,380 bytes ≈ 98.0 KiB | 30% | 227,300 bytes | | pluto ML AI.ino.bin — Firmware Binary | — | 1,148 KB reported | — | — | Sketch uses 378948 bytes 28% of program storage space. Maximum is 1310720 bytes. Global variables use 31100 bytes 9% of dynamic memory, leaving 296580 bytes for local variables. Maximum is 327680 bytes. The Hardware Control Layer manages hardware-facing functions such as Bluetooth communication, GPIO, I²C SDA/SCL , and other supported peripheral operations. Sketch uses 806788 bytes 61% of program storage space. Maximum is 1310720 bytes. Global variables use 69564 bytes 21% of dynamic memory, leaving 258116 bytes for local variables. Maximum is 327680 bytes. The Pluto TinyML Engine provides the core instruction-processing functionality. Its reported memory usage represents the engine configuration tested in this build. Sketch uses 1174724 bytes 89% of program storage space. Maximum is 1310720 bytes. Global variables use 100380 bytes 30% of dynamic memory, leaving 227300 bytes for local variables. Maximum is 327680 bytes. pluto ML AI.ino.bin = 1148 KB This build report represents the integrated firmware containing the hardware control layer and Pluto TinyML Engine. Warning Memory Measurements and Build Configuration The memory information provided above was obtained by compiling the hardware control layer, the Pluto TinyML engine, and the complete firmware under various configurations. Pluto's overall memory footprint depends on: 1. Microcontroller capabilities: Available Flash, RAM, CPU architecture, and processing capacity. 2. Hardware control functions: The number and type of supported functions, including Bluetooth, GPIO, I²C, and other peripherals. 3. 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. All reported values are specific to the tested ESP32 hardware and build configurations. This benchmark compares a conventional ESP32 I²C address scan with Pluto processing a natural-language instruction to identify connected I²C sensors. Check how many sensors are connected to I2C SDA GPIO 21 and GPIO 22 SDA - SCL Pluto's response: One address is found here 0x76 The detected I²C address was 0x76 . | Metric | ESP32 Pure I²C Scan | Pluto Engine | |---|---|---| | Execution scope | Direct I²C address scanning | Natural-language processing and task execution | | SDA pin | GPIO 21 | GPIO 21 | | SCL pin | GPIO 22 | GPIO 22 | | I²C clock | 100 kHz | 100 kHz | | Addresses checked | 1–126 | Determined by Pluto's implementation | | Devices detected | 1 | 1 address reported | | Average execution time | ~18.801 ms | ~110.133 ms | | Relative execution time | 1× | ~5.86× | An average value is presented here for the ESP32; during testing, the same command was checked 50 to 100 times. In this context, the ESP32 I²C scanner directly checks the addresses of connected devices or sensors to determine which ones are responding. An 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. Naturally, 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. The following code measures the elapsed time of each Pluto function call over 50 iterations. for int i = 0; i < 50; i++ { int64 t startTime = esp timer get time ; pluto "Check how many sensors are connected to I2C SDA GPIO 21 and GPIO 22 SDA - SCL " ; int64 t endTime = esp timer get time ; int64 t elapsedUs = endTime - startTime; Serial.printf "Test %03d | %lld us | %.3f ms\n", i, long long elapsedUs, elapsedUs / 1000.0 ; } The measured time shown here begins before the main function is called and ends only after the main function has finished its execution. This 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. 1. Different benchmark scopes A 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. 2. Results depend on configuration Execution 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. 3. RAM usage is not reported in this benchmark This 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. Assessing memory usage would require a separate memory benchmark. Such metrics should be measured and reported independently of execution time. 4. Results are specific to the tested configuration The 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. In 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. This 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. It’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. 1. Sentence Filter Layer: The 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. The Pluto Engine has been implemented on platforms including Arduino Mega, STM32, the ESP32 series, and Raspberry Pi Pico W. 2. Text Section Layer: In this layer, the text is assigned a specific, compact ID. 3. GPIO Layer: This 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. 4. Main Engine: The 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. 5. Generative Section: This 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. 6. Hardware Control Tree Layer: A visual representation of this layer is provided below. The final instructions generated by the Pluto Engine consist of three key components: A: This Tree layer begins with an address—or, depending on requirements, multiple addresses—where each address carries distinct information. B: Next is the "Instruction GPIO" section, which contains data specifying the function of each GPIO pin. 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. 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. A 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. During 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. Important 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++. The 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. The 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. As 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. We 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. However, I can share a few details: In 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. The Pluto Engine is currently in the research and development phase. I am working on this project independently, without company funding or investors. At 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. You can order the hardware unit here: The 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. I 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. Thank you for your interest and support. Note Seeking Technical Feedback I 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. 🌐 Website: Visit us https://dibsoftiot.com/ 💼 LinkedIn: Follow LinkedIn https://www.linkedin.com/in/nazmul-agi/