블로그

나빌레라의 이미지

루아 2.1 소스 코드 읽기.

루아 1.1 소스 코드 읽기에 이어 루아 2.1 소스 코드 읽기를 끝냈습니다. 루아 1.1에서 어떻게 코드가 변화했나를 주로 신경 쓰면서 읽었습니다.

https://navilera.github.io/tags/#lua2-1

위 링크를 방문하면 독후감을 읽어 보실 수 있습니다. 다음 루아 릴리즈는 2.2 군요. 슬슬 귀찮아 지고 있지만 그래도 정말 하기 싫을 만큼 귀찮아 질 때 까지 읽어 보겠습니다.

cinsk의 이미지

채용: Joyent Engineer [한국/미국]

안녕하세요.

저번에 구인 관련 글을 한 번 올렸었는데, 이번에 다시 올립니다.
(몇몇 분들에게는 따로 연락을 드리지 못한 점, 사과드립니다.)

저희 회사 Joyent는 미국 San Francisco에 위치하고 있으며, 매우 큰 고객사와 함께
Cloud Infra/Platform을 구축하고 있으며, 분야는 Networking (virtualization), VM hypervisor, Networked Block Storage Service, Managed Kubernetes 등 여러 분야의 service를 개발하고 있습니다.

이번에 미국 및 한국에서 engineer들을 고용하고 있으며, 분야는 다음과 같습니다. (한국/미국 제외한 지역은 안타깝지만 현재 고려 대상이 아닙니다.)

나빌레라의 이미지

루아 1.1 소스 코드 읽기.

원래는 KLDP에 쓰려고 했는데,
제가 이 공간을 너무 도배하는 것 같아서 간단히 github 블로그 만들고 그쪽에 올린 다음 모아서 KLDP에 링크만 쓰기로 했습니다.

루아는 1995년에 1.1 버전을 발표해서 가장 최근 버전은 2018년 5.3.5 버전까지 꾸준히 발표하고 있는 언어입니다. 나름 타게팅하고 있는 분야에서는 많이 쓰이기도 하고요.

구현이 간단하진 않은데, 코드 분량이 적고 적당한 릴리즈 횟수(23년동안 22회)라서 그냥 전체 릴리즈를 정독하면 구현을 이해할 수 있지 않을까라는 잉여로운 생각으로 소스 코드 읽기를 시작했습니다.

https://navilera.github.io/tags/#lua1-1

나빌레라의 이미지

키보드를 만듭시다. 어때요~ 참 쉽죠? (마지막)

키보드 펌웨어 개발을 완료했다. 개인적으로는 재미있게 작업한 프로젝트였다. 도메인에 대한 이해가 어렵지 않고 펌웨어의 구성 또한 누구나 예측할 수 있는 요소로 디자인 할 수 있어서 부담이 없었다. 그리고 학습용 RTOS로 만든 나빌로스를 실전에 적용했고 잘 되는 것을 검증한 것으로 내게는 재미로 만든것 이상의 가치가 있는 프로젝트였다.

15편으로 글을 나눠 썼다. 키보드 펌웨어를 만드는 과정을 절차적으로 나눴더니 15개 정도가 되길래 그렇게 썼다. 개별 글은 애초에 내가 계획했던 것보다 더 대충 썼다. 계획한 대로 정말 따라하기 강좌 수준으로 쓰려니까 너무 길어지고 내가 지치더라. 그래서 일반적인 부분이나 구글 검색등으로 쉽게 찾을 수 있는 내용을 쳐내고 썼더니 내용이 완결성이 부족한 것처럼 보인다. 나 개인의 역량 부족 탓이니 이 시리즈의 글을 읽고 이해가 안된다고 본인 탓을 하지 말아 주시기 바란다. 내가 글을 잘 못 써서 그런거다.

나빌레라의 이미지

키보드를 만듭시다. 어때요~ 참 쉽죠? (15)

  1. Main FW 바이너리 빌드 분리

부트 로더를 분리하기로 마음 먹었기에, 키보드 펌웨어는 두 개가 나와야 한다. 부트 로더와 메인 펌웨어. 그래서 makefile등 빌드에 관계된 파일을 수정해서 바이너리를 분리해야 하고 소스 코드에서도 condition flag로 부트 로더 전용 코드와 메인 펌웨어 전용 코드, 그리고 공통 코드를 식별해야 한다.

나빌레라의 이미지

키보드를 만듭시다. 어때요~ 참 쉽죠? (14)

  1. MSC를 부트로더로 변경

NOR 플래시 메모리에서 펌웨어가 동작 중인데 펌웨어 데이터가 저장되 있는 플래시 메모리 영역에 데이터를 업데이트 하면 현재 그 업데이트 동작을 수행하고 있는 펌웨어 코드를 지워버리거나 덮어서 써 버리는 문제가 생긴다. 두 개 정도 해결 방법을 생각해 봤다.

내가 설명할 두 가지 방법 외에도 여러 해결 방법이 있을 것이다. 현재 동작하고 있는 있는 코드가 손상되지 않기만 하면 된다.

나빌레라의 이미지

키보드를 만듭시다. 어때요~ 참 쉽죠? (13)

  1. 펌웨어 다운로더 만들기

키맵 다운로더를 만들었으면 펌웨어 다운로더는 쉽게 만들 수 있다. 조금만 확장하면 된다. 그러나 펌웨어 다운로드 기능은 키맵과는 다르게 고려해야할 사항이 몇개 더 있다.

나빌레라의 이미지

키보드를 만듭시다. 어때요~ 참 쉽죠? (12)

  1. 키맵 다운로더 만들기

FAT16 데이터를 펌웨어에서 만들어서 운영체제에 보내면 드라이브로 마운트 된다. 그러면 사용자는 키맵 바이너리나 펌웨어 바이너리를 직관적이고 단순하게 그냥 복사하면 된다. 펌웨어는 파일 데이터만 내장 플래시 메모리에 저장하고 그 데이터를 잘 쓰는 것이다. 이 과정에서 펌웨어는 사용자가 보낸 데이터가 키맵인지 펌웨어인지 구분해야 한다. 우선 키맵을 어떻게 구분할지 방법을 궁리해 보자.

나빌레라의 이미지

키보드를 만듭시다. 어때요~ 참 쉽죠? (11)

  1. FAT16 만들기

MSC 스펙을 구현해서 디바이스를 대용량 저장장치로 연결하면 장치로 연결까지는 되는데 드라이브로 마운트는 되지 않는다. 윈도우면 E:, F: 이렇게 드라이브로 뜨지 않는다는 말이고 리눅스면 /mnt나 /media 디렉터리 밑에 뭐가 생기지 않는다는 말이다. 호스트에서 디바이스로 파일을 보내는 실질적인 작업을 하려면 드라이브로 마운트를 해야 한다. 그러려면 디바이스에 파일 시스템을 만들어야 한다.

디바이스에 파일 시스템을 만드는 방법은 두 가지 방법이 있다. 디바이스 스토리지 영역을 실제로 호스트에 공개해서 호스트에서 포멧하는 방법. 디바이스에서 파일 시스템에 해당하는 데이터를 호스트로 보내서 호스트가 이 디바이스는 이미 파일 시스템이 있다고 인식하게 만드는 방법. STM32F103은 스토리지라고 해 봐야 인터널 플래시 64KB ~ 128KB 뿐이고 내가 MSC를 구현한건 호스트에서 파일을 받기 위함이지 디바이스 내부의 바이너리 데이터를 호스트로 보내려고 하는 것은 아니다. 그래서 굳이 내가 호스트에서 디바이스 스토리지 영역을 제어하게 할 필요는 없다.

페이지

RSS - 블로그 구독하기