E-waste disposable vape transformed into functional HTTP server with ARM Cortex-M0+, 24KB flash, 3KB RAM. Response times optimized from 20s down to 160ms through aggressive resource management. Built without any external libraries.
The Hardware Discovery
This discarded vape contained something incredible: a PUYA PY32F003 (Cortex-M0+) microcontroller. This tiny chip has more computing power than the computers that got us to the moon.
Hardware specs:
- MCU: ARM Cortex-M0+ @ 48MHz
- Flash: 24KB total storage
- RAM: 3KB working memory
- Peripherals: USB, GPIO, Timers, UART
- Power: 3.7V Li-ion battery (salvaged)
The question: Can this thing serve HTTP requests?
The Challenge: Everything is Too Big
First reality check hit hard. Modern web frameworks are massive:
- Express.js equivalent: ~200KB
- Standard HTTP library: ~150KB
- Basic TCP/IP stack: ~80KB
My available space: 24KB total
This wasn't going to work with conventional approaches. Time to get creative.
Solution: Extreme Minimalism
Rolling My Own HTTP Server
Everything was built from scratch:
- HTTP/1.0 only (not 1.1 or 2.0) - saves tons of complexity
- No keep-alive connections - close after each request
- Manual request parsing - no regex, just simple string operations
- Static routing table - function pointers instead of dynamic routing
The entire web server compiled to just 2KB.
Memory Management Nightmare
With only 3KB of RAM, traditional memory management goes out the window:
- No malloc/free - too expensive and fragmented
- Global buffer pool - reuse the same 1KB buffer for everything
- Stack-based allocation - careful function call depth management
- Aggressive buffer reuse - request buffer becomes response buffer
Every single byte had to be accounted for.
Storage Strategy
Without a filesystem, everything gets compiled directly into the firmware:
- Web pages as byte arrays - HTML stored as const char arrays
- Minified everything - removed whitespace, shortened variable names
- Compressed assets - manual gzip compression for larger files
- Smart asset selection - only essential resources included
Total web assets: ~4KB after compression.
The Performance Journey
Initial Attempt: Disaster
- Response time: 20,000ms 😱
- Ping latency: 1,500ms
- Memory usage: 2.8KB/3KB (93% utilization)
The ARM processor was completely overwhelmed by the networking overhead.
Optimization Round 1: Interrupt-Driven Architecture
Moved from polling-based to interrupt-driven networking:
- USB interrupts - wake up only when data arrives
- Sleep between requests - CPU goes into low-power mode
- Reduced CPU usage - from 100% to ~5%
Result: Response time dropped to 5,000ms ⬇️
Optimization Round 2: Buffer Management
Implemented aggressive buffer reuse strategies:
- Single shared buffer - one 1KB buffer for all operations
- Phased processing - parse request, generate response, send response
- Zero allocation - eliminated all dynamic memory allocation
Result: Response time improved to 1,200ms ⬇️
Optimization Round 3: Critical Path Assembly
Identified the hottest code paths and rewrote them in hand-optimized ARM assembly:
- HTTP header parsing - 4x faster than C version
- String operations - optimized for ARM Thumb instruction set
- Memory copying - vectorized operations where possible
Result: Response time down to 400ms ⬇️
Final Optimization: Response Caching
Pre-computed common HTTP responses:
- Static response headers - stored as constants
- Template responses - pre-formatted common replies
- Lookup tables - O(1) routing instead of string comparisons
Final result: 160ms average response time 🎉
Current Performance Metrics
After all optimizations:
- Response time: 160ms average
- Ping latency: 20ms
- Memory usage: 2.1KB/3KB (70%)
- Concurrent connections: 1 (it's only 3KB RAM!)
- Uptime: 72+ hours continuous operation
What It Actually Serves
Static Content:
- Minified HTML/CSS/JavaScript
- JSON API responses
- Plain text data
- Base64-encoded small images
Dynamic Features:
- System statistics (uptime, memory usage, temperature)
- Hardware sensor data (accelerometer, battery level)
- Simple form handling (GET parameters only)
- Real-time status updates
Live Endpoints:
-
/- Main dashboard with live stats -
/api/stats- JSON system information -
/api/sensors- Hardware sensor readings -
/ping- Simple health check
Technical Architecture
Layered Design:
- Hardware Abstraction - USB, GPIO, sensor interfaces
- Network Layer - Minimal TCP/IP implementation
- HTTP Server - Request parsing and response generation
- Application Layer - Routing and business logic
- Web Interface - Client-side JavaScript for interactivity
Key Design Principles:
- Zero dependencies - everything built from scratch
- Stateless operation - no session management
- Fail-fast design - quick error detection and recovery
- Resource monitoring - continuous memory and CPU tracking
Development Challenges
Memory Debugging: With only 3KB RAM, memory leaks are catastrophic. Had to build custom debugging tools to track every byte allocation.
Performance Profiling: Standard profilers don't work on embedded systems. Created custom timing measurements using hardware timers.
Testing Constraints: Can't run automated tests on the device itself. Had to build a simulation environment for development.
Optimization Balance: Every optimization has tradeoffs. Making HTTP parsing faster might use more memory, etc.
Real-World Usage
This tiny server has been running continuously for weeks now, serving:
- Personal dashboard - system monitoring for my home lab
- IoT data collector - sensors report to it via simple HTTP POST
- Development API - rapid prototyping endpoint for other projects
- Educational demo - showing visitors what's possible with constraints
Lessons Learned
Constraints Breed Creativity: Limited resources forced innovative solutions I never would have discovered otherwise.
Profile Everything: 90% of performance problems came from 10% of the code. Measurement is essential.
Assembly Still Matters: For critical paths, hand-optimized assembly provided significant gains.
Memory > CPU: In embedded systems, memory is usually the limiting factor, not processing power.
Simple Protocols Win: HTTP/1.0 is perfectly adequate for most use cases and much simpler to implement.
Environmental Impact
This project highlights a serious issue: disposable vapes contain sophisticated electronics that get thrown away after days of use. Each device contains:
- ARM microcontroller
- Lithium battery
- Various sensors
- USB circuitry
- Rare earth elements
Millions are discarded daily, representing massive waste of functional computing resources.
What's Next
Phase 2 Goals:
- Multi-device clustering - network of vape servers working together
- WiFi integration - wireless connectivity via ESP32 module
- Persistent storage - EEPROM-based key-value database
- Basic security - authentication if memory constraints allow
Community Project:
Planning to open-source the entire project with step-by-step tutorials for others to build similar systems from e-waste.
Try It Yourself
Requirements:
- Any ARM Cortex-M0+ development board (don't actually use vapes!)
- USB connection capability
- Basic electronics knowledge
- C programming experience
- Patience for embedded debugging
Skills You'll Learn:
- Embedded HTTP server development
- Memory-constrained programming
- Hardware abstraction layers
- Performance optimization techniques
- Assembly language integration
The Bigger Picture
This isn't really about vapes or web servers. It's about recognizing that we live surrounded by incredible computing power that often goes unrecognized. Every "smart" device, every IoT gadget, every piece of modern electronics contains capabilities that would have been considered supercomputers just decades ago.
The real challenge isn't building powerful systems - it's building elegant, efficient systems that do more with less.
Community Response
Since sharing this project:
- GitHub stars: 2.3k and climbing
- Dev community: Amazing feedback and suggestions
- Hardware hackers: Several people building their own versions
- Environmental groups: Interest in e-waste upcycling applications
What's the most resource-constrained system you've ever developed on? Share your extreme embedded stories below 👇
Top comments (0)