TL;DR

Maurycy vừa phát hành một bộ font bitmap 5×5 pixel chứa đủ ASCII in hoa + in thường, chỉ nặng 350 byte cho toàn bộ font. Mục tiêu: chạy text đọc được trên vi điều khiển 8-bit như AVR128DA28 (16 kB RAM) với màn OLED 128×64 hoặc 160×128. Dự án kèm biến thể 3×53×2 cho các case siêu hẹp, cộng một mẹo subpixel rendering khai thác sọc RGB của LCD để biến mỗi glyph thành 1×5 pixel hiệu dụng. So với font vector kèm rasterizer cần cả MB code và MB data, 350 byte là chênh lệch 4–5 bậc độ lớn.

Có gì mới

Điểm mới không phải là ý tưởng font bitmap tí hon — Tom Thumb 4×6 hay font 5×7 trên HD44780 đã sống hàng chục năm. Cái mới là kỷ luật thiết kế: Maurycy vẽ tay từng glyph với ràng buộc cell 6×6 chứa glyph 5×5, tức mỗi ký tự tự mang sẵn 1 pixel kerning, không cần bảng khoảng cách phụ. Vì vậy render engine chỉ là một vòng lặp bit-blit ngắn gọn, không thư viện đồ hoạ nào.

Tác giả cũng công khai lý do không làm 4×4: không đủ pixel để phân biệt E, M, W — ba chữ có kết cấu ngang phức tạp nhất. 5×5 là cận dưới thực tế để giữ được toàn bộ bảng chữ cái Latin không dấu.

Vì sao quan trọng

Trên một con AVR128DA28, bạn có 16 kB RAM — tức một framebuffer 384×288 (~110 nghìn pixel, ~14 kB ở 1 bit/pixel) đã gần như ăn hết bộ nhớ. Chọn màn 128×64 hoặc 160×128 là cách duy nhất giữ lại headroom cho logic ứng dụng. Nhưng màn nhỏ thì font phải nhỏ, và font 32×32 vector nhét vào flash 64–128 kB là không khả thi.

350 byte là con số có nghĩa: nó vừa vặn nằm lọt trong một section .rodata, không đụng đến RAM, và để lại vài chục kB flash cho phần còn lại của firmware. Với dev hobbyist và team sản phẩm thương mại chi phí thấp (sensor node, smartwatch, dashboard e-ink), đây là đường giữa hiếm hoi giữa "1 byte/chữ" sơ khai và "1 MB font stack" hiện đại.

Facts kỹ thuật

  • Kích thước tổng: 350 byte cho toàn bộ ASCII in được (~96 glyph).
  • Glyph/cell: 5×5 pixel trên cell 6×6 để có sẵn spacing.
  • Biến thể: 3×2 (cực hẹp, một số glyph đụng nhau như c/o), 3×5 (M/W/Q kém), 4×5 phong cách Tom Thumb, 5×5 bản chính.
  • Phần cứng đích: AVR128DA28 (8-bit, 16 kB RAM) + OLED SSD1306 128×64 hoặc ST7735 160×128.
  • Trick subpixel: dùng sọc R/G/B của LCD làm 3 cột con, ra font 1×5 hiệu dụng — kèm hiệu ứng pseudo-dropshadow "free".
  • License: CC BY-NC-SA (phi thương mại, share-alike).

So sánh

FontCellPixel/glyphGhi chú
Maurycy 5×56×625350 B tổng, full ASCII, có subpixel mode
Tom Thumb 4×64×624Font tí hon kinh điển, MIT license
3×5 variant3×515M, W, Q bắt đầu khó đọc
3×2 variant3×26Một số glyph gần như đụng nhau
HD44780 5×75×735Chuẩn LCD ký tự, dễ đọc hơn
Vector TTF + rasterizerMB code + MB data, không khả thi trên AVR

Điểm đáng chú ý: 5×5 dùng thêm đúng 1 pixel/glyph so với Tom Thumb 4×6 nhưng cho chữ hoa rõ hơn hẳn — đặc biệt là MW.

Use cases

  • Dự án AVR/ATtiny hobby đẩy text lên OLED 0.96" hoặc 1.3".
  • Thiết bị chạy pin: smartwatch DIY, data logger môi trường, sensor node LoRa.
  • E-paper dashboard: màn 2.9"/4.2" cần nhiều dòng text ngắn, không tận dụng subpixel nhưng hưởng lợi từ kích thước.
  • LED matrix signage: panel 64×32 hoặc 128×32 — 5 pixel cao cho tối đa số dòng.
  • Retro / demo scene: hợp thẩm mỹ 8-bit, terminal cổ.

Limitations & pricing

Miễn phí nhưng license CC BY-NC-SA cấm thương mại — điểm này bị cộng đồng HN phản biện khá nhiều vì không gian thiết kế ở resolution này vốn rất chật, khó có bản permissive thay thế. Về mặt glyph:

  • Chữ g thường hơi khó đọc.
  • t thường gần giống T hoa.
  • Dấu phụ (tiếng Việt, Tây Ban Nha, Pháp) gần như không vẽ được ở 5×5 — đây là rào cản lớn cho người làm tool i18n.
  • Mẹo subpixel chỉ hoạt động đúng trên LCD sọc RGB có hướng xác định; trên e-ink hoặc panel khác nó xuống thành 5×5 bình thường.

What's next

Cộng đồng trên Hacker News đang đòi thêm coverage dấu phụ, một biến thể 6×7 vẫn nhỏ nhưng đủ chỗ cho accent, và khả năng tác giả đổi sang license permissive hơn. Tác giả chưa phản hồi chính thức. Nếu bạn làm firmware embedded, đây là lúc fork sớm và thử trên dự án thật.

Nguồn: maurycyz.com, thảo luận Hacker News, Tom Thumb 4×6.