Fix unit gaps in e-reader.term

1 files changed, 5 insertions, 5 deletions

diff --git a/_projects/e-reader.md b/_projects/e-reader.md
index dcafca0..3405cc8 100644
--- a/_projects/e-reader.md
+++ b/_projects/e-reader.md
@@ -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.