engineer4ever 님의 블로그

라즈베리 파이에서 UI를 구성할 때 여러 가지 선택지가 있는데, 주력 플랫폼은 크게 아래의 네 종류가 있다.

Avalonia?

1. 개요

- Avalonia는 .NET 기반의 크로스플랫폼 UI 프레임워크

- C#과 XAML로 화면을 만들며 Windows / Linux / macOS / 임베디드 리눅스에서 동일 코드로 실행

2. UI 구성 방식

- XAML 기반 레이아웃, 스타일 시스템, 데이터 바인딩을 지원해서 데스크톱 수준의 일관된 UI 구조를 만들 수 있음

3. 성능 및 렌더링

- GPU 기반 렌더러를 사용해 고해상도 환경에서도 안정적이고 빠르게 동작

4. 배포와 환경 구성

- 독립 실행 형태로 배포할 수 있어 라즈베리 파이 같은 ARM 장치에서도 설정이 단순

5. 생태계 특징

- 오픈소스이며 .NET 라이브러리들과 자연스럽게 연동됨

- 라이선스 비용 부담이 없음

Avalonia를 라즈베리 파이에서 사용하기 위한 환경 구성 절차는 다음과 같음

1. NET 런타임 설치

2. 개발 환경 구성(PC)

3. 프로젝트 빌드 및 배포 파일 생성

4. 라즈베리 파이에 배포 및 실행

1. NET 런타임 설치

- 라즈베리 파이 OS(64비트 기준)에 Microsoft 패키지 저장소를 등록한 뒤 .NET SDK 설치

- Visual Studio 2022 설치 하면 .NET SDK는 같이 설치됨

- 확장 관리자에서 Avalonia 설치(Avalonia, Avalonia Template Studio)

설치 후 dotnet --info 명령으로 ARM64 환경이 정상 인식되는지 확인

3. 프로젝트 빌드 및 배포 파일 생성

다음 명령으로 라즈베리 파이용 실행 파일을 생성

이 방식은 .NET 런타임이 포함된 독립 실행 파일을 생성하므로 파이에 별도 설치가 필요 없음

4. 라즈베리 파이에 배포 및 실행

Publish 디렉터리 전체를 라즈베리 파이에 복사한 후 실행 파일을 실행

Avalonia는 X11 또는 Wayland 환경에서 자동으로 렌더링되며, 터치 디스플레이도 기본적으로 지원됨

1. Arducam FPD-Link Camera Solution 테스트

- Raspberry Pi의 MIPI CSI-2 카메라는 센서를 보드 근처에 두는 것을 전제로 설계되었기 때문에 FPC 길이에 제한이 있음

- 기구 설계 관련하여 카메라를 보드에서 떨어진 위치에 배치해야 했음. 이를 위해 SerDes 기반 FPD-Link 를 테스트 해봐야 했고 Arducam V3Link Camera Solution을 구매함.

Arducam V3Link Camera Solution은 구성은 다음과 같음

• Arducam FPD-Link Camera
• Deserializer Board
• Coaxial Cable

1. GMSL, FPD-Link 사용 이유

임베디드·산업·자동차 시스템에서 카메라를 SoC 근처에 둘 수 없는 경우가 많은데 이때 가장 현실적인 해결책이 GMSL(Analog Devices) 과 FPD-Link(Texas Instruments).

이 두 기술은 흔히 'MIPI 연장' 이라고 말하지만, 정확히 말하면 MIPI를 장거리로 끌고 가는 기술이 아니고 본질은 카메라의 위치 제약을 제거하기 위한 SerDes 링크 구조임.

1-1. 왜 MIPI는 그대로 연장할 수 없는가

MIPI CSI-2는 애초에 다음 전제를 기반으로 설계된 인터페이스

• SoC 바로 근처에 센서 배치
• PCB 트레이스 또는 짧은 FPC 전제
• 수 cm ~ 수십 cm 이내 거리
• 케이블, 커넥터 사용 비권장

그래서 현실적으로는 다음 문제가 발생

• FPC 길이 증가 시 신호 무결성 붕괴
• 외부 케이블 사용 시 EMI, skew, eye collapse 발생
• 거리 확장은 사실상 불가능함

즉, MIPI에는 '연장'이라는 개념 자체가 없음.

1-2. SerDes 구조의 본질

GMSL과 FPD-Link는 MIPI 인터페이스가 아니라 입력 인터페이스를 직렬화하여 장거리 전송 가능한 링크로 변환하는 기술

기본 구조는 다음과 같음

2. GMSL (Gigabit Multimedia Serial Link)

2-1. 개요

• 제조사: Analog Devices(구 Maxim)
• 주요 사용처: 자동차, 고신뢰 산업 시스템
• 설계 성향: 링크 안정성, EMI 내성 우선

2-2. GMSL 대표 IC 구성

Serializer (카메라 모듈 쪽)

• MAX9295A
• MAX9296A
• MAX96717 / MAX96717F (GMSL2)
• MAX96799 (GMSL3)

대부분의 MIPI 카메라 모듈은

CMOS Sensor → MAX9295A 구조를 사용

Deserializer (SoC 보드 쪽)

• MAX96712 (4채널 멀티카메라 허브)
• MAX9296A
• MAX96722
• MAX96724 (GMSL3)

멀티카메라 시스템에서는

MAX96712가 사실상 표준

2-3. GMSL 구현 구조

2-4. GMSL 구현 절차

1. CMOS 센서 해상도, FPS, MIPI lane 수 확정
2. Serializer를 센서 출력 규격에 맞게 선택
3. Deserializer를 카메라 수 기준으로 선택
4. Bias-T 기반 PoC 회로 설계
5. I2C 제어는 SerDes 내부 터널링 사용
6. 초기화 순서는
7. Deserializer → Serializer → Sensor 필수
8. FSYNC, EQ, EMI 관련 기능은 자동 처리됨

2-5. GMSL 특성 요약

• 케이블 길이와 편차에 매우 강함
• EMI 환경에서 안정성 높음
• 멀티카메라 동기 정확함
• IC 단가와 설계 난이도는 높음

3. FPD-Link

3-1. 개요

• 제조사: Texas Instruments
• 주요 사용처: 산업용, 머신비전, 중저가 자동차
• 설계 성향: 단순성, 비용 효율성 중시함

3-2. FPD-Link 대표 IC 구성

Serializer

• DS90UB933
• DS90UB953
• DS90UB971 (FPD-Link IV)
• DS90UB925 (병렬 RGB)

Deserializer

• DS90UB960 (4채널 허브)
• DS90UB964
• DS90UB914

실무에서는

DS90UB953 + DS90UB960 조합이 가장 흔함.

3-3. FPD-Link 구현 구조

3-4. FPD-Link 구현 절차

1. 센서 출력 클럭과 lane 구조 확인
2. Serializer 선택
3. Deserializer로 카메라 수 집약
4. TI 레퍼런스 기반 PoC 회로 설계
5. I2C Alias 설정으로 주소 충돌 방지
6. Link Lock 상태 확인

3-5. FPD-Link 특성 요약

• 설정 구조 직관적
• 비용 경쟁력 있음
• 양산에 유리

EMI 성능은 PCB 레이아웃 영향 큼

4. 최종 정리

- GMSL과 FPD-Link는 서로 호환되지 않음

- Serializer와 Deserializer는 반드시 같은 계열로 구성해야 함

- 케이블이 같아도 내부 프로토콜은 완전히 다름

이 두 기술은 MIPI를 단순히 연장하는 방식이 아니라,

- 카메라의 위치 제약을 제거하기 위해 MIPI 구간을 최소화

- 장거리 구간을 SerDes 링크로 대체하는 구조

뭘 사용할지는,

- 케이블 길이

- EMI 환경

- 카메라 개수

- 비용 조건

이 네 가지에 의해 결정됨

3-1. Raspberry Pi OS Download

3-2. Raspberry Pi OS 이전 버전 Download

Raspberry Pi OS 공식적으로 이전 릴리스들을 아카이브 형식으로 보관하여 Raspberry Pi Imager에서 바로 Writing이 불가하다.

위 링크에서 원하는 버전의 View archive를 누르면 아래와 같이 이전 버전을 다운로드 할 수 있다.

1. STM32CubeIDE for VS Code

- Code editing

- Project build

- Automation

- Simplified debugging

라고 설명하고 있다.

메뉴얼이라고 만들어 놓은 pdf는 설치, 삭제만 달랑 적어놔서 사용하는데 한참 헤맴.

2. STM32CubeIDE vs STM32CubeIDE for VS Code

3. VSCode STM32CubeIDE 플러그인 설치

: VSC에서 Extension에서 STMCubeIDE 검색하여 install

: CubeCLT 설치 할 필요 없음. 필요한 파일은 위 통합팩에 다 들어있음.

4. STM32CubeMX에서 새 프로젝트 생성

VS Code에서 사용하는 여러 방법이 있겠지만 나는 아래 방법으로 하였다.

! CubeIDE에서 Toolchain 변경 안됨(하는 방법이 있긴 하나 억지로 건드려야 함)

! 결국 STM32CubeMX를 6.14.0 이후 버전을 설치(이후 버전 부터 Toolchain이 cmake 지원된다고 함)

! STM32CubeMX에서 새 프로젝트 생성

: STM32CubeMX

- MCU 선택

- Project Name, Location 입력, Toolchain → CMake 선택

- 기본 설정 & GENERATE CODE

: VS Code

- File - Open Folder... - 위에서 만든 폴더 오픈

- 하단 우측에 메시지가 뜨는데 'Bad CMake~'는 무시하고 아래의 'Would you like to configure discovered CMake project(s) as STM32Cube project(s)'는 Yes 클릭

- 하단의 Build 클릭

- Debug or Release 어느것으로 Build할껀지 선택 하여 Build

- 좌측 Run and Debug를 클릭해 STLink 확인(STLink를 연결한 상태)

- ST-Link Firmware 업그레이드

- 하단 우측에 'Successfully updated STLink Firmware' 메시지 확인

- STM32Cube:STLink GDB Server 클릭

- Build 성공 후, Debugger 연결이 안되서 STM32CubeProgrammer로 Download해 Build 확인 완료.

기존 방법들의 단점:

• SSH (PuTTY): 빠르지만 VI/NANO 같은 터미널 에디터만 사용 가능 → 불편함
• 원격 제어 (VNC, XRDP): GUI 사용 가능하지만 느리고 딜레이 심함

VSCode + Remote-SSH 방식:

• GUI 환경에서 편집 가능
• 빠른 속도 (SSH 기반)
• 파일/디렉터리 한눈에 확인
• 무료 (Microsoft 개발)

: Terminal 열어 ifconfig로 ip 확인

2. VSCode 다운로드 및 설치

https://code.visualstudio.com/

1. Gemini Code Assist 설치

: Visual Studio Code가 설치 되어 있어야 한다.(이하 VSC)

: VSC에서 Extension에서 Gemini Code Assist를 검색하여 install

2-2. 왼쪽 다이아몬드 모양을 누르면 아래와 같이 사용 가능

2-1. GitHub 계정 연결

: 상단 중앙 또는 하단의 개구리 모양(고글 쓴 로봇)을 누르면 사용 가능

Sign in to use Copilot for free 버튼을 클릭하여 Github 계정 연결.

GitHub 계정이 있으면 연결

없으면 Create an account 버튼 눌러서 계정 생성

2-2. GitHub Copilot 설정

: Copilot in GitHub.com → Enabled

: Copilot in GitHub Desktop → Enabled

최근 이런 생각이 들었다.

내가 선택해 쓰는 프로그래밍 언어(이하 언어)와 프레임워크, 앞으로도 살아남을 수 있을까?

서서히 사라져가는 기술에 시간을 쓰는건 아닐까?

예전에는 플랫폼 마다 언어가 거의 정해져 있었다.

- PC나 서버에서는 Java, C#, Python 같은 범용 언어들이 주로 사용됐고,

- 센서나 장비 위에서는 C나 C++ 같은 임베디드 전용 언어가 사용됐다.

하지만 지금은 상황이 다르다.

- 라즈베리 파이 같은 고성능 보드에서는 Python도 돌아가고,

- Rust나 MicroPython처럼 PC와 임베디드 경계를 넘나드는 언어도 등장했다.

PC와 임베디드의 기술의 경계가 흐려졌고, 선택지도 많아졌다.

기술을 고를 수 있는 폭은 넓어졌지만, 그만큼 ‘오래가지 않는 기술’을 고를 위험도 커졌다.

유지보수가 끊긴 프레임워크, 구인 시장에서 사라진 언어들.

그럴 때마다 생각하게 된다.

최근 몇 년간 어떤 언어가 올라가고, 어떤 언어가 내려갔는지 살펴봤다.

내가 자주 보거나 써온 언어들을 중심으로 정리해보니 이런 흐름이 보였다

• Python, JavaScript, TypeScript, Rust는 꾸준히 올라오고 있음
• Java와 C#은 한때 압도적인 점유율을 보였지만 천천히 하락 중
• Go는 클라우드, 인프라 분야에서 안정적인 위치를 유지하고 있음

요즘 인기 있다는 이유로 언어를 쉽게 바꾸고 싶진 않다.

하지만 적어도, 앞으로도 살아남을 기술에 시간을 쓰고 싶다.

내가 쓰는 언어가 그냥 ‘지금 당장 되는 기술’인지,

아니면 몇 년 뒤에도 여전히 쓸 수 있을 기술인지

한 번쯤 점검할 필요가 있다.

프로그래밍 언어는 결국 도구다.

하지만 그 도구가 나의 커리어 방향을 정하기도 한다.

눈앞의 편리함만 쫓지 말고, 지금 내가 타고 있는 흐름이 어디로 향하는지도 같이 봐야 한다고 생각한다.

2. Claude Desktop : json 파일 편집

설정 - 개발자 - 로컬 MCP 서버 - 구성 편집

3. Claude Desktop : claude_desktop_config.json 파일 편집

2번에서 생성한 개인 토큰을 아래 편집 파일의 your-integration-token에 대체

4. Claude Desktop 완전 종료 후 재실행

running 되었음 확인 가능

A. Claude + Figma (직접 통합)

• 기능 : Figma에서 직접 디자인 생성
• 작업 방식 : Figma 플랫폼 내에서 Claude의 도움을 받아 디자인 작업 수행
• 특징 : 실시간 디자인 생성 및 편집 가능

명령어 예시

사용자 :

"우리 모바일 앱 프로젝트 Figma 파일에서 로그인 화면 컴포넌트를 찾아서, 그 디자인을 분석하고 HTML/CSS로 구현해줘."

Claude :

"죄송하지만 Figma 파일에 직접 접근할 수 없습니다. 대신 다음과 같은 방법으로 도움을 드릴 수 있습니다: 1. Figma에서 로그인 화면을 스크린샷으로 찍어서 공유해 주세요

2. 또는 Figma의 "Copy as CSS" 기능을 사용한 코드를 붙여넣어 주세요

3. 디자인 스펙(색상, 폰트, 크기 등)을 텍스트로 알려주세요 그러면 그 정보를 바탕으로 HTML/CSS 코드를 작성해드리겠습니다."

B. Claude + Figma MCP Server (서버 기반 통합)

• 기능 : Claude에서 Figma 관련 작업 요청 및 처리
• 작업 방식 : Claude 인터페이스에서 "Figma로 안내문 작성해줘"와 같은 자연어 명령으로 Figma 작업 수행
• 특징:
  • Claude 환경에서 직접 Figma 파일 데이터 조회
  • Figma 이미지 및 에셋 다운로드
  • 자연어를 통한 직관적인 디자인 작업 지시

명령어 예시

사용자 :

"우리 모바일 앱 프로젝트 Figma 파일에서 로그인 화면 컴포넌트를 찾아서, 그 디자인을 분석하고 HTML/CSS로 구현해줘."

와 같이 가능해짐.

Claude(클로드)에 Figma MCP Server 연결

0. 사전 준비 사항 : Claude Desktop 설치

https://claude.ai/download

1. 코드 복사 : 다음 링크에서 Mac 또는 Windows용 코드를 복사

2. Figma Web : 개인 토큰 생성

Profile - Settings - Security 탭 - Generate new tokens

3. Figma Web : 개인 토큰 생성 및 복사

(절대 남에게 공개 하면 안됨)

4. Claude Desktop : json 파일 편집

설정 - 개발자 - 로컬 MCP 서버 - 구성 편집

5. Claude Desktop : claude_desktop_config.json 파일 편집

3번에서 생성한 개인 토큰을 아래 편집 파일의 YOUR-KEY에 대체

6. Claude Desktop 완전 종료 후 재실행

running 되었음 확인 가능