Overview

This repository is centered on a real-time acquisition terminal for inkjet nozzle monitoring.
Its primary purpose is to capture nozzle-related analog signals with very low delay after an external trigger, preserve the early part of the waveform, and forward the captured data to an external host through UART or UDP.

The codebase shows that the project is not organized as a general-purpose embedded UI product. Its design priority is clearly the acquisition path itself. Display, diagnostics, networking, and control framing exist, but they are arranged around the sampling core rather than the other way around.

Main Content

At the center of the system is a triggered acquisition pipeline built around ADC3 + DMA + TIM2 on an STM32H750. The firmware supports at least two operating modes:

• Single trigger mode
• AUTO_256 mode
• AUTO_256 + N, where each nozzle is captured repeatedly and averaged before post-processing

In the repeated capture path, the board collects multiple raw captures per nozzle, averages them locally, processes the averaged frame, and finally sends a full batch covering 256 nozzle positions. This makes the firmware more than a simple data forwarder. It already performs part of the data reduction and conditioning on-board.

The repository also includes:

• a control-frame parser using a custom binary frame format with CRC16 Modbus
• a send manager for UART or UDP output switching
• an LCD status layer for local observability
• a monitoring subsystem for CPU usage, stack watermark, latency, event traces, and recovery signals
• a W5500 Ethernet path for UDP communication
• signal processing code including FIR filtering and utility functions for alignment and comparison

This means the project is best understood as a signal acquisition endpoint with embedded transport and observability, not just as a peripheral demo.

System Context

The repository appears to sit between a physical nozzle or ignition event source and an upper-level host analysis system.

A likely system context is:

• an external pulse or event arrives
• the board starts acquisition immediately
• the sampled waveform is buffered and processed
• results are sent to a host PC through UART or Ethernet
• the host controls mode selection and requests status by sending framed commands

This makes the firmware suitable for bench validation, nozzle diagnostics, timing studies, and host-assisted measurement workflows.

Architecture / Design Considerations

The architecture strongly favors a short and predictable acquisition path.

The intended data flow is effectively:

External trigger -> ADC/DMA sampling -> acquisition task handoff -> app-side processing -> UART/UDP transmission -> local display and diagnostics

Several design choices reveal the project’s priorities:

1. Acquisition-first structure

Sampling is treated as the dominant concern. UI refresh, network output, and logging are intentionally secondary.

2. Batch-aware capture model

AUTO_256 + N is especially important. Instead of sending every raw capture immediately, the board accumulates repeated samples per nozzle, averages them locally, then applies filtering and sends the batch. This reduces transport overhead and moves some stabilization logic onto the device.

3. Task separation without over-fragmentation

The project uses FreeRTOS tasks, but it does not explode into too many abstraction layers. Acquisition, application processing, sending, LCD refresh, UDP receive/process, and monitoring are separated enough to be manageable while remaining practical for debugging.

4. Built-in observability

This is one of the stronger parts of the repository. The firmware tracks:

• CPU usage by task
• task stack usage
• queue blockage and drop behavior
• acquisition-to-processing and processing-to-send latency
• transport failures
• batch timing misses

That is a meaningful engineering choice. It suggests the project is being shaped not only to run, but to be diagnosed under timing pressure.

5. Dual transport path

The send path can switch between UART and UDP. This makes the board usable both as a local lab instrument and as a network-connected terminal.

Possible Implications

This repository has value in environments where timing fidelity matters more than UI completeness.

It can be useful for:

• nozzle waveform characterization
• repeated capture and averaging workflows
• remote acquisition terminals in lab setups
• host-controlled embedded measurement systems
• early-stage diagnostic platforms before a larger product is built

Its practical strength is that it already combines:

• hard real-time acquisition intent
• transport flexibility
• basic signal conditioning
• on-device diagnostics

Its main engineering tension is also clear: the more features are added around the capture loop, the more risk there is that the front-end timing path becomes less deterministic. The codebase itself seems aware of this trade-off.

Conclusion

This repository is best described as a real-time nozzle signal acquisition and monitoring terminal built around STM32H750, with control framing, batch capture logic, local averaging, filtering, LCD status output, and UART or UDP transmission.

Its technical significance is not in a flashy interface, but in how it tries to preserve measurement reliability under real embedded constraints. The project’s core value lies in keeping the acquisition path short, observable, and operational while still exposing enough communication and monitoring features to support system-level integration.

KR - Internal / Review

요약

이 저장소는 단순한 임베디드 데모가 아니라, STM32H750을 중심으로 외부 트리거 기반의 잉크젯 노즐 신호를 고속 수집하고, 이를 배치 단위로 가공한 뒤 UART 또는 UDP로 전달하는 측정 단말로 보는 것이 더 정확합니다.

핵심은 화면이나 네트워크 기능이 아니라 다음 세 가지입니다.

1. 트리거 이후 짧은 시간 안에 샘플을 놓치지 않는 것
2. 256개 노즐 단위 배치 수집을 안정적으로 끝내는 것
3. 수집 이후 전송/표시/진단은 하되, 수집 경로를 침범하지 않게 하는 것

전체 구조 해석

이 프로젝트의 중심 흐름은 대략 아래와 같습니다.

외부 트리거(PA1) -> ADC3 + DMA + TIM2로 샘플링 시작 -> 수집 완료 이벤트 -> 앱 처리 -> 전송(UART/UDP) -> LCD/모니터링

여기서 중요한 점은,
이 흐름이 “기능 나열”이 아니라 실시간성 우선 순서로 배치되어 있다는 것입니다.

• 샘플링 시작은 가능한 한 짧은 경로를 타도록 되어 있음
• 샘플 처리와 전송은 샘플 확보 이후로 밀려 있음
• LCD, CPU 표시, 상태 덤프, 이벤트 추적은 모두 보조 기능으로 붙어 있음

즉, 이 시스템의 본질은 데이터를 보여주는 장치가 아니라 데이터를 먼저 놓치지 않는 장치입니다.

무엇을 실제로 지원하는가

현재 저장소 기준으로 확인되는 동작 모드는 다음과 같습니다.

• 단발 트리거 모드
• AUTO_256
• AUTO_256 + N
• 상태 조회
• 전송 채널 전환 UART / UDP

특히 AUTO_256 + N이 중요합니다.
이 모드는 단순히 256개를 한 번씩 읽는 것이 아니라, 각 노즐에 대해 N회 반복 수집 후 보드에서 평균을 낸 다음, 그 결과를 바탕으로 후처리와 전송을 수행합니다.

이 말은 곧:

• 노이즈 완화 일부를 상위 PC가 아니라 보드가 담당
• 모든 raw pulse를 그대로 쏘는 구조가 아님
• 통신량을 줄이는 대신, 보드 쪽 처리 책임이 커짐

이라는 뜻입니다.

설계 의도 해석

이 저장소는 구조상 “수집 중심”이라는 의도가 매우 분명합니다.

1. 수집 경로를 짧게 유지하려는 의도

문서와 코드 모두에서 반복적으로 드러나는 방향은 같습니다.

• 트리거 후 즉시 샘플링
• DMA 기반 버퍼링
• 수집이 끝난 뒤에야 분석/전송/표시
• UI와 통신이 수집 타이밍을 흔들지 않도록 분리

이건 좋은 방향입니다.
이 계열 시스템은 기능이 많아질수록 멋있어지는 게 아니라, 초기 10~수십 us 구간을 놓치는 순간 존재 이유가 흔들립니다.

2. AUTO 배치 수집을 단순 반복이 아니라 “평균 후 전송” 구조로 설계

이 부분은 꽤 실무적입니다.

각 노즐에서 N번 반복 측정한 뒤:

• 먼저 노즐 단위 평균
• 256개 전체가 끝난 뒤
• DSP/FIR 적용
• 이후 일괄 전송

이 구조는 상위 시스템 입장에서 두 가지 장점이 있습니다.

• raw 노이즈에 덜 흔들리는 데이터 확보
• 256 x 512 급 데이터를 전송할 때 의미 없는 중복 raw를 줄일 수 있음

반대로 단점도 있습니다.

• 보드 메모리와 처리 시간을 더 먹음
• 반복 횟수 N이 커질수록 전체 배치 지연이 커짐
• 평균 이전의 개별 변동 정보는 사라질 수 있음

즉, 이 구조는 “정확한 즉시 원시 데이터 수집기”보다는 “현장형 안정화 측정 단말” 쪽 성격을 강화합니다.

소프트웨어 구조 해석

현재 코드에서 드러나는 주요 축은 아래와 같습니다.

• adc_task.*
  수집 상태, DMA 버퍼, AUTO_256 배치 진행, 슬롯 큐 관리
• cmd_handler.*
  상위 제어 프레임 파싱, CRC16 검사, 모드 전환, 상태 질의 처리
• send_mgr.*
  UART/UDP 전송 경로 관리, 송신 큐, 배치 전송 상태 추적
• monitor.*
  CPU 사용률, stack watermark, latency, trace, watchdog, recovery, 저전력 진입 관리
• lcd_mgr.*
  현재 상태, 실패 카운트, CPU/latency 표시
• Process.*
  FIR 필터링, 전압 변환, RMS/상관 계산 계열 처리
• W5500 관련 코드
  SPI 기반 Ethernet 인터페이스 및 UDP 통신 기반 제공

이 구조는 과하게 이상화된 계층 구조는 아닙니다.
오히려 현재 단계에서는 괜찮습니다. 지나친 추상화보다 실제 디버깅 가능한 구조를 택한 쪽입니다.

이 시스템에서 W5500의 역할

이 저장소에서 W5500은 단순 부속품이 아닙니다.
상위 제어와 데이터 송신을 Ethernet/UDP 경로로 가능하게 하는 핵심 통신 블록입니다.

역할은 명확합니다.

• 고정 IP 기반 네트워크 엔드포인트 제공
• UDP 제어 프레임 수신
• 상태 조회 응답 송신
• 샘플 프레임 또는 배치 데이터 송신

즉, 이 시스템은 UART만으로도 디버깅은 가능하지만, 원격 제어 및 상위 장비 연동까지 포함하려면 W5500 경로가 사실상 중요합니다.

특히 이 프로젝트는 명령 파서에서:

• 상태 질의
• 전송 경로 전환
• AUTO 모드 진입

등을 UDP 프레임으로 받을 수 있게 되어 있어서, W5500은 단순 통신 옵션이 아니라 운영 방식 자체를 바꾸는 모듈입니다.

데이터 흐름에서 중요한 포인트

1. 제어 프레임과 샘플 프레임이 분리되어 있음

상위 장비는 바이너리 제어 프레임을 보냅니다.

형식은 대략:

• 헤더 55 AA
• 길이
• payload
• CRC16 Modbus

이 구조는 간단하지만 실무적입니다.
특히 길이와 CRC가 있어 UART와 UDP 양쪽에서 공통적으로 다루기 좋습니다.

2. 수집 데이터는 곧바로 보내지 않고 큐를 거쳐 송신

send_mgr 쪽을 보면 샘플은 송신 큐를 거치며, 배치 전송 상태도 별도로 추적합니다.

이건 장점과 위험이 같이 있습니다.

• 장점: 수집과 전송이 분리되어 수집 경로가 덜 막힘
• 위험: 큐가 막히면 전송 지연 또는 드롭이 발생할 수 있음

그래서 이 저장소가 큐 깊이, timeout, 전송 실패 횟수까지 모니터링하는 겁니다.
그냥 예쁘게 통계 붙인 게 아니라, 실패 지점을 알고 있다는 뜻입니다.

3. LCD는 주 기능이 아니라 상태 관찰 창

LCD는 꽤 많이 붙어 있지만, 구조상 주연은 아닙니다.

표시 항목도:

• 현재 모드
• 전송 모드
• 진행 인덱스
• 실패 카운트
• CPU 사용률
• latency
• 원격 IP/Port

같이 “운영 상태 확인” 중심입니다.

즉, 이 LCD는 GUI가 아니라 현장 디버그 패널에 가깝습니다.

실패 비용이 가장 큰 지점

이 프로젝트에서 가장 실패 비용이 큰 지점은 단연 이 부분입니다.

외부 트리거 -> 실제 ADC/DMA 시작 구간

이유는 간단합니다.

• 이 구간이 늦어지면 파형 앞부분이 비어버릴 수 있음
• 초기 수십 us 데이터가 날아가면, 뒤를 아무리 잘 잡아도 진단 의미가 약해질 수 있음
• 이후 분석, LCD, 네트워크는 어느 정도 늦어도 되지만 이 구간은 늦으면 안 됨

즉, 이 시스템에서 제일 비싼 실패는 “전송 실패”보다 먼저 선행 샘플 손실입니다.

그 다음으로 큰 지점은 아래입니다.

AUTO_256 + N 배치 중 누적/평균/전송 경계

이 구간이 위험한 이유:

• 반복 횟수 N 증가 시 누적량 증가
• 256개 노즐 전체를 메모리에 정리해야 함
• 평균, 필터, 배치 송신이 순차적으로 이어짐
• 어느 한 부분이 밀리면 전체 batch timing이 무너질 수 있음

그래서 monitor 쪽에서 batch miss, send fail, queue blocking, latency를 따로 추적하고 있는 겁니다.

현재 구조의 장점

장점 1. 실시간 수집 시스템으로서 방향이 맞다

수집 우선, 후처리 후순위라는 구조가 분명합니다.

장점 2. 상위 제어와 현장 디버깅이 둘 다 가능하다

UART와 UDP를 모두 열어둬서 개발, 시험, 원격 운영에 유연합니다.

장점 3. 관측 가능성이 좋다

CPU, stack, latency, trace, queue 상태까지 드러나 있어 병목 분석이 가능합니다.

장점 4. AUTO_256 + N이 단순 옵션이 아니라 의미 있는 측정 전략이다

반복 평균을 보드 단에서 수행해 측정 품질을 조금 더 안정적으로 만들 수 있습니다.

현재 구조의 한계와 주의점

1. 기능이 계속 붙으면 수집 경로 오염 위험이 있다

모니터링, LCD, 네트워크, 저장, 저전력까지 다 붙으면 결국 핵심 경로를 간접적으로 흔들 수 있습니다.

2. W5500 경로는 편하지만 결정론성이 완전히 보장되는 영역은 아니다

UDP는 실험실 장비 연동엔 실용적이지만, 타이밍 보장형 버스는 아닙니다.

3. 배치 평균 구조는 raw 개별 변동을 일부 가린다

평균 후 전송은 안정적이지만, 개별 반복 간 편차 분석에는 불리할 수 있습니다.

4. 저전력 진입은 강력하지만, 실제 운영에선 깨지기 쉬운 구간이 될 수 있다

코드상으로는 DSTOP 진입과 복귀까지 포함하고 있습니다.
이건 꽤 공격적인 편입니다. 저전력은 멋있어 보이지만, 실시간 측정 장비에선 늘 잠복 버그의 산실이기도 합니다.

검증 포인트

이 저장소를 실제 장비 관점에서 검토할 때는 아래를 우선 봐야 합니다.

1. 트리거 후 ADC 시작 latency
2. 초기 구간 샘플 유실 여부
3. AUTO_256 + N에서 N 증가 시 총 배치 시간 변화
4. 배치 송신 중 queue blocking 또는 fail 발생 빈도
5. UDP 제어와 샘플 전송이 동시에 들어올 때 수집 간섭 여부
6. STOP 모드 진입/복귀 후 W5500, UART, ADC 상태 일관성

종합 판단

이 프로젝트의 본질은 “잉크젯용 보드 데모”가 아니라,
고속 수집을 우선하는 임베디드 측정 단말입니다.

좋은 점은, 개발자가 단순 기능 추가보다 관측 가능성, batch miss, queue blocking, CPU/stack 상태 같은 현실 문제를 꽤 신경 썼다는 것입니다.
즉, 이 저장소는 기능 데모보다 운영 가능한 측정 시스템 쪽으로 가고 있습니다.

다만 앞으로 기능을 더 붙일수록, 이 프로젝트의 품질은 새 기능 개수로 결정되지 않습니다.
오히려 다음 한 줄로 결정됩니다.

수집 시작 경로가 얼마나 짧고 안정적으로 유지되는가

이 원칙이 무너지면, 나머지는 다 주변 장식이 됩니다. 임베디드 세계는 늘 그렇게 잔인하죠.

FAQ

Q1. 이 프로젝트는 프린터 제어기입니까, 측정 단말입니까?

현재 저장소 기준으로는 측정 단말에 더 가깝습니다. 노즐을 직접 구동하는 제어기라기보다, 트리거된 현상을 빠르게 수집하고 상위 장비에 전달하는 구조가 중심입니다.

Q2. AUTO_256 + N의 의미는 무엇입니까?

256개 노즐을 단순히 한 번씩 읽는 것이 아니라, 각 노즐을 N회 반복 측정해서 평균을 낸 뒤 후처리와 전송을 수행하는 방식입니다. 즉, raw를 전부 보내기보다 보드가 일부 안정화 처리를 먼저 맡습니다.

Q3. 왜 UART와 UDP를 둘 다 지원합니까?

UART는 현장 디버깅과 초기 bring-up에 유리하고, UDP는 상위 PC 연동과 원격 제어에 편합니다. 둘을 모두 두면 개발 단계와 운영 단계에서 유연성이 커집니다.

Q4. 이 프로젝트의 가장 중요한 기술 포인트는 무엇입니까?

외부 트리거 이후 ADC/DMA가 얼마나 빠르고 안정적으로 시작되느냐입니다. 여기서 샘플을 놓치면 이후 필터링이나 전송이 아무리 잘 되어도 측정 가치가 낮아질 수 있습니다.

Q5. LCD는 핵심 기능입니까?

아닙니다. 현재 구현상 LCD는 운영 상태와 진단 정보를 보여주는 보조 관찰 창에 가깝습니다. 핵심 기능은 수집과 전송 체인입니다.

Q6. 앞으로 구조를 더 크게 바꾸는 게 좋습니까?

지금 단계에서는 대규모 재구성보다 핵심 경로 안정화가 우선입니다. 수집 경로를 유지한 상태에서 모듈 경계를 천천히 정리하는 편이 훨씬 안전합니다.

저자 정보

현재 확보된 자료는 업로드된 저장소 압축본과 URL 수준이라, 저자 정보를 과장해서 쓰면 위험합니다.
확인 가능한 범위에서 보면 이 저장소는 GitHub 사용자 Zhichao0711 명의로 정리된 프로젝트이며, 코드와 문서 전반에서 STM32H750, W5500 Ethernet, FreeRTOS 기반의 실시간 수집 시스템에 관심을 두고 있는 개발 흐름이 드러납니다.

다만 소속, 경력, 실명, 세부 이력은 현재 자료만으로는 검증되지 않았습니다.
따라서 공개 소개문을 작성해야 한다면, 현 단계에서는 “STM32H750 기반 고속 신호 수집 및 네트워크 연동 임베디드 시스템을 다루는 개발자” 정도로만 정리하는 것이 가장 정직합니다.