diff options
Diffstat (limited to '_projects')
| -rw-r--r-- | _projects/bumblebee.md | 17 | ||||
| -rw-r--r-- | _projects/e-reader.md | 58 | ||||
| -rw-r--r-- | _projects/fpm-door-lock.md | 10 |
3 files changed, 45 insertions, 40 deletions
diff --git a/_projects/bumblebee.md b/_projects/bumblebee.md index a114140..b322969 100644 --- a/_projects/bumblebee.md +++ b/_projects/bumblebee.md @@ -37,15 +37,16 @@ src="https://github.com/desjarlais/Scintilla.NET" class="external" target="_blank" rel="noopener noreferrer">Scintilla.NET</a> editor), debounce events, and block hidden elements and scripts. -Before settling on a desktop application, we contemplated a browser extension. -We decided against that because we didn't want the browser vendor to dictate -Bumblebee's capabilities. Furthermore, the company's security policy prohibited -browser extensions, complicating its deployment. The initial prototype used a -C# wrapper of the Chromium project instead of WebView. WebView's more intuitive +Before settling on a desktop application, we contemplated designing Bumblebee +as a browser extension. We decided against that because we didn't want the +browser vendors to dictate Bumblebee's capabilities. Besides, the company's +security policy, which prohibited browser extensions, would have complicated +the deployment of an extension-based solution. The initial prototype used a C# +wrapper of the Chromium project instead of WebView. WebView's more intuitive API and its seamless integration with Windows Forms led us to choose it over the Chromium wrapper. -Bumblebee reduced the time we spent on authoring scripts from hours to a few -minutes. Since the rules for code generation were written and optimized by -experts in web technologies, the output was more robust. +Bumblebee predictably reduced the time we spent on authoring scripts from hours +to a few minutes. Since the code generation rules were written and optimized by +experts in web technologies, the quality of the scripts improved as well. diff --git a/_projects/e-reader.md b/_projects/e-reader.md index 1a0892e..3405cc8 100644 --- a/_projects/e-reader.md +++ b/_projects/e-reader.md @@ -1,14 +1,14 @@ --- -title: Prototype e-reader +title: Experimental e-reader date: 2023-10-24 thumbnail: thumb.png layout: post --- -This project features a prototype e-reader powered by an ESP-WROOM-32 -development board and a 7.5-inch <a href="https://www.waveshare.com/" -class="external" target="_blank" rel="noopener noreferrer">Waveshare</a> -e-paper display. +This project features a minimal e-reader powered by an ESP-WROOM-32 development +board and a 7.5-inch <a href="https://www.waveshare.com/" class="external" +target="_blank" rel="noopener noreferrer">Waveshare</a> e-paper display built +with the intention of learning about e-paper displays. <video style="max-width:100%;" controls="" poster="thumb.png"> <source src="ereader.mp4" type="video/mp4"> @@ -29,13 +29,13 @@ minimize power consumption when not in use and records the reading progress in the chip's RTC memory. The most formidable challenge when trying to build an e-reader with an ESP32 -board is its limited memory and storage. My ESP-WROOM-32 board has 512 KB of -SRAM and 4 MB of flash memory, which the freeRTOS, ESP-IDF, and the e-reader +board is its limited memory and storage. My ESP-WROOM-32 board has 512KB of +SRAM and 4MB of flash memory, which the freeRTOS, ESP-IDF, and the e-reader application must share. To put things into perspective, a Kindle Paperwhite has -at least 256 MB of memory and 8 GB of storage. +at least 256MB of memory and 8GB of storage. Despite its size, as microcontrollers go, ESP32 is a powerful system-on-a-chip -with a 160 MHz dual-core processor and integrated WiFi. So, I thought it’d be +with a 160MHz dual-core processor and integrated WiFi. So, I thought it’d be amusing to embrace the constraints and build my e-reader using a $5 MCU and the power of C programming. @@ -48,7 +48,7 @@ monochrome image of a page (a .ebm file). The EBM file contains a series of bitmaps, one for each page of the book. The dimensions of each bitmap are equal to the size of the display. Each byte of the bitmap encodes information for rendering eight pixels. For my display, -which has a resolution of 480x800, the bitmaps are laid out along 48 KB +which has a resolution of 480x800, the bitmaps are laid out along 48KB boundaries. This simple file format lends well to HTTP streaming, which is its main advantage, as we will soon see. @@ -57,20 +57,20 @@ PDF documents to EBM files. ## How does it work? -As the e-reader has no storage, it can't store books locally. Instead, I first -have to upload the EBM file I want to read to a web server. The `EBM_ARCH_URL` -setting in the Kconfig.projbuild file points to the URL of the file. To read a -different book, I create an EBM file with the same name and upload it to the -original location. That way, I don't have to modify the `EBM_ARCH_URL` value, -which requires recompiling the embedded software. +As the e-reader has no storage, it can't store books locally. Instead, it +downloads pages of the EBM file over HTTP from the location pointed to by the +`EBM_ARCH_URL` setting in the Kconfig.projbuild file on demand. To read a +different book, we have to replace the old file with the new one or change the +`EBM_ARCH_URL` value. The latter requires us to recompile the embedded +software. Upon powering up, the e-reader checks the reading progress stored in the RTC memory. It then downloads three pages (current, previous, and next) to a -circular buffer in DMA-capable memory. When the user turns a page, one of the -microprocessor's two cores transfers it from the buffer to the display over a -Serial Peripheral Interface (SPI). The other downloads a new page in the -background. I use the ESP-IDF task API to distribute the two tasks between the -available cores for maximum parallelism. +circular buffer in DMA-capable memory. When the user turns a page by pressing a +button, one of the microprocessor's two cores transfers it from the buffer to +the display over a Serial Peripheral Interface (SPI). The other downloads a new +page in the background. I used the ESP-IDF's task API to distribute the two +tasks between the available cores to make the reader more responsive. I designed the EBM format with HTTP streaming in mind. Since the pages are laid out in the EBM file along predictable boundaries, the e-reader can request @@ -80,11 +80,15 @@ web server will process this request without custom logic. ## Reflections It's been six years since the car park and the displays. I began this project -hoping to learn the low-level workings of e-paper displays. As a bonus, it led -me to explore some of ESP32's most fascinating features: sleep modes, multicore -processing, DMA, and RTC memory. Embedded systems are magical things: invisible -particles swirl into form as the programmer whispers C. - - +hoping to learn more about e-paper displays, and I got that and more. By +working within the constraints of the ESP32, I forced myself to explore some of +its advanced features: sleep modes, multicore task scheduling, DMA transfers, +and RTC memory. + +As for the prototype, while it's no match for a commercial e-reader with +features like an offline library of books and touch screens, there's something +to be said about reading on hardware you built yourself. You are no longer the +powerless Muggle watching others perform magic. You are the wizard who makes +the invisible particles swirl into form by whispering C to it. Files: [source.tar.gz](source.tar.gz) diff --git a/_projects/fpm-door-lock.md b/_projects/fpm-door-lock.md index a94b9e0..b2a0165 100644 --- a/_projects/fpm-door-lock.md +++ b/_projects/fpm-door-lock.md @@ -14,11 +14,11 @@ microcontroller. ## Overview -The lock comprises three subsystems: the ATmega328P, an R503 fingerprint -sensor, and an FS5106B high-torque servo. The sensor mounted on the front -surface of the door enables users to unlock it from the outside. The servo is -attached to the interior door knob. The MCU must be installed at the back of -the door to prevent unauthorized users from tampering with it. +The lock comprises three subsystems: the ATmega328P microcontroller, an R503 +fingerprint sensor, and an FS5106B high-torque servo. The sensor mounted on the +front surface of the door enables users to unlock it from the outside. The +servo is attached to the interior door knob. The MCU must be installed at the +back of the door to prevent unauthorized users from tampering with it. When no one is interacting with the lock, the MCU is in deep sleep. The sensor and the servo each draw 13.8mA and 4.6mA of quiescent currents. To prevent this |