azmo/IR_test_firmware
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update firmware

Browse Source
This commit is contained in:
Dongubak
2026-08-22 19:14:55 +09:00
parent f75318d889
commit 226b081aee
11 changed files with 887 additions and 149 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/readme.md
+362 -100
View File
@@ -1,16 +1,39 @@
# IR 광신호 Mock 프로토타입 설계 정리
**대상 과제:** IR 광신호 기반 무선 토양수분 센서 (농촌진흥청 국립원예특작과학원)
**본 문서 범위:** 센서 미개발 상태에서 온도·습도 mock 신호를 IR LED로 송출하고 카메라로 인식하는 벤치 프로토타입
**본 문서 범위:** 격자 지점별 LED 블링크 횟수를 카메라로 카운트하는 벤치 프로토타입
**작성 기준일:** 2026-08-22
**개정:** rev.2 — 온·습도 비트 인코딩 → **습도 단일 값, 블링크 카운트 방식**으로 변경
**구현 상태:** 7장의 펌웨어가 저장소에 구현되고 빌드 검증까지 완료됨(2026-08-22). CubeMX 생성 결과와 설계 간 불일치 2건을 구현 중 발견·수정 — [6.7절](#67-cubemx-생성-결과-검증-중-발견된-오차) 참조.
---
## 1. 프로토타입 목표
각 식물 팟에 온·습도 센서가 내장되고, 그 값을 IR LED 광신호로 변환해 외부 카메라가 판독하는 시스템을 검증한다. 실제 센서가 아직 없으므로 **MCU가 결정적 패턴의 mock 값을 생성**하여 송출하고, 카메라 측 디코더가 이를 정확히 복원하는지 확인하는 것이 이번 단계의 목적이다.
각 식물 팟에 습도 센서가 내장되고, 그 값을 IR LED 광신호로 변환해 외부 카메라가 판독하는 시스템을 검증한다.
배터리 수명, 방수, 양산성은 **본 단계에서 고려하지 않는다.**
**본 단계에서 검증하는 것은 값의 의미가 아니라 계수(計數)의 신뢰성이다.**
- 실제 습도값은 사용하지 않는다
- 온도는 다루지 않는다
- 카메라가 **격자 각 지점의 깜박임 횟수를 정확히 세는지**만 확인한다
배터리 수명, 방수, 양산성은 본 단계에서 고려하지 않는다.
### 1.1 카운트 방식을 채택한 의의
비트 인코딩 대비 이점이 분명하다.
| 항목 | 비트 인코딩 | 블링크 카운트 |
|---|---|---|
| 프레임 정렬 | 심볼 경계 판정 필요 | **불필요** |
| 임계값 | 비트마다 판정 | 지점마다 1회 |
| 프레임 누락 | 심볼 전체 손실 | 상태 유지 구간이 길어 영향 미미 |
| 검증 대상 | 광학계 + 프로토콜 혼재 | **광학계만 순수 분리** |
이번 단계에서 알고 싶은 것은 "카메라가 9개 지점을 안정적으로 분리 해상하고 각 지점의 시간적 상태를 추적할 수 있는가"이다. 카운트 방식은 프로토콜 계층을 걷어내고 이 질문에만 답한다.
또한 **고정 창(window) 내의 카운트는 곧 주파수**이므로, 제안서의 1~6Hz 주파수 변조 방식으로 자연스럽게 확장된다. 버린 설계가 아니라 하위 단계다.
---
@@ -22,7 +45,8 @@
| LED | Siemens LD274 (950nm) × 9 | 기 확보, 추후 변경 예정 |
| 카메라 필터 | 950nm, C 마운트 | LD274 피크 파장과 정합 |
| 셔터 방식 | 글로벌 셔터 | 확인 완료 |
| 인코딩 | 공간 병렬 (3×3 동시) | 벤치 환경이라 분리 해상 가능 |
| 격자 구성 | 3×3, 9개 지점 | 각 지점이 팟 1개에 대응 |
| 전송 방식 | **지점별 블링크 카운트** | 본 개정 |
| 구동 방식 | GPIO 오픈 드레인 직결 | 근거리라 저전류로 충분 |
| 테스트 거리 | 1 ~ 1.5 m | 블롭 분리 여유 확보 |
@@ -47,6 +71,8 @@
| 패키지 | 5 mm (T-1 3/4), 지름 5.1 mm |
| 스위칭 시간 t_r, t_f | 1 µs |
스위칭 시간 1 µs는 본 설계의 200 ms 상태 유지 시간 대비 5자리수 여유이므로 전혀 제약이 되지 않는다.
### 3.2 파장 정합 — 양호
950nm 필터와 LD274의 950nm 피크가 일치한다. 스펙트럼 폭 55nm를 감안해도 에너지가 대략 920~990nm에 몰려 있어 필터 통과에 문제가 없다.
@@ -81,7 +107,7 @@ LD274는 TV 리모컨용으로 설계된 협각 부품이다. 방사 특성상
### 4.1 구동 전류 및 저항 산출
벤치 1m 환경에서는 오히려 **과다 광량이 문제**가 된다. 포화된 블롭이 번지면(blooming) 인접 LED와 뭉쳐 공간 병렬 인코딩이 깨진다.
벤치 1m 환경에서는 오히려 **과다 광량이 문제**가 된다. 포화된 블롭이 번지면(blooming) 인접 지점과 뭉쳐 격자 분리가 깨진다.
```
목표 전류: 6 mA
@@ -110,6 +136,8 @@ STM32L073 GPIO는 정규 스펙에서 핀당 ±8 mA, 비정규 V_OL/V_OH를 감
전체 I/O 합산 전류(ΣI_VSS) 한계는 데이터시트 절대최대정격 표에서 확인할 것.
**카운트 방식의 부수적 이점:** 지점마다 카운트가 다르므로 9개가 동시에 켜져 있는 순간은 첫 번째 블링크뿐이고, 이후로는 켜진 개수가 점차 줄어든다. 평균 전류가 최대치보다 낮다.
### 4.3 전원 경로
LED 전류를 Nucleo의 3.3V 핀에서 뽑는 것은 무방하나(54mA 수준), 향후 전류를 크게 올릴 경우 주의가 필요하다.
@@ -148,67 +176,129 @@ VDD 3.3V ──┬── LED(애노드) ... LED(캐소드) ── 330Ω ── P
---
## 5. 프로토콜 설계
## 5. 프로토콜 설계 — 블링크 카운트
### 5.1 비트 배치
### 5.1 격자 지점 매핑
| 위치 | 핀 | 역할 |
각 핀은 격자 한 지점(팟 1개)에 대응한다. 비트 자리가 아니라 **독립된 측정 지점**이다.
| 격자 위치 | 핀 | 지점 번호 |
|---|---|---|
| 중앙 | PC0 | **토글 클록** |
| 상단 좌 | PC1 | 온도 b3 (MSB) |
| 상단 중 | PC2 | 온도 b2 |
| 상단 우 | PC3 | 온도 b1 |
| 중단 좌 | PC4 | 온도 b0 (LSB) |
| 중단 우 | PC5 | 습도 b3 (MSB) |
| 하단 좌 | PC6 | 습도 b2 |
| 하단 중 | PC7 | 습도 b1 |
| 하단 우 | PC8 | 습도 b0 (LSB) |
| 상단 좌 | PC0 | G1 |
| 상단 중 | PC1 | G2 |
| 상단 우 | PC3 | G3 |
| 중단 좌 | PC4 | G4 |
| 중단 중 | PC5 | G5 |
| 중단 우 | PC6 | G6 |
| 하단 좌 | PC7 | G7 |
| 하단 중 | PC8 | G8 |
| 하단 우 | PC2 | G9 |
온도 4비트(16단계) + 습도 4비트(16단계) + 클록 1비트 = 9비트.
이전 개정에서 PC0에 부여했던 토글 클록 역할은 **폐지**한다. 카운트 방식에서는 사이클 사이의 소등 구간이 그 역할을 대신하며, 9개 핀 전부를 데이터 지점으로 쓸 수 있다.
### 5.2 PC0의 역할: 토글 클록
> **구현 노트:** 최초 CubeMX 생성 프로젝트는 G3~G8을 PC3~PC8에 배정하며 PC2를 비워둔 채였다(8지점만 구성됨, [6.7절](#67-cubemx-생성-결과-검증-중-발견된-오차)). 기존 G1~G8 배선을 그대로 두고 남은 PC2를 G9로 채워 9지점을 완성했다 — 핀 번호 순서상 G9가 G2와 G3 사이에 위치하지만, 격자 물리 배치와 핀 번호는 애초에 무관하므로 기능·회로에는 영향이 없다.
글로벌 셔터가 확정되면서 롤링 셔터 대비용 동기 LED는 불필요해졌다. PC0을 **심볼마다 반전하는 토글 클록**으로 재배정한다.
검토했던 대안과 비교:
| 후보 | 얻는 것 | 잃는 것 |
|---|---|---|
| **토글 클록 (채택)** | 심볼 경계 검출, 누락 심볼 감지, 링크 생존 확인 | 고정 밝기 기준 없음 |
| 상시 점등 기준 | 자동 임계값 산출, ROI 앵커 | 경계·누락 미검출 |
| 패리티 | 단일 비트 오류 검출 | 위 둘 다 불가 |
채택 이유: 다수결 디코딩과 궁합이 좋다. 클록 전환 시점이 곧 심볼 경계이므로, 디코더는 전환 사이의 프레임만 모아 투표하면 되고 경계 프레임을 따로 판정할 필요가 없다.
밝기 임계값은 9개 중 켜진 LED들의 밝기 분포에서 얻을 수 있어 별도 기준 LED가 없어도 무방하다.
### 5.3 심볼 타이밍
**심볼 주기 200 ms (30fps 기준 6프레임)**
MCU와 카메라는 서로 독립적으로 동작한다. 노출 창 한가운데서 심볼이 바뀌면 전환된 LED들이 중간 밝기로 찍힌다. 글로벌 셔터라 9개가 균일하게 이상해질 뿐, 값 자체는 무효다.
### 5.2 사이클 구조
```
심볼 N (200ms) │ 심볼 N+1 (200ms)
[F][F][F][F][F] [X] │ [F][F][F][F][F]
↑
경계 걸침 프레임 1개만 폐기
├──────────── 버스트 구간 6.0 s ────────────┤├── 소등 2.0 s ──┤
│ │ │
G1 ▇▁▇▁▇▁ │ │ (3회)
G2 ▇▁▇▁▇▁▇▁▇▁ │ │ (5회)
G3 ▇▁ │ │ (1회)
... │ │
G9 ▇▁▇▁▇▁▇▁▇▁▇▁▇▁▇▁▇▁▇▁▇▁▇▁▇▁▇▁▇▁ │ │ (15회)
│ │
└──────────────── 1 사이클 = 8.0 s ─────────────────────────────┘
```
최악의 경우에도 **6프레임 중 5프레임이 유효**하므로 다수결로 뽑으면 오류율이 사실상 0이 된다. 요구 갱신 주기가 시간당 1회임을 감안하면 초당 5심볼은 과도한 속도이며, 남는 속도를 전부 신뢰성으로 환산하는 설계다.
**모든 지점이 동시에 시작하고, 각자의 카운트만큼 깜박인 뒤 소등한다.** 시작 시각이 같으므로 디코더가 사이클 경계를 잡기 쉽다.
### 5.3 타이밍 파라미터
| 항목 | 값 | 30 fps 기준 |
|---|---|---|
| 틱(상태 유지) 주기 | 200 ms | 6 프레임 |
| 블링크 1회 (점등+소등) | 400 ms | 12 프레임 |
| 블링크 주파수 | 2.5 Hz | — |
| 최대 카운트 | 15회 | — |
| 버스트 구간 | 6.0 s (30 틱) | 180 프레임 |
| 소등 구간 | 2.0 s (10 틱) | 60 프레임 |
| **사이클 전체** | **8.0 s (40 틱)** | 240 프레임 |
### 5.4 왜 200 ms인가
**프레임 여유가 결정 요인이다.**
| 프레임레이트 | 상태당 프레임 수 | 판정 |
|---|---|---|
| 30 fps | 6 | 여유 |
| 15 fps (저조도 자동 강등) | 3 | 최소 허용 |
| 10 fps | 2 | 위험 |
상태당 최소 3프레임을 확보해야 경계 프레임 1개를 버려도 판정이 가능하다. 200 ms는 카메라가 15 fps로 떨어지더라도 살아남는 값이다.
나이퀴스트 한계(30 fps → 15 Hz)만 보면 훨씬 빠르게 가도 될 것 같지만, **한계 근처에서는 프레임 하나만 밀려도 카운트가 틀어진다.** 요구 갱신 주기가 시간당 1회이므로 속도를 버리고 여유를 사는 것이 옳다.
### 5.5 사이클 길이 8초의 의미
제안서 4.가의 "신호 송출 지속 시간 1회 구동당 8초"와 일치시켰다. 프로토타입 결과를 제안서 수치로 그대로 인용할 수 있다.
또한 6초 버스트 안의 최대 15회는 **2.5 Hz**이고, 제안서의 1~6 Hz 대역과 같은 스케일이다. 카운트 방식에서 주파수 변조 방식으로 넘어갈 때 타이밍 재설계가 필요 없다.
### 5.6 분해능
카운트 1~15의 15단계. 제안서 4.나의 "수분 0~70% 구간 5% 단위 14단계"와 정합한다.
카운트 0은 사용하지 않는다. 0은 "소등"과 구분되지 않아 **고장난 지점과 값이 0인 지점을 혼동**하게 되기 때문이다. 최소 1회는 반드시 깜박이게 하여, 한 번도 깜박이지 않은 지점은 이상으로 판정한다.
---
## 6. CubeMX 설정
### 6.1 클록
### 6.1 Clock Configuration
| 항목 | 값 |
CubeMX 신규 프로젝트의 기본값은 **MSI 2.097 MHz**다. 이 상태로 타이머 값을 넣으면 주기가 7.6배 느려지는데, **에러 없이 조용히 느려지기 때문에** 발견이 늦어진다. 반드시 확인할 것.
**변경 지점: System Clock Mux → HSI 16 선택 (한 곳)**
나머지는 기본값 `/1`이 그대로 맞으므로 손대지 않는다.
| 항목 | 설정값 |
|---|---|
| RCC | HSI16, PLL 미사용 |
| System Clock Mux | **HSI** |
| SYSCLK | 16 MHz |
| AHB Prescaler | /1 → HCLK 16 MHz |
| APB1 Prescaler | /1 → PCLK1 16 MHz |
| **APB1 timer clocks** | **16 MHz (배율 X 1)** |
| APB2 Prescaler | /1 |
| HSI RC 분주 (HSI16DIVEN) | /1 |
| USART2 Source Mux | PCLK1 |
| USART2CLK | 16 MHz |
| Flash Latency | 0 WS (자동) |
| Power Regulator | Range 1 (자동) |
프로토타입이므로 LPTIM·RTC·저전력 모드는 설정하지 않는다.
**"Resolve Clock Issues" 버튼이나 HCLK 직접 입력은 피할 것.** CubeMX가 PLL 경로를 자동으로 잡아 불필요하게 PLL을 켜는 경우가 있다. Mux를 직접 클릭하는 편이 의도한 경로를 보장한다.
#### 타이머 2배 규칙
```
APB 분주 = 1 → 타이머 클록 = PCLK (16 MHz)
APB 분주 ≠ 1 → 타이머 클록 = PCLK × 2 (자동 2배)
```
APB1을 `/1`로 고정하면 이 규칙을 생각할 필요가 없다. 클록 트리의 `X 1` 표시가 확인 지점이다.
#### MSI가 아닌 HSI16을 쓰는 이유
전력이 무관한 프로토타입이므로 판단 기준은 정확도뿐이다.
| 클록원 | 정확도 | UART 115200 오차 |
|---|---|---|
| MSI 2.097 MHz | ±3% 이상 | USARTDIV 18.2 → 18, 약 1.1% + 클록 오차 |
| **HSI16** | ±1% 수준 | USARTDIV 138.9 → 139, **-0.08%** |
UART는 누적 오차 2.5% 부근에서 깨진다. **로그가 이번 테스트의 검증 수단**이므로 여기서 여유를 확보해야 한다.
### 6.2 GPIO (PC0 ~ PC8)
@@ -222,9 +312,9 @@ MCU와 카메라는 서로 독립적으로 동작한다. 노출 창 한가운데
**User Label:**
```
PC0 → CLK
PC1 → T3 PC2 → T2 PC3 → T1 PC4 → T0
PC5 → H3 PC6 → H2 PC7 → H1 PC8 → H0
PC0 → G1 PC1 → G2 PC2 → G9
PC3 → G3 PC4 → G4 PC5 → G5
PC6 → G6 PC7 → G7 PC8 → G8
```
`GPIO output level`을 High로 두는 것이 가장 실수하기 쉬운 지점이다. 푸시풀 습관대로 Low를 넣으면 리셋 직후부터 LED가 켜진 채로 있게 된다.
@@ -242,9 +332,15 @@ PC5 → H3 PC6 → H2 PC7 → H1 PC8 → H0
| 타이머 | TIM6 |
| Prescaler | 15999 |
| Counter Period (ARR) | 199 |
| 결과 주기 | 200 ms |
| 결과 주기 | **200 ms** |
| NVIC | TIM6 global interrupt 활성화 |
```
f_TIM6 = 16,000,000 Hz
카운터 클록 = 16,000,000 / (15999+1) = 1,000 Hz
주기 = (199+1) / 1,000 = 0.200 s
```
TIM6를 선택한 이유는 기본 타이머(Basic Timer)라 GPIO 대체 기능을 전혀 점유하지 않기 때문이다. **PC6~PC8은 TIM3 채널과 겹치므로 TIM3는 사용하지 않는다.**
### 6.5 UART
@@ -252,89 +348,234 @@ TIM6를 선택한 이유는 기본 타이머(Basic Timer)라 GPIO 대체 기능
| 항목 | 값 |
|---|---|
| USART2 | Asynchronous, 115200 8N1 |
| 용도 | 송출값 로그 (ST-LINK VCP 경유) |
| 용도 | 사이클별 정답 카운트 로그 (ST-LINK VCP 경유) |
**이 로그가 핵심이다.** MCU가 "지금 온도 N, 습도 M을 송출했다"를 시리얼로 찍어주면 카메라 디코더 결과와 대조하여 에러율을 정량화할 수 있다. 이것이 없으면 디코더 오류인지 광학계 오류인지 구분할 수 없다.
**이 로그가 핵심이다.** MCU가 사이클마다 "G1=3, G2=5, …"를 찍어주면 디코더 결과와 대조하여 지점별 에러율을 정량화할 수 있다. 이것이 없으면 디코더 오류인지 광학계 오류인지 구분할 수 없다.
### 6.6 (선택) MCO — 클록 실측용
MCO Source Mux를 SYSCLK에 두고 **PA8을 RCC_MCO로 활성화, 분주 `/16`** 으로 설정하면 PA8에 정확히 **1 MHz**가 나온다.
```
16 MHz / 16 = 1.000 MHz
```
`HAL_RCC_GetSysClockFreq()`는 레지스터 설정값을 계산한 것이라 **실제 발진 주파수를 검증하지 못한다.** MCO는 물리적 증거를 준다. PA8은 CN9의 D7에 나와 있고 PC0~PC8과 충돌하지 않는다. 브링업 1회 측정 후 꺼도 무방하다.
### 6.7 CubeMX 생성 결과 검증 중 발견된 오차
7장 펌웨어를 실제 코드에 적용하는 과정에서 `.ioc`가 생성한 `gpio.c`를 본 문서의 6.2절 스펙과 대조한 결과, 두 가지가 어긋나 있었다. 둘 다 `.ioc`와 `gpio.c`/`main.h`에서 함께 고쳐 CubeMX로 재생성해도 유지되도록 했다.
| 항목 | CubeMX 생성 결과 | 문제 | 조치 |
|---|---|---|---|
| GPIO output level 초기값 | `GPIO_PIN_RESET` (Low) | 오픈 드레인에서 Low = 점등이므로, **리셋 직후 9개 LED가 전부 켜진 채로 부팅**된다. 6.2절이 "가장 실수하기 쉬운 지점"으로 미리 경고한 바로 그 실수 | `GPIO_PIN_SET` (High)으로 수정 |
| 지점 수 | G1~G8 (PC0, PC1, PC3~PC8) 8개만 구성, **PC2 미사용** | 3×3=9지점 설계와 불일치. PC2가 비어 연속 배치가 깨지므로 7.2절이 전제하는 BSRR 단일 쓰기 방식도 그대로는 성립하지 않음 | PC2를 G9로 추가해 PC0~PC8 9핀 연속 배치 완성 (기존 G1~G8 배선은 유지 — 상세는 [5.1절 구현 노트](#51-격자-지점-매핑)) |
두 항목 모두 최초 CubeMX 프로젝트 생성 시점(설계 확정 이전)의 산출물이 그대로 남아 있던 것으로 보이며, 이번 구현 작업 중 발견했다.
---
## 7. 펌웨어
### 7.1 전체 코드
아래 코드는 [`Core/Src/main.c`](../Core/Src/main.c)에 CubeMX의 `USER CODE BEGIN/END` 구획을 따라 그대로 구현되어 있다 (재생성 시에도 보존됨). 실제 배치는 매크로·전역변수 → `PV`, `load_counts`/`drive`/`__io_putchar` → `0`, `HAL_TIM_PeriodElapsedCallback` → `4`, 초기 구동 호출 → `main()`의 `2` 구획이다. `app_start()`는 설명용 표기이며 실제로는 별도 함수로 분리하지 않고 `main()`의 해당 구획에 인라인되어 있다.
```c
#define LED_MASK 0x01FFu
#define BIT_CLK 0x0001u /* PC0 */
#define LED_MASK 0x01FFu /* PC0..PC8 */
#define N_POINTS 9
#define COUNT_MIN 1
#define COUNT_MAX 15
#define TICKS_BURST 30 /* 15회 × 2틱 = 6.0 s */
#define TICKS_IDLE 10 /* 2.0 s */
#define TICKS_CYCLE (TICKS_BURST + TICKS_IDLE)
static uint8_t clk_state = 0;
static uint8_t mock_t = 0, mock_h = 0;
static uint16_t tick = 0;
static uint16_t cycle = 0;
static uint8_t cnt[N_POINTS]; /* 지점별 목표 블링크 횟수 */
static void emit(uint8_t t4, uint8_t h4, uint8_t clk)
/* 결정적 회전 패턴: 지점마다 다른 값, 사이클마다 1씩 이동 */
static void load_counts(void)
{
uint16_t bits = 0;
if (clk) bits |= BIT_CLK;
bits |= (uint16_t)(t4 & 0x0F) << 1; /* PC1..PC4 */
bits |= (uint16_t)(h4 & 0x0F) << 5; /* PC5..PC8 */
for (uint8_t k = 0; k < N_POINTS; k++) {
cnt[k] = (uint8_t)(((cycle + k) % COUNT_MAX) + COUNT_MIN);
}
}
static void drive(uint16_t bits)
{
/* 오픈 드레인: 0 = 점등이므로 반전. 9핀 원자적 동시 전환 */
GPIOC->BSRR = ((uint32_t)(bits & LED_MASK) << 16)
GPIOC->BSRR = ((uint32_t)( bits & LED_MASK) << 16)
| ((uint32_t)(~bits & LED_MASK));
}
/* printf -> USART2 (ST-LINK VCP). syscalls.c의 weak _write()가 문자마다 호출한다. */
int __io_putchar(int ch)
{
HAL_UART_Transmit(&huart2, (uint8_t *)&ch, 1, HAL_MAX_DELAY);
return ch;
}
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
if (htim->Instance != TIM6) return;
clk_state ^= 1;
emit(mock_t, mock_h, clk_state);
uint16_t bits = 0;
printf("T=%2u H=%2u CLK=%u\r\n", mock_t, mock_h, clk_state);
/* 버스트 구간의 짝수 틱에서만 점등.
지점 k의 j번째 블링크는 틱 2j(점등) / 2j+1(소등)을 점유 */
if (tick < TICKS_BURST && (tick & 1u) == 0u) {
for (uint8_t k = 0; k < N_POINTS; k++) {
if (tick < (uint16_t)cnt[k] * 2u) {
bits |= (uint16_t)(1u << k);
}
}
}
drive(bits);
/* 결정적 스윕: 온도는 매 심볼, 습도는 16심볼마다 */
mock_t = (mock_t + 1) & 0x0F;
if (mock_t == 0) mock_h = (mock_h + 1) & 0x0F;
if (++tick >= TICKS_CYCLE) {
tick = 0;
cycle++;
load_counts();
printf("CYCLE=%u G:", cycle);
for (uint8_t k = 0; k < N_POINTS; k++) printf(" %2u", cnt[k]);
printf("\r\n");
}
}
/* main()의 while 루프 진입 전 */
void app_start(void)
{
load_counts();
drive(0); /* 전 지점 소등 */
HAL_TIM_Base_Start_IT(&htim6);
}
```
### 7.1 BSRR 직접 사용
### 7.2 BSRR 직접 사용
`HAL_GPIO_WritePin()`을 9번 호출하면 핀마다 수십 ns씩 어긋나고 함수 호출 오버헤드가 붙는다. BSRR 직접 쓰기는 원자적 1사이클 연산이다.
### 7.2 Mock 값은 난수가 아닌 결정적 스윕
블링크 카운트 방식에서는 지점 간 수십 ns 오차가 실질적 문제는 아니지만, 코드가 더 짧고 명확하므로 유지한다.
온도가 매 심볼 1씩 증가하므로, 디코더가 `0, 1, 2, 4, 5`를 출력하면 **3을 놓쳤다는 사실이 즉시 드러난다.** 난수 mock으로는 알 수 없는 정보다.
### 7.3 Mock 값은 난수가 아닌 결정적 회전
- 전체 주기: 온도 16 × 습도 16 = 256 심볼 = **51.2초**
- 1분 녹화로 전 조합 커버리지 확보
`cnt[k] = ((cycle + k) % 15) + 1`
| 사이클 | G1 | G2 | G3 | … | G9 |
|---|---|---|---|---|---|
| 1 | 1 | 2 | 3 | … | 9 |
| 2 | 2 | 3 | 4 | … | 10 |
| 3 | 3 | 4 | 5 | … | 11 |
| … | | | | | |
| 15 | 15 | 1 | 2 | … | 8 |
**이 패턴이 주는 것:**
- 한 사이클 안에서 9개 지점이 **전부 다른 값**을 가지므로, 디코더가 지점을 혼동하면 즉시 드러난다
- 사이클마다 값이 1씩 이동하므로 **특정 지점만 계속 틀리는지**(위치 의존 오류) 판별 가능
- 15 사이클 = **120초**면 모든 지점이 모든 카운트를 한 번씩 경험한다
난수 mock으로는 이 중 어느 것도 알 수 없다.
### 7.4 printf 리다이렉트
`syscalls.c`(CubeMX 생성)는 `_write()`가 문자 단위로 `__io_putchar()`를 호출하도록 이미 `weak` 참조를 걸어두고 있으나, 정작 `__io_putchar()` 본체는 어디에도 정의돼 있지 않았다. `main.c`에 `HAL_UART_Transmit(&huart2, ...)`으로 구현해 연결했다 (7.1절 코드 참조).
빌드는 newlib-nano(`--specs=nano.specs`)를 링크하므로 `_write()` 경로가 실제로 사용된다. `__io_putchar()`는 `weak extern`으로 선언돼 있어 정의가 없어도 링크 자체는 성공하지만, 그 상태에서 `printf()`를 호출하면 널 포인터를 호출하는 셈이라 하드폴트로 즉시 정지한다 — "링크되니 괜찮겠지"로 넘어가면 안 되는 지점이다.
### 7.5 빌드 검증
```
RAM: 2224 B / 20 KB (10.86%)
FLASH: 17232 B / 192 KB (8.76%)
```
**툴체인 주의:** Homebrew의 `arm-none-eabi-gcc`는 newlib 헤더(`stdint.h` 등)가 빠져 있어 `stm32l0xx_hal_tim.c` 등 표준 헤더를 include하는 모든 파일에서 빌드가 실패한다. STM32CubeCLT에 포함된 `GNU-tools-for-STM32`(`/opt/ST/STM32CubeCLT_*/GNU-tools-for-STM32/bin`)를 PATH에 우선 배치해야 한다. `cmake/gcc-arm-none-eabi.cmake`는 `arm-none-eabi-gcc`를 PATH에서만 찾으므로 툴체인 파일 수정 없이 PATH 순서만으로 해결된다.
```
export PATH="/opt/ST/STM32CubeCLT_*/GNU-tools-for-STM32/bin:$PATH"
cmake --preset Debug
cmake --build build/Debug
```
---
## 8. 카메라 설정 — 반드시 수동 고정할 항목
## 8. 디코더 설계 지침
### 8.1 ROI 자동 검출
버스트 구간에서는 모든 지점이 최소 1회 점등하므로, **버스트 구간 프레임들의 최대값 투영(max projection)** 을 취하면 9개 블롭이 한 장에 모두 나타난다.
```
roi_map = max(frame[t] for t in burst_window)
→ 임계값 이진화 → 연결 요소 라벨링 → 9개 중심 좌표
```
수동 ROI 지정보다 안정적이고, 격자가 흔들려도 사이클마다 재계산할 수 있다.
### 8.2 사이클 경계 검출
소등 구간 2.0초(60프레임)는 어떤 블링크 간격(200ms, 6프레임)보다 압도적으로 길다. **전 ROI가 동시에 어두운 상태가 30프레임 이상 지속되면 사이클 경계**로 판정한다.
### 8.3 카운트 산출
지점마다 독립적으로 처리한다.
1. ROI 내 픽셀 밝기 평균 → 시계열
2. 임계값으로 이진화 (임계값은 해당 지점의 min/max 중간값)
3. **상승 에지(off→on) 개수**를 센다
4. 각 on/off 구간이 3프레임 미만이면 노이즈로 간주하고 병합
3번에서 하강 에지가 아닌 상승 에지를 세는 이유는, 버스트 종료 후 소등 상태가 이어지므로 마지막 하강 에지가 사이클 경계와 겹칠 수 있기 때문이다.
### 8.4 검증 지표
| 지표 | 산출 |
|---|---|
| 지점별 정확도 | (일치 사이클 수) / (전체 사이클 수), 9개 각각 |
| 카운트별 정확도 | 카운트 1~15별로 집계 — 큰 값에서 오류가 느는지 확인 |
| 오류 방향 | 과소 계수(블링크 놓침) vs 과다 계수(노이즈) 구분 |
**과소 계수가 많으면** 노출 부족 또는 임계값이 높음. **과다 계수가 많으면** blooming으로 인접 지점 간섭 또는 임계값이 낮음. 오류의 방향이 곧 조치 방향이다.
---
## 9. 카메라 설정 — 반드시 수동 고정할 항목
여기서 실패하는 경우가 많다.
| 항목 | 조치 | 이유 |
|---|---|---|
| 자동 노출 (AE) | **끄기** | LED 점멸마다 노출이 요동쳐 비트 패턴에 따라 밝기가 달라지고 임계값이 무너짐 |
| 자동 노출 (AE) | **끄기** | 켜진 LED 개수가 사이클 내내 변하므로 노출이 계속 요동침 |
| 자동 게인 (AGC) | **끄기** | 동일 |
| 자동 화이트밸런스 | **끄기** | 950nm 단색이라 무의미하고 방해만 됨 |
| 프레임레이트 자동 조정 | **끄기** | 어두우면 자동으로 15fps로 떨어지는 카메라가 많음 |
| 노출 시간 | 20 ms 부근에서 시작 후 튜닝 | 블롭 중심만 포화되고 번지지 않는 지점을 탐색 |
| 노출 시간 | 20 ms 부근에서 시작 후 튜닝 | 블롭 중심만 포화되고 번지지 않는 지점 탐색 |
**AE는 카운트 방식에서 특히 치명적이다.** 버스트 초반에는 9개가 켜져 있다가 후반으로 갈수록 줄어드는데, AE가 이를 보상하려 게인을 올리면 남은 지점의 블롭이 커져 인접 지점을 침범한다. 카운트가 큰 지점일수록 후반부에 오류가 몰리는 형태로 나타난다.
노출 튜닝이 이번 벤치 테스트에서 가장 시간이 많이 소요될 지점이다.
---
## 9. 브링업 절차
## 10. 브링업 절차
1. **LED 1개(PC0)만 330Ω으로 연결** → 스마트폰 카메라로 점등 확인 (필터 없이)
2. **950nm 필터 장착** → 실제 카메라로 블롭 확인, 노출 튜닝
3. **9개 전부 연결** → 모든 비트를 수동으로 켜서 9개 블롭이 분리되는지 확인
4. **TIM6 활성화, 스윕 시작** → USART 로그와 디코더 출력 대조
1. **클록 검증** — 코드 생성 후 UART 로그가 **8초마다 1줄** 나오는지 확인 (MCO를 켰다면 PA8에서 1 MHz 실측)
2. **LED 1개(PC0)만 330Ω으로 연결** → 스마트폰 카메라로 점등 확인 (필터 없이)
3. **950nm 필터 장착** → 실제 카메라로 블롭 확인, 노출 튜닝
4. **9개 전부 연결** → 버스트 구간을 max projection 하여 **9개 블롭이 분리되는지** 확인
5. **1개 사이클 녹화** → 수동으로 프레임을 넘겨가며 G1의 블링크를 육안 계수, UART 로그와 대조
6. **디코더 자동 계수** → 15 사이클(120초) 이상 녹화 후 정확도 산출
3번에서 블롭이 뭉치면 피치를 넓히거나 카메라 거리를 조정한다. **이 단계가 통과되지 않으면 디코더를 아무리 수정해도 소용없다.**
4번에서 블롭이 뭉치면 피치를 넓히거나 카메라 거리를 조정한다. **이 단계가 통과되지 않으면 디코더를 아무리 수정해도 소용없다.**
5번을 건너뛰지 말 것. 육안 계수 1회가 디코더 디버깅 수 시간을 절약한다.
---
## 10. 제안서 수정 필요 항목
## 11. 제안서 수정 필요 항목
프로토타입 완료 후 문서 갱신 시 놓치기 쉬운 지점들.
@@ -351,36 +592,57 @@ void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
---
## 11. 본 프로토타입 이후 결정할 사항
## 12. 본 프로토타입 이후 결정할 사항
### 11.1 LED 부품 교체 기준 (우선순위 순)
### 12.1 카운트 → 주파수 변조 전환
제안서 본안은 1~6 Hz 주파수 변조 + FFT 방식이다. 본 프로토타입의 카운트 방식은 그 하위 단계이며, 전환 시 바뀌는 것은 다음과 같다.
| 항목 | 프로토타입 (카운트) | 제안서 본안 (주파수) |
|---|---|---|
| 송출 | 6초간 N회 블링크 | 8초간 f Hz 연속 점멸 |
| 판독 | 상승 에지 계수 | FFT / 제로크로싱 |
| 노이즈 내성 | 프레임 누락에 취약 | 주파수 영역이라 강함 |
| 필요 프레임레이트 | 30 fps로 충분 | 6 Hz 판독 시 최소 15 fps 이상 |
카운트 방식에서 확보한 ROI 검출·임계값 산출 코드는 그대로 재사용된다. 바뀌는 것은 시계열 처리 단계뿐이다.
### 12.2 LED 부품 교체 기준 (우선순위 순)
1. **반각** — ±20~25° 이상. 이것이 실제 설치 가능성을 좌우함
2. 파장 — 필터와 정합 (현 필터 유지 시 940~950nm)
3. 방사강도 — 목표 거리에서의 조도로 역산
4. 패키지 — 3×3 배치 시 피치 확보 가능한 크기
### 11.2 미결 항목
### 12.3 미결 항목
- **온도 4비트(16단계)로 충분한가** — 제안서의 "수분 14단계"와는 정합하나 온도는 부족할 수 있음. 온도 5비트 + 습도 4비트로 가려면 심볼 2개로 분할하거나 LED 수를 늘려야 함
- **실제 목표 인식 거리** — 벤치 1m 검증 후 온실 실환경 거리 확정 필요. 3m 초과 시 외부 드라이버 및 광각 LED 필수
- **격자 지점 수 확장** — 9개는 MCU 핀 수 제약이 아니라 프로토타입 편의값. 제안서의 "화각 내 2,000개 이상"까지 가려면 지점당 1 MCU 구조가 되므로 본 프로토타입과 아키텍처가 다름
- **팟 배치와 카메라 위치 기하** — 조준 문제의 실제 발생 여부는 이 기하에 달려 있음
- **디코더 구현** — ROI 자동 검출, 클록 기반 심볼 분할, 다수결 로직 (Python)
- **저전력 전환** — LPTIM1 + LSE 기반 구조. NUCLEO-L073RZ의 LSE 수정(X2) 실장 여부 확인 필요
---
## 부록: 핵심 수치 요약
```
LED : LD274, 950nm, 반각 ±10°, V_F ≈ 1.1V @ 6mA
저항 : 330Ω (대안 220Ω)
구동 전류 : 6 mA/개, 합계 54 mA
배치 : 3×3, 피치 10mm
거리 : 1 ~ 1.5 m
심볼 주기 : 200 ms (6 프레임 @ 30fps)
유효 프레임 : 심볼당 최소 5
전체 스윕 주기 : 51.2 초 (256 심볼)
MCU : STM32L073RZ, HSI16, TIM6 (PSC 15999 / ARR 199)
GPIO : PC0~PC8, Open Drain, No pull, Low speed, Output level High
로그 : USART2 115200 8N1
LED : LD274, 950nm, 반각 ±10°, V_F ≈ 1.1V @ 6mA
저항 : 330Ω (대안 220Ω)
구동 전류 : 6 mA/개, 최대 합계 54 mA
배치 : 3×3, 피치 10mm, 9개 격자 지점
거리 : 1 ~ 1.5 m
틱 주기 : 200 ms (30fps 기준 6프레임)
블링크 1회 : 400 ms (2.5 Hz)
카운트 범위 : 1 ~ 15 (0은 미사용)
버스트 구간 : 6.0 s (30 틱)
소등 구간 : 2.0 s (10 틱)
사이클 : 8.0 s (40 틱)
전 조합 커버리지 : 15 사이클 = 120 초
MCU : STM32L073RZ
클록 : HSI16 → SYSCLK 16MHz, AHB /1, APB1 /1, 타이머 X1
TIM6 : PSC 15999 / ARR 199 → 200 ms
GPIO : PC0~PC8, Open Drain, No pull, Low speed, Output level High
로그 : USART2 115200 8N1, 사이클당 1줄
```