한량처럼 살고 싶다

맨날 까먹는 prettier + eslint 설정법

투영 — Wed, 23 Apr 2025 09:35:22 +0900

가끔 json파일을 직접 건드려야 할 때가 있다.

에어비엔비 코드 컨벤션 사용 기준이다.

.eslintrc

{
    "parser": "@typescript-eslint/parser",
    "extends": [
      "plugin:react/recommended",
      "plugin:@typescript-eslint/recommended"
    ]
  }

.eslintrc.json

{
  "root": true,
  "env": {
    "browser": true,
    "es2021": true,
    "node": true
  },
  "extends": [
    "airbnb",
    "airbnb/hooks",
    "plugin:@typescript-eslint/recommended",
    "plugin:prettier/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    },
    "project": "./tsconfig.json"
  },
  "plugins": ["react", "@typescript-eslint", "prettier"],
  "rules": {
    "prettier/prettier": ["error"],
    "react/react-in-jsx-scope": "off",
    "react/jsx-filename-extension": [
      "warn",
      { "extensions": [".tsx", ".ts", ".jsx", ".js"] }
    ],
    "import/no-extraneous-dependencies": ["error", { "devDependencies": true }],
    "no-console": "warn",
    "no-unused-vars": "warn",
    "@typescript-eslint/no-unused-vars": "warn"
  },
  "settings": {
    "react": {
      "version": "detect"
    },
    "import/resolver": {
      "typescript": {},
      "node": {
        "extensions": [".js", ".jsx", ".ts", ".tsx"]
      }
    }
  }
}

.prettierrc

{
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 80,
  "tabWidth": 2,
  "semi": true
}

eslint.config.js

import js from '@eslint/js'
import globals from 'globals'
import reactHooks from 'eslint-plugin-react-hooks'
import reactRefresh from 'eslint-plugin-react-refresh'
import tseslint from 'typescript-eslint'

export default tseslint.config(
  { ignores: ['dist'] },
  {
    extends: [js.configs.recommended, ...tseslint.configs.recommended],
    files: ['**/*.{ts,tsx}'],
    languageOptions: {
      ecmaVersion: 2020,
      globals: globals.browser,
    },
    plugins: {
      'react-hooks': reactHooks,
      'react-refresh': reactRefresh,
    },
    rules: {
      ...reactHooks.configs.recommended.rules,
      'react-refresh/only-export-components': [
        'warn',
        { allowConstantExport: true },
      ],
    },
  },
)

다음은 vscode 설정

file 탭 클릭 -> preference 클릭 -> settings 클릭

1) 저장버튼 누를 때마다 자동 포맷팅하기

검색창에 format on save 를 입력하면 Editor: Format On Save 나와있다. 체크해주면 된다.

2) default formatter 설정하기

저장(컨트롤s)했는데도 prettier 가 작동을 안 해요! => default formatter 설정을 해주면 해결된다.

settings 에서 default formatter 를 검색한 뒤, 아래 사진처럼 prettier를 골라주면 된다.

만약 이게 되어 있는데도 저장 시 포맷팅이 안 된다면 다른 문제일 수 있다 ㅜ

3) javascript/typescript format

마찬가지로 javascript format 검색한 뒤 enable/disable 부분에 체크 해제해주자.

이제부턴 개인 설정으로 format 하기 때문이다.

typescript format 도 검색해서 체크 해제해주면 된다.

새로운 환경에서 vscode 쓸 때마다 삽질하지 않길

CAN Frame 타입

투영 — Tue, 25 Feb 2025 10:42:48 +0900

Single Frame

데이터 길이가 7바이트 이하일 경우 single frame 을 사용하여 데이터 전송이 가능하다.

데이터의 형태가 0x06OOOOOOO 라면, 해당 프레임은 싱글 프레임이면서 데이터의 길이는 2인 것이다.

Bit offset	7 .. 4 (byte 0)	3 .. 0 (byte 0)	15 .. 8 (byte 1)	23 .. 16 (byte 2)
single	0	size (0 .. 7)	Data A	Data B

Multi Frame

데이터 길이가 7바이트를 초과할 경우 multi frame 을 이용하여 데이터 전송이 가능하다.

멀티 프레임에는 2가지 종류가 있는데,

멀티 프레임을 전송한다는 의미를 담은 가장 첫 번째 프레임인 First Frame과

그 이후에 오는 프레임이라는 내용을 담은 Consecutive Frame 두 가지가 있다.

일반적인 CAN 프레임은 데이터의 길이를 12bit로 표현해야 하므로 전송 가능한 최대 byte 수가 4095이다.

이를 넘어설 경우 CAN FD 프로토콜 혹은 사용자 정의 프로토콜을 사용해야 한다.

Bit offset	7 .. 4 (byte 0)	3 .. 0 (byte 0)	15 .. 8 (byte 1)	23 .. 16 (byte 2)
First Frame	1	size (12bit)		Data A
Consecutive Frame	2	index (0..15)	Data A	Data B

예를 들어 First Frame 이 이런 형태로 들어온다면: 0x1009OOOOOO

최초 상위 4비트가 1 이며 이어오는 12bit 가 009 이기 때문에 이 프레임은 First frame 이자 총 데이터의 길이가 9 라는 뜻이 된다.

그러므로 이번 프레임이 오고 나서 2로 시작되는 다른 프레임이 온다는 것까지 알 수 있다.

Consecutive Frame 은 20, 21, 22, 23 ... 2F 이런 식으로 늘어난다.

인덱스가 0부터 15까지이며 만약 16개의 연속된 Consecutive Frame 을 전송했는데 데이터가 남아있을 경우 다시 20부터 순환하게 된다.

주의할 점은 첫 번째 Consecutive Frame (CF)는 0x21부터 시작하고, 2F까지 증가한 후, 다음 프레임에서는 다시 0x20으로 순환하는 구조라는 점이다.

21 22 .. 2F 까지 다 돈 뒤에 그 다음에 오는 Consecutive가 20 부터 시작된다는 의미이다.

Flow Control Frame

can 통신에서는 여러 프레임을 연속적으로 보낼 때 상대방으로부터 Flow Control Frame 을 받은 뒤에 보낸다.

Bit offset	7 .. 4 (byte 0)	3 .. 0 (byte 0)	15 .. 8 (byte 1)	23 .. 16 (byte 2)
description	type	if the transfer is allowed	Block Size	Separation time
Single	type = 3	0: Continue to send 1: Wait 2: Overflow/abort	0: flow control frame 혹은 delay 없이 consecutive 전송	Separation time
Single	type = 3	0: Continue to send 1: Wait 2: Overflow/abort	> 0: 다음 Flow Control Frame을 기다리기 전 보낼 Consecutive Frame 수	0xF1 ~ 0xF9 100~900 의 마이크로초

상위 4비트는 3으로 고정되어있다.

하위 4비트는 0일 경우 Consecutive 전송, 1일 경우 다음 Flow Control Frame 을 기다린다는 의미, 2일 경우 중단한다.

Block Size 가 0일 경우 Flow Control Frame / Delay 없이 Consecutive Message를 전송한다는 의미이다.

만약 0보다 큰 값이 올 경우 다음 Flow Control Frame 을 기다리기 전 보낼 Consecutive Frame 수를 말한다.

Bitbake 의존성 소개

투영 — Sat, 22 Feb 2025 13:52:31 +0900

빌드타임 의존성(DEPENDS)과 런타임 의존성(RDEPENDS_${PN}) 두 개로 나뉜다.

빌드타임 의존성은 Depends에 정의되며, 컴포넌트 빌드 시 의존성이 있는 빌드가 언제 수행되어야 할 지 정의한다.

Depends 안의 변수값은 의존성 있는 레시피 이름으로 정의된다.

런타임 의존성은 RDEPENDS_PN 은 패키지 단위로 정의되므로 뒤에 PN이 추가된다.

실행 도중의 의존성이기 때문에 빌드 순서에는 의미가 없고

최종적으로 내 컴포넌트가 빌드 완료되기 전에 다른 컴포넌트 빌드가 완료되면 된다.

Bitbake 소개

투영 — Sat, 22 Feb 2025 13:48:10 +0900

Bitbake 소개

Bitbake 는 실행엔진으로, 쉘과 파이썬 태스크를 효율적이고 병렬적으로 실행할 수 있게 만들어준다.

실제 Bitbake 는 태스크 단위로 실행되는데 태스크에는 do_fetch, do_unpack 등이 존재한다.

가장 마지막에 do_rootfs 를 실행한 뒤 이미지를 만드는 do_image를 실행하면 bitbake 의 업무가 끝난다.

Bitbake 디렉토리 종류

${DL_DIR}

소스 다운로드 원본이 저장되는 위치.

모든 컴포넌트가 이 위치를 사용한다.

bitbake.conf 파일에 설정 가능하다.

${S}

다운로드 된 소스코드의 압축이 풀리는 위치.

${WORKDIR} 하위에 위치하며 default name은 레시피이름-버전이다.

${B}

${B} 디렉토리에는 빌드 과정 중 생성된 결과물이 저장된다.

${D}

${D} 디렉토리에는 최종 빌드 산출물이 저장된다.

bitbake curl -c listtasks

: 특정 레시피 (curl)의 실행 가능한 태스크 목록을 확인하는 명령어

자주 사용하는 Bitbake 태스크 종류

DO_FETCH

SRC_URI 변수에 소스 위치를 정의
소스가 다운로드 되면 DL_DIR 변수로 설정된 곳에 저장됨
git, svn, ftp, http, repo 등 다양한 프로토콜 지원함
:// 앞의 프로토콜 명을 보고 어떤 프로토콜을 사용하는지 확인함. 필요에 따라 해시값 혹은 체크섬 값을 넣어줘야 함.

DO_UNPACK

do_fetch 에서 받은 소스코드가 S 디렉토리에 압축 해제
SRC_URI에 링크만 적어주면 알아서 압축 해제하여 S 하위에 저장한다.

DO_PATCH

patch 나 diff 확장자를 가진 파일이 SRC_URI 에 있으면 패치 파일로 인식한다.
Patch level 을 지정할 수 있으며 기본은 -p1 이다.

DO_POPULATE_LIC

license 와 lic_files_chksum 에 정의된 라이센스 체크
라이센스 변수에 사용하는 라이센스를 넣어주면 된다
내부 라이센스 사용 시 CLOSED 를 추가해주면 스킵됨

DO_CONFIGURE

컴파일을 시작하기 전 환경 설정을 하는 단계
do_configure 함수를 직접 만들거나 autotools.bbclass 등을 inherit 하여 사용한다
inherit 할 경우 EXTRA_OECONF 등의 변수를 사용하여 커스터마이즈 가능

DO_COMPILE

코드를 컴파일 할 때 사용하는 태스크
do_configure 과 비슷하게 직접 정의하거나 사전 정의된 클래스를 inherit 하여 사용한다

DO_INSTALL

빌드 후 산출물을 원하는 디렉토리에 설치하는 task
D 변수와 함께 사용해야 한다
D = ${WORKDIR}/image

DO_PACKAGE

레시피를 빌드하여 산출된 결과물을 여러 패키지로 저장하기 위한 태스크
최종 이미지를 만들 때는 패키지 단위로 설치가 진행된다.

Yocto 프로젝트 용어 소개

투영 — Sun, 16 Feb 2025 16:11:50 +0900

Metadata vs Bitbake

make 와 makefile 의 차이라고 간단하게 설명 가능

make는 빌드하는 도구이고, makefile은 빌드하는 내용물이 정의되어 있는 메타데이터들.

bitbake는 파이썬으로 만들어져있는 yocto를 빌드하는 핵심 도구이자 엔진.

metadata는 빌드를 하는 방법을 정의한 파일들 (.bb 파일들 위주)

모든 컴포넌트는 자신만의 bb 파일이 있으며 그 안에는 소스 다운로드 방법부터 빌드 방법까지 전부 정의되어 있다.

yocto 시스템은 계층구조로 이뤄져있고 이를 메타데이터로 정의한다.

계층 구조는 아래와 같다.

layer: 비슷한 기능을 하는 컴포넌트의 레이어를 모아놓은 것
recipes: .bb 로 이뤄져있으며 각 컴포넌트가 어떻게 빌드되는지 정의함
machine: bsp 관련 레시피를 모아둠
distro: 배포판의 설정 및 관련 컴포넌트를 모아둔 것

위의 메타데이터들을 bitbake라는 엔진을 사용해 custom linux image를 생성한다.

Distro

배포판의 약자로, 빌드 전체를 구성하는 정책을 정의한다.

배포판의 ipv6, 키보드, nfs 등과 같은 어떤 특성을 지원하는지 + 배포판 이름과 버전을 정의한다.

conf/distro.conf 에 정의되어있고 local.conf에 distro 변수를 넣어 사용한다.

poky 가 레퍼런스 배포판이고, poky-agl + pelux + tizen 같은 다양한 커스텀 리눅스 배포판이 있다.

MACHINE

yocto 이미지가 빌드되는 대상 디바이스 또는 SoC를 말한다.

machine 은 bsp 레이어의 machine이름.conf 파일이 존재하며 local.conf 파일에 machine 이름을 넣어 사용한다.

poky에서는 3가지 레퍼런스 머신을 제공하는데 x86, bedgerouter, beaglebone 제공 중이며 qemu 도 지원한다.

실제 제품 개발할 때 레퍼런스 하드웨어가 아닌 직접 제공하는 메타레이어를 사용하여 진행한다.

Layers

컴포넌트 레이어의 조합으로 구성. 여기서 레이어는 레시피의 조합으로 구성.

기본적으로 oe-core (OpenEmbedded Core)를 기반으로 한다.

poky (oe-core)
- 기본 빌드 시스템 제공 (bitbake)
- 패키지 및 리눅스 배포에 필요한 기본 레시피를 포함
poky (meta-yocto)
- Yocto 프로젝트에서 제공하는 기본 메타 데이터가 포함된 레이어
- meta-yocto 레이어는 기본적인 빌드 설정 및 예제 머신 구성을 제공합니다.
Hardware-Specific BSP Layer (하드웨어별 BSP 레이어)
- 특정 하드웨어 보드에 맞춘 BSP (Board Support Package) 관련 구성 요소
- 예를 들어 meta-raspberrypi 레이어가 이에 해당됨
- 주로 부트로더, 커널, 하드웨어 드라이버 관련 설정이 포함됨
UI Specific Layer (UI 레이어)
- UI (User Interface) 관련 설정 및 패키지를 포함하는 레이어
- Qt 기반의 UI 어플리케이션을 포함하는 레이어
개발자별 맞춤 레이어
- 최상위 레이어, 개발자가 추가하는 애플리케이션, 사용자 설정, 커스텀 스크립트 등이 포함됨
- 개발자가 독자적인 소프트웨어 기능을 추가할 때 사용하는 영역

결론적으로 하위 레이어일수록 공통적인 기능을 제공하며 상위 레이어로 갈수록 특정 제품 또는 개발자 맞춤 설정이 추가됨

각 레이어는 독립적이며 필요에 따라 추가/삭제 될 수 있음.

하드웨어와 소프트웨어를 분리하여 유지보수가 용이하며 커스텀 배포판을 손쉽게 관리할 수 있음

Layers 예시

1. Poky (기본 레이어)

Poky는 Yocto 프로젝트의 기본적인 메타데이터가 포함된 레이어
예시: curl_7.82.0.bb
- meta/recipes-support/curl/ 디렉터리 내에 curl_7.82.0.bb 파일이 존재
- curl 패키지를 빌드하는 레시피 파일

2. meta BSP Layer (예: Raspberry Pi BSP)

특정 하드웨어(보드)에 맞는 Board Support Package (BSP) 를 포함하는 레이어
예시: linux-raspberry_5.10.bb
- recipes-kernel/linux/ 디렉터리에 위치.
- Raspberry Pi 보드용 리눅스 커널을 정의한 레시피.

3. meta custom layer (사용자 정의 레이어)

개발자가 기존 레시피를 수정할 때, 기본 파일을 직접 변경하는 것이 아니라 .bbappend 파일을 이용하여 추가 및 오버라이드
예시:
- meta/recipes-support/curl/curl_%.bbappend
  - curl 패키지에 대한 사용자 정의 수정 사항 추가.
- recipes-kernel/linux/linux-raspberry_%.bbappend
  - Raspberry Pi용 커널 레시피에 대한 추가 수정.

Recipe 에서 쓰는 변수 종류

SRC_URI	컴포넌트 소스 주소 정의
LICENSE	라이센스 정의
PN	패키지 이름
PV	패키지 버전
DEPENDS	빌드 타임 의존성 정의
RDEPENDS	런타임 의존성 정의

Class

공통 기능을 구현해놓고 여러 레시피에서 상속받아 사용
Meta 레이어의 classes 디렉토리 밑에 존재
bbclass 확장자
레시피에서 inherit 지시어와 함께 사용 (inherit cmake)
Conf 파일에서 INHERIT 지시어와 함께 사용
Poky/meta/classes/base.bbclass 가 yocto 의 기본 태스트가 정의된 기본 class

레시피 전개

https://docs.yoctoproject.org/dev/dev-manual/new-recipe.html

5 Writing a New Recipe — The Yocto Project ® dev documentation

Recipes (.bb files) are fundamental components in the Yocto Project environment. Each software component built by the OpenEmbedded build system requires a recipe to define the component. This section describes how to create, write, and test a new recipe. 5

docs.yoctoproject.org

레시피 작성 (Establish the Recipe)
- 새로운 레시피(.bb 파일)를 생성합니다.
소스 파일 가져오기 (Fetch Source Files)
- 원격 저장소(Git, SVN 등)에서 소스 파일을 다운로드하거나, 로컬 경로를 지정하여 소스 파일을 가져옵니다.
소스 파일 압축 해제 (Unpack Source Files)
- 가져온 소스 파일이 압축되어 있다면 해제합니다.
소스 파일 패치 적용 (Patching Source Files)
- Yocto에서 요구하는 빌드 환경에 맞게 패치를 적용할 수 있습니다.
라이선스 정보 추가 (Add Licensing Information)
- 패키지의 라이선스 정보를 LICENSE 변수에 정의합니다.
설정 추가 (Add Configurations)
- 빌드 설정(do_configure 함수 등)을 추가합니다.
컴파일 수행 (Compilation)
- do_compile 함수를 통해 실제 소스 코드를 빌드합니다.
Autotools 또는 CMake 사용 여부 확인
- Yes → 자동으로 do_install 단계에서 필요한 작업이 수행됨.
- No → do_install 함수를 직접 작성해야 함.
추가적인 서비스(예: 데몬, 백그라운드 프로세스)가 필요한가?
- Yes → 서비스 초기화 스크립트(예: systemd 또는 init.d 스크립트)를 설치해야 함.
- No → 추가적인 설치 작업 없이 패키징 단계로 이동.
패키징 (Packaging)
- 빌드된 결과물을 .ipk, .rpm, .deb 등의 패키지 형식으로 변환.
설치 후 스크립트 제공 (Provide Post-Installation Scripts)
- 패키지 설치 후 실행해야 하는 후처리 스크립트(예: 환경 설정)를 추가할 수 있음.
런타임 테스트 수행 (Perform Runtime Testing)
- 실제 환경에서 실행 테스트를 진행하여 레시피가 올바르게 동작하는지 확인.

Packagegroup & Image

Packagegroup: 다양한 패키지들의 번들 모음

Image: yocto 최상위 레시피, 다양한 이미지를 제공하기 위해 기본 제공되는 이미지. .bb 를 실행하면 이미지가 생성됨

기본적으로 core-image-minimal.bb를 상속받아 개발을 시작함

Yocto 프로젝트 소개

투영 — Sat, 15 Feb 2025 18:14:43 +0900

임베디드 리눅스 시스템 소개

임베디드 하드웨어 구조

: 부트로더 + 리눅스 커널과 드라이버 + 미들웨어 + 어플리케이션 + 툴체인

툴체인

: 소스코드를 실제 임베디드 시스템 내에서 실행 가능한 바이너리 코드로 바꿔주는 것

: 컴파일러, 코어 라이브러리 등이 포함되어 있음

임베디드 리눅스 부팅 순서

부트로더
1. DTB 로딩, 커널을 램에 적재, 커널 시작
2. u-boot 이 임베디드 시스템에서 자주 사용되는 오픈소스 부트로더
커널
1. 부트로더는 더 이상 사용되지 않고, 메모리를 회수
2. 부트로더에서 커널로 제어권이 넘어갈 때, 하드웨어의 세부사항 + 커널 커맨드 정보가 함께 넘어감
3. 운영체제에 가장 핵심적인 역할을 하며, 커널이 시작되면 루프 파일 시스템 마운트와 동시에 init 어플리케이션 시작
4. init은 최근 systemd 가 많이 사용되는 추세
  1. sbin/init: 사용자 공간 서비스 및 애플리케이션 시작

임베디드 리눅스 빌드 시스템

오픈소스 컴포넌트 + 자체개발 컴포넌트 + 외부 업체 개발 컴포넌트 = 임베디드 리눅스 빌드 시스템

임베디드 리눅스 빌드 시스템에 각종 환경 설정을 넣어 제품에 맞게 변형

-> 산출물: 툴체인, 부트로더 이미지, 커널 이미지, 루트파일 시스템 이미지

Yocto 프로젝트 소개

하드웨어 상관 없이, 커스텀 임베디드 리눅스 시스템을 생성하는데 도움을 주는 오픈소스 프로젝트

Poky: Yocto 프로젝트 레퍼런스 배포판 (Yocto 프로젝트의 하위 프로젝트)
OpenEmbedded: Poky 의 핵심 부분을 차지하는 빌드 엔진과 Yocto 호환 메타데이터
Yocto 프로젝트: 최상위 오픈 소스 프로젝트

윈드리버, 인텔이 아주 오랫동안 yocto platinum member 로 참여되어 있음

Yocto 산하 프로젝트 소개

: bitbake, openembbed core, poky, toaster, auto builder

Yocto 프로젝트 작업 흐름

설정 파일 종류

1) User Configuration

: 사용자 설정(병렬 빌드, 머신, 디스트로 설정), 빌드 레이어 설정

2) Machine BSP Configuration

: 하드웨어 관련 설정

3) Policy Configuration

: 배포판 관련 설정

4) Meta

: 컴포넌트 빌드 과정이 정의된 메타데이터

전역 설정은 보통 확장자가 .conf 로 이루어져 있음 / 개별 컴포넌트 확장자는 .bb

-> yocto 에서 파일 확장자가 .conf 면 전역 설정이다.

빌드 프로세스 (Build Process)

소스, 패치 파일 등의 위치가 정의되어 있기 때문에, 각 컴포넌트별로 정의된 우선순위에 맞게 다운로드 받음
- SRC_URI 변수에 정의되어 있음
  - 소스가 온라인에 올라가있든, 오프라인에 저장되어 있든 상관 없음
  - MIRROR 사이트도 접근하여 진행 가능
- Patch 를 통한 소스 수정을 지원한다.
- 빌드하는 표준 과정 정의
  - Autotools, cmake, qmake, scons 등 다양한 빌드 도구를 지원하는데, cmake를 잘 사용하는 편
  - EXTRA_OEMAKE 등과 같은 변수로 추가 설정 지원
  - pseudo 를 사용하여 특별한 파일, 권한 및 소유자/그룹을 설정함
정해진 규칙에 따라 package 생성됨
- 헤더파일이 포함된 dev 패키지 + 디버그 심볼 들어간 debug 패키지 생성
- rpm, deb, ipk 패키지 등 중 한 개를 선택하여 최종 산출물 만들 수 있음
- 패키지가 생성되면 제대로 생성됐는지 확인 -> QA 체크 (sanity check)
  - yocto reference 를 읽으면 새니티 체크 설정 가능

부팅 비교

투영 — Mon, 10 Feb 2025 21:49:33 +0900

정리 (비교표)

NFS Boot	네트워크에서 파일 시스템 마운트	저장장치 부담 없음, 실시간 코드 변경 가능	네트워크 없으면 부팅 불가	개발 중 테스트 및 디버깅
RAM Boot	RAM에 파일 시스템 로드 후 부팅	빠른 부팅, 저장장치 필요 없음	RAM 부족 시 문제, 재부팅 시 데이터 초기화	복구 모드, 디스크 없는 시스템
U-Boot	임베디드 시스템 부트로더	다양한 부팅 방식 지원, 유연한 설정 가능	설정 실수 시 부팅 불가	Yocto 등 임베디드 OS 부팅

NFS Boot → 네트워크 기반으로 파일 시스템 실행 (개발 중 편리)
RAM Boot → RAM에 올려서 부팅 (빠르지만 휘발성)
U-Boot → 다양한 부팅 방식을 설정하고 실행하는 부트로더

메모리 종류

투영 — Mon, 10 Feb 2025 21:46:20 +0900

메모리는 크게 ROM 과 RAM 으로 분류된다.

RAM 은 읽고 쓰기가 가능한 메모리이고 ROM은 쓰기에 제약이 있는 메모리이다.

쓸 수 있는 횟수가 늘어날 수록 활용도가 높아지는데,

Flash Memory 타입은 보통 10만번 정도를 쓸 수 있으며 쓰기 수명이 긴 것들이 일반적으로 쓰기 속도도 빠르다.

ROM 알아보기

Masking ROM

생산할 때 데이터가 고정되어 출하된다.

오로지 읽기만 가능하고, 비휘발성 메모리이다.

OTP ROM

사용자가 데이터를 쓸 수는 있지만 한 번 쓰면 수정이 불가능하다.

디바이스 보안에서 유용하게 사용되기 때문에 대부분의 SoC가 내부에 OTP ROM을 갖는다.

또한 주요한 데이터(암호화 키, 시리얼 넘버 등)를 OTP ROM에 저장한다.

OTP ROM 또한 마스킹 롬처럼 비휘발성 메모리이자 데이터 보존성이 뛰어난 메모리이다.

EEPROM (Electrically Erasable Programmable Rom)

읽고 쓸 수 있는 ROM 들 중 가장 오래된 종류

작은 플래쉬 메모리 라고 생각하면 된다.

플래쉬 메모리는 비휘발성 메모리이자 전원이 꺼져도 데이터를 유지할 수 있는 반도체 장치를 말한다.

여기서 EPROM (지우고 재작성 가능한 메모리) 와 EEPROM (전기적으로 지울 수 있는 메모리) 에서 발전된 형태이다.

NOR Flash vs NAND Flash

둘 다 비휘발성 메모리인 플레쉬 메모리이다. (전원이 없어도 보존이 가능한 메모리)

메모리 셀 구조 및 데이터 접근 방식에서 차이를 갖는다.

NOR Flash

주소 기반 읽기 (Random Access)
- 랜덤 엑세스가 가능하여 메모리의 특정 주소에 직접 접근 가능
- 실행 코드 저장 및 실행에 적합하다
느린 쓰기와 삭제 + 빠른 읽기
낮은 저장 밀도 (저장 용량은 낮고 가격은 비쌈)
데이터 정확도가 높음
펌웨어 저장 (IoT 디바이스, 자동차 전자장치, 임베디드 시스템)

NAND Flash

블록 기반 읽기 (Sequential Access)
- 데이터는 블록 단위로 읽고 쓰며 순차 접근만 가능
- 단순 데이터 저장에 적합
빠른 쓰기와 삭제 + 느린 읽기
높은 저장 밀도 (저장 용량은 크고 가격이 쌈)
낮은 신뢰성
- 데이터 오류 발생 가능성 높음
- 오류 수정 알고리즘 (Error Correction Code, ECC) 필요
시스템에서 데이터를 실행하려면 복사가 필요함
SSD, USB 메모리, SD 카드, 스마트

eMMC (Embedded Multi-Media Controller)

NAND 플래쉬 메모리에 NAND 컨트롤러를 내장한 메모리이다.

NOR 와 NAND 모두 해당 플래쉬를 제어할 수 있는 컨트롤러를 칩셋 (SoC) 에서 지원해줘야 했지만,

eMMC 는 컨트롤러를 내장하여 최적화된 성능을 갖는다.

SSD (Solid State Disk)

eMMC 보다 용량이 크고 빠른 메모리이다.

HDD + 플래쉬 메모리 + RAM 이 다 섞인 디스크이다.

내부 저장 장치는 플래쉬가 사용되며, 이를 제어하는 컨트롤러가 있으며 RAM 버퍼를 사용하여 성능을 높이고

디스크처럼 사용이 가능하다.

HDD 메모리를 대체하게 되었다.

HDD 메모리는 PVR 이나 DVR 처럼 녹화된 영상과 같이 대용량의 데이터 저장이 필요한 기기에서 사용된다.

RAM 알아보기

SRAM -> DRAM(요즘 쓰이는 RAM의 원형) -> SDRAM

DDR SDRAM

현재 가장 많이 쓰이는 메모리이다.

데이터 클락 신호의 상승 및 하강 엣지에서 데이터를 동시에 전송하여 SDRAM (single data rate dram) 보다 2배의 데이터 전송을 제공한다.

실제로 ddr은 double date ram 의 줄임말이기도 하다

휘발성: 전원이 꺼지면 저장된 데이터가 모두 사라진다.
고속 등장: 클록 신호의 상승 및 하강 엣지에서 데이터를 전송하여 고속 처리가 가능하다
동기화: CPU의 클록 신호와 동기화되어 동작합니다.
저렴한 비용: 대량 생산으로 인해 저장 용량 대비 비용이 낮다.

NVRAM (Non-Volatile Random Access Memory)

전원이 꺼져도 데이터를 유지할 수 있는데,

DRAM 과 같이 빠른 엑세스 속도를 가지면서도 플래시 메모리처럼 데이터를 영구히 보존한다.

램임에도 불구하고 비휘발성인 점에서 효율적이다.

비휘발성
빠른 속도
내구성 -> 쓰기 및 읽기에서
에너지 효율 -> 데이터 유지에 전력이 필요 없거나 매우 적음

디바이스 드라이버 vs 커널 모듈

투영 — Mon, 20 Jan 2025 11:56:09 +0900

gpio 관련 기능 개발 하다가, 내가 만든 기능이 디바이스 드라이버인지 커널 모듈인지 헷갈려 정리한다.

결론부터 말하자면 둘 다에 해당했음.

디바이스 드라이버

디바이스 드라이버는 컴퓨터 프로그램이다.

컴퓨터에서 device(기기)를 동작시키거나 조종하는 프로그램인 것이다.

리눅스는 디바이스 역시 파일이다.

그래서 디바이스 드라이버는 파일을 컨트롤하기 위한 프로그램을 의미한다.

커널은 application 과 소통하기 위해 VFS를 거치고, 그 이후에 시스템 콜을 거친다.

따라서 디바이스 드라이버 역시 VFS의 형식에 맞게 작성되어야 한다.

디바이스 드라이버 종류

1) character device driver

바이트 단위로 데이터를 순차적으로 받아오기 때문에 버퍼와 캐시를 갖지 않는다.

예시로는 키보드, 마우스, 시리얼 포트 등등이다.

2) block device driver

일정 크기의 버퍼 (블록 단위) 를 통해 데이터를 처리한다.

커널 내부의 파일 시스템에서 관리하고 예시로는 하드 디스크, 램 디스크 등이 있다.

3) network device driver

네트워크 계층과 연결되어 네트워크 통신을 통해 네트워크 패킷을 송수신할 수 있는 기능을 제공한다.

이더넷 등이 있다.

커널 모듈

커널의 기능을 동적으로 확장하거나 변경할 수 있는 독립적인 코드 조각이다.

일반적으로 하드웨어에 무관하다.

그리고 실행 중인 커널에 동적으로 추가하거나 제거가 가능한 코드이다.

헷갈렸던 점은 디바이스 드라이버도 커널 모듈로 제작이 가능하다는 것이다.

커널 모듈로 제작하는 디바이스 드라이버

드라이버를 커널 모듈 형태로 구현하며, 커널이 실행 중일 때 동적으로 로드 및 언로드 될 수 있다.

실행 중에 insmod 와 rmmod를 통해 추가와 제거가 가능하다.
디바이스 드라이버에 변경 사항이 생겨도 전체 커널을 다시 빌드하지 않아도 된다.
커널 이미지 (vmlinuz)와 별도로 드라이버를 관리할 수 있다.
문제가 생겼을 때 해당 모듈만 수정하고 재 로드가 가능하다.
부팅 시점에 필요한 필수 하드웨어 드라이버로는 적합하지 않다.

정적 디바이스 드라이버로 제작

드라이버 코드를 커널 소스에 포함시켜 커널 빌드 시 함께 컴파일 한다. 그리고 커널 이미지 (vmlinuz)에 통합되어 부팅 시 로드된다.

커널 부팅 시점에 드라이버가 자동으로 초기화된다.
드라이버 로드 실패나 의존성 문제를 방지할 수 있다.
수정하면 전체를 다시 빌드해야 하고, 커널 크기가 증가한다.
부팅 디스크, 루트파일 시스템, 초기화 장치 등 부팅에 필수적인 하드웨어 장치에 어울린다.

내 안에선 둘 다 그냥 커널에 들어가는 하나의 프로그램인데 왜 나눠놨는지 궁금했다.

아직도 직관적으로 이해가 된 건 아니지만 의존성 문제인 것 같다.

개발을 많이 해보면 알겠지

커널 모듈과 정적 드라이버 차이와 역할

커널 모듈

동적 로드 및 언로드 가능: insmod, rmmod 명령을 통해 실행 중인 커널에 기능(드라이버 포함)을 추가하거나 제거 가능
목적
1. 새로운 하드웨어나 기능을 커널 재부팅 없이도 추가 가능함
2. 개발 및 디버깅이 편리함 -> 모듈만 교체하면 되니까
3. 필요하지 않을 때 메모리에서 해제하여 자원 절약 가능

정적 드라이버

커널에 포함: 커널이 부팅될 때 로드되며 실행 중에는 제거할 수 없음
목적
1. 부팅에 필수적인 하드웨어를 지원해야 할 때 사용 (루트파일 시스템, 초기화 과정에서 필요한 장치)
2. 성능과 안정성이 중요한 환경 (정적으로 포함되어 있어 로드 속도가 빠르고 의존성 문제 없음)

커널 모듈과 정적 드라이버를 나눠둔 이유

모든 것을 동적 드라이버 혹은 커널 모듈로 만들지 않은 이유가 궁금했다.

성능

정적 드라이버는 커널에 이미 포함되어 있기 때문에 부팅 시점부터 바로 사용할 수 있음

부팅 초기에는 동적 모듈을 로드할 수 있는 사용자 공간 도구 (udev 등) 이 아직 실행되지 않은 경우가 많다
예로는 부팅 시 반드시 필요한 루트파일 시스템을 마운트하기 위한 스토리지 드라이버 등이 있음

안전성

동적으로 추가/제거되는 커널 모듈은 실시간으로 시스템에 영향을 줄 수 있음

잘못된 모듈을 로드하면 커널 패닉이 발생할 수 있음
정적 드라이버는 부팅 시 검증된 상태에서 로드되므로 안정성이 높음

의존성 문제

커널 모듈은 종종 다른 모듈에 의존한다

모든 것이 동적으로 구성되면, 올바른 순서로 로드하거나 의존성을 만족시키는 과정에서 복잡성이 증가한다
정적 드라이버는 커널 빌드 시 이미 필요한 모든 의존성이 해결된 상태로 포함된다.

부팅 시간

부팅 시점에 동적 로드를 처리하려면 추가 작업 (모듈 검색 및 로드) 이 필요하기 때문에 시간이 더 걸릴 수 있다.

정적 드라이버는 커널이 부팅될 때 이미 메모리에 로드되어 있으므로 부팅 시간이 단축된다.

특수 환경

일부 임베디드 시스템이나 리얼타임 시스템에서는 모든 것이 정적으로 설정되어야만 성능과 안정성이 보장된다.

의료기기, 항공 시스템, 자동차용 시스템 등

요약하자면 커널 모듈은 유연성과 확장성, 개발 편의성을 제공하기 위해 만들고 정적 드라이버는 안정성, 성능, 초기화 요구사항을 보장하기 위해 만든다.

리눅스는 요구사항에 따라 개발자가 편리하게 개발할 수 있도록 여러 선택지를 제공한 것이다.

[안드로이드 스튜디오] auto-health 개발 완료 (90프로 쯤)

투영 — Sun, 19 Jan 2025 15:14:51 +0900

auto-health 개발이 얼추 완료됐다.

색깔이랑 아이콘 같은 것 이것저것 넣다보니 업로드가 느렸다
기능 자체는 한달 정도 계속 써보면서 테스트를 해봤는데 크게 문제는 없는듯?
네이버 OCR이 인식률이 대단히 좋다

90프로라 적은 이유는 계속 업데이트가 될 수도 있기 때문에~

리드미를 적어야되는데 귀찮아서 나중에 적을란다.
오늘 할 일 너무 많이 남음

개발하면서 아쉬웠던 점은 헬스 커넥트가 생각보다 삼성헬스와 빨리 동기화가 안 된다는 점이다.
이거 속도를 잘 모르겠음

동기화버튼을 눌러주자마자 바로 들어갈 때도 있고
버튼 안 눌러도 바로 들어가져있을 때도 있고
버튼을 눌러도 30분 뒤에서야 들어갈 때도 있고

음식 입력 시간도 수정되게 하고 싶은데,
또 뭔가 수정하는 폼을 넣어야 되어서 귀찮아서 담주로 미루겠다
담주에 리드미 수정할 때 추가해야지

여튼 이제 성분표 보면서 하나하나 입력 안해도 되어서 참 좋다

홍보 해볼까? 싶다가도 네이버 클라우드 가입 방법이나 ocr 사용을 위한 토큰 발급 방법이나..
가이드를 적어야되어서 고민할 게 많다.

개발을 하는 사람이면 쉽게 할 텐데 개발을 안 접해본 사람들은 아무래도 번거로우니까 걍 안 쓰실듯
이거 앱 쓴다고 가이드 읽으랴 어디 가입하랴 나같아도 걍 앱 안 쓰고 성분표 보고 하나하나 적을 것 같음 (사실 조금만 귀찮으면 되는 일이라서)

그래서 저 부분 생각하면 배포까지 욕심이 나는데 OCR이 한달에 100회까지만 무료라 아마 못할 것 같다
욕심이 많다 많아 돈이 많아지면 좋겠다

아니 왜 영상 첨부하니까 다깨지고 작아지고 ?
기록용이니까 파일 통째로 올린다

https://github.com/Hayeon-Lee/auto-health

GitHub - Hayeon-Lee/auto-health: 삼성 헬스에 등록되지 않은 음식을 편리하게 추가시켜보자

삼성 헬스에 등록되지 않은 음식을 편리하게 추가시켜보자. Contribute to Hayeon-Lee/auto-health development by creating an account on GitHub.

github.com

실행 영상.mp4

5.30MB