Category (Click)
개발보드 덕질하기

[Beepy Likely] 2. 키보드&마우스 제어 방식 확립, LCD 켜보기

 차완기 - @7/13/2024, 12:17:00 AM
Beepy Likely 프로젝트
작고, 키보드 달렸고, 느리고, 그런데 리눅스가 돌아가는!!! 오픈소스 포터블 리눅스 머신인 Beepy를 레퍼런스로 삼아, 나만의 포터블 리눅스 머신을 만드는 프로젝트입니다.
#HW #PCB Design #FW #Pico SDK #RTOS #TinyUSB #HID #u8g2 #LCD #terminal emulation
지난 포스팅에서 선정한 두 부품이 도착했습니다. Adafruit 향 디스플레이는 국내에서 구매했다가 배송 지연당하고 해외구매했습니다 ㅋㅋ.. 또 속냐!!!
아무튼 큼직큼직한 부품이 도착했으니 이제 뭔가를 시작할 수 있겠네요!

SBC, MCU 역할 구상

포터블 리눅스 머신이니 OS가 돌아갈 무언가가 필요하겠죠.
RPi 5 같은 커다란 SBC를 박으면 딱이겠지만, 그랬다가는 무게도 무게이지만 무엇보다 보기가 흉할 겁니다. 그렇다고 CM4를 사용하기에는 다른 SBC로 교체하기가 힘들 것 같았습니다.
Raspberry Pi - Raspberry Pi Zero 2 W [링크]
radxa -Radxa ZERO 3W [링크]
Beepy 1승이네요. 원본 프로젝트와 동일한 RPi Zero 폼팩터를 사용하기로 했습니다. Raspberry Pi의 Zero 시리즈 이외에도 radxa나 Orange Pi 등 다양한 SBC 제조사에서 Zero 폼팩터를 만들고 있어 질리면 다른 SBC로 바꿔가며 사용할 수 있어 보입니다. RISC-V 개발 보드를 달면..! 먹음직스럽겠네요
Raspberry Pi - Raspberry Pi hardware [링크]
이러한 SBC들은 대부분 GPIO를 지원하고 있어 간단한 LED부터 I2C나 SPI 인터페이스를 사용하는 모듈류까지 활용할 수 있습니다. SBC의 강력한 성능을 바탕으로 블랙베리 키보드나 단색 디스플레이 정도는 정말 쉽게 제어할 수 있죠. 문제는 이렇게 하드웨어를 제어하면 SBC를 자유롭게 바꾸기 어려워진다는 것입니다.
개인적으로 원본 프로젝트인 Beepy에서 불만족스러웠던 것이 바로 이 하드웨어 제어 방식이었습니다.
일반적으로 SBC를 사용할 때에는 HDMI, USB처럼 범용적인 방식으로 디스플레이와 입력장치를 연결하거나 UART 인터페이스를 사용하는 시리얼 터미널을 이용합니다.
SQFMI - Beepy Schematic 중 일부 [링크]
반면, Beepy에서는 디스플레이의 경우 GPIO의 SPI에, 키보드는 MCU를 거치기는 하지만 I2C로 연결됩니다. 그리고 그 두 장치는 Linux 커널 드라이버를 통해 OS에 직접적으로 연결됩니다.
운이 좋아 누군가가 드라이버를 빌드 해두었다면 그걸 설치하면 되겠지만, RISC-V처럼 듣도 보도 못한 환경이라면 직접 드라이버를 빌드 해야 할 수도 있습니다.
드라이버가 없으면 어떻게 되나고요? 당연히 먹통이죠 ㅋㅋ 모니터&키보드 꽂아야 합니다.
이대로는 안됩니다. 불편한 건 오히려 좋지만(?) 이건 그런 불편함이 아니라 조잡함입니다.
뭔가 방법을 찾아야 했는데요, 대부분의 SBC에서 지원하는 시리얼 터미널을 활용해 보기로 했습니다.
에이 UART 받아다가 화면에 뿌리면 되겠지 ㅋ
그리고 그건 엄청난 착각이었습니다..

Pico SDK 개발 환경 구성

IoT를 주로 다루다 보니 RF를 지원하는 ESP32나 nRF52를 주로 사용하는 편입니다. 하지만 이번 프로젝트에서는 MCU에 무선 기능이 있을 이유가 없죠. 아직 맛을 보지 못한 MCU가 뭐가 있을까 하다가 Raspberry Pi의 RP2040을 사용하기로 했습니다. 원본인 Beepy도 이걸 사용하죠. Beepy 2승
이참에 RP2040의 공식 개발 환경인 Pico SDK를 사용해 보기로 했습니다.
Raspberry Pi의 공식 디버거인 Raspberry Pi Debug Probe입니다.
SWD를 사용하지만, ST-LINK나 J-Link에서 보던 Cortex Debug 커넥터와는 다른 JST 커넥터를 사용하는 것을 확인할 수 있습니다. H 타입 RPi Pico를 사용하니 디버깅 커넥터가 있어 딱이더라고요.
마침 VSCode의 Extension이 베타 버전으로 출시되어 있어, 이걸 활용해 개발 환경을 구성했습니다.
nRF Connect SDK도 그렇고 요즘 VSCode로 슥삭하는 개발 환경이 많이 너무 편리한 것 같습니다.
개발 환경 설정하겠다고 춤을 췄던 기억이 있는데.. 아무튼 아직 이건 베타 버전이다 보니 추가될 기능이 남아 있어, 나중에 정식 출시된다면 관련 포스팅 남겨보겠습니다

LCD 사기당했..나..?

FreeRTOS 올리고, 펌웨어 계층 쌓아 올리고, 우선 LCD부터 켜보기로 했습니다.
원래는 누군가가 만들어둔 LS027B7DH01 라이브러리를 직접 뜯어보며 이해해 보려 했다가, 너무나도 갈 길이 멀어 보여 u8g2 라이브러리를 사용하기로 했습니다. 언젠가 시간이 되면 꼭 직접 구현해 보고 싶네요.
u8g2 Wiki 중 일부 (MCR → MCU 오타로 보임) [링크]
보통 u8g2라 하면 아두이노를 많이 떠올릴 텐데요, 아두이노를 위한 C++ 구현도 있지만, 다른 MCU에 포팅이 가능한 구현체도 제공합니다.
u8g2 핸들러를 init 하는 u8g2_Setup_ls027b7dh01_400x240_f() 함수에 (1)SPI 데이터 전송을 추상화하는 함수와 (2)GPIO와 delay를 추상화하는 함수를 넘겨주는 것이죠.
각각의 함수는 이런 식으로 u8g2에서 디스플레이 제어를 위해 요구하는 기능을 담게 됩니다.
테스트를 위해 간단한 기능 몇 가지를 구현하고 글씨를 띄워보았습니다.
???
콘솔 출력에 사용할 6x10 폰트를 사용했더니.. 눈에 잘 보이지가 않습니다 ㅜㅜ..
혹시나 싶어 프레임도 측정해 봤는데..
5초에 28프레임이면..5.6fps???? 어억 이건 뭔가 잘못된 것 같습니다 ㅋㅋㅋ
사실 앞에서 잠시 언급했던 Pico SDK 전용 라이브러리를 테스트했을 때에는 최대 60fps로 작동해 u8g2가 많이 느린 게 아닌가 싶습니다. (확인해 보니 u8g2의 텍스트 그리는 속도가 느린 것 같습니다. 변경된 라인만 렌더링하도록 리팩토링할 예정입니다.)
언젠가 시간이 되면 고치기로 하죠..

마무리

분명 저는 오른쪽의 E-Ink 디스플레이를 생각했는데 뭔가 중간의 애매한 녀석을 사용하게 된 것 같습니다 ㅋㅋ.. 그나마 조명 바로 아래에서는 잘 보이네요 ㅎㅎ..ㅎ.. 🫠
보통 콘솔 하면 검은 화면에 흰색 글씨를 떠올리다 보니 거부감이 조금 있지만, 정 보이지 않는다 생각되면 흰색 바탕에 검은 글씨로 반전을 해봐도 좋을 것 같습니다.
처음 사용하는 디스플레이이다 보니 조금 걱정이 되었는데, 잘 작동은 되어서 다행이네요.
다음 포스팅에서는 SBC와 Pico를 연결해 디스플레이를 띄워보겠습니다!