TL;DR

  • Muse.ai를 메모리 321KB뿐인 Xteink X3에 연결해 우선순위, 운동, 메모 등 flowe-os 기능을 전자책 리더에서 확인하고 조작하는 프로토타입을 구현함.
  • ESP32-C3의 메모리 제약으로 세션 초기화가 반복 실패해, 속도 최적화용 램에 배치되는 와이파이·블루투스 코드를 다른 메모리 풀로 옮김.
  • 792×528 흑백 화면을 52KB 단일 버퍼에 직접 렌더링하고, 이미지 수신 중 디더링해 추가 복사본을 없앰.
  • 디스플레이 컨트롤러에 마지막 화면을 유지해 페이지 전환을 플래시 없이 650ms에 처리함.
  • FreeInk SDK의 화면 구동 시퀀스와 전압 표를 활용했으며, 코드와 단계별 안내를 저장소에 제공함.

Muse Gadget: 얼마나 휴대성을 높일 수 있을까?

Xteink X3의 Muse.ai

  • 작고 휴대하기 좋은 Xteink X3를 인공지능(AI) 설정에 연결해 보려 했으며, 처음에는 재미로 시작함.
  • 2주 뒤 추가할 수 있는 것이 거의 없다는 점을 깨닫고, Crosspoint에서 시작해 flowe-os로 옮겼지만 결과에 다소 실망함.
  • 이후 Muse Gadget SDK를 발견하고 프로토타입을 만들기 시작함. 소프트웨어 개발 키트(SDK)는 ESP32 보드를 지원한다고 안내하지만, Xteink X3는 더 작은 버전의 보드를 사용함.
  • 코드를 불러와 조정한 뒤 몇 시간 만에 프로토타입을 완성함.

구현한 기능

  • 기본적인 전자종이(e-paper) 디스플레이 기능을 홈 와이파이에 연결함.
  • 우선순위, 운동, 메모 등 flowe-os의 기능을 확인할 수 있음.
  • 기기의 작은 버튼으로 탭 사이를 이동하고 각 항목을 살펴보며 완료 또는 취소 상태를 선택할 수 있음.

ESP32-C3의 메모리 문제

  • Xteink X3는 총 321KB 램(RAM)을 탑재한 ESP32-C3 기반 기기이며, 추가 메모리 칩은 없음.
  • SDK에서 실제 화면을 갖춘 보드는 모두 8MB의 추가 램을 탑재함. SDK 자체 전자종이 코드는 이미지 한 장을 위해서만 384KB를 요구함.
  • 첫 빌드는 소스 코드를 바꾸지 않고도 작동했지만, Muse 세션 연결 상태에서 남은 메모리는 59KB, 가장 큰 연속 여유 메모리 블록은 11KB였음.
  • 로그에는 세션이 메모리 할당에 네 차례 실패한 뒤 다섯 번째 시도에서 성공한 기록이 나타남.
  • 속도를 위해 램에 배치되는 코드를 다른 항목과 같은 메모리 풀에서 가져오도록 수정함. SDK 기본 설정은 와이파이·블루투스 코드 약 90KB를 해당 영역에 배치하지만, 정지 화면을 표시하는 기기에는 빠른 와이파이가 필요하지 않음.

52KB에서 화면 렌더링

  • 메모리를 확보한 뒤에도 화면을 52KB 안에서 렌더링해야 함. X3 패널은 792×528픽셀 흑백이며, 픽셀당 1비트 기준으로 화면 크기는 52KB임.
  • 하나의 버퍼에 직접 그리며, 이미지가 들어오는 동안 디더링해 두 번째 복사본을 만들지 않음.
  • 다음 문제는 페이지 전환이었음. 전자책 리더용으로 설계된 디스플레이 컨트롤러는 절전 상태로 전환하지 않으면 마지막 이미지를 자체 메모리에 유지함.
  • 펌웨어는 디스플레이를 깨어 있는 상태로 두며, 플래시 메모리 없이 페이지 전환에 650ms가 걸림.

다음 단계

  • Muse가 렌더링할 수 있는 항목과 없는 항목을 완전히 제어하므로, Muse에 추가하는 콘텐츠를 조정해 나중에 오프라인에서 볼 화면으로 구성할 수 있음.
  • 책을 다시 기기에 넣거나 인공지능 요약을 불러오는 방안도 검토 중임.

크레딧

  • 화면 구동 시퀀스와 전압 표는 이 기기를 역공학한 CrossPoint Reader 커뮤니티가 만든 FreeInk SDK에서 가져옴. 이 자료가 없었다면 화면에 이미지를 표시하지 못했을 것임.
  • X3 사용자는 저장소에서 코드와 단계별 안내를 확인할 수 있음.
  • 다른 ESP32-C3 보드에서도 메모리 관련 설정 일곱 줄이 작동할 수 있음.