안녕하세요! 강의 하단 강의 노트에도 적어둔 내용인데, 여기서 보실 수도 있으니 같은 내용을 적습니다. 결론: 수강생님이 바꾸신 설정(CPOL Low)이 맞습니다. FND 모듈의 74HC595는 SCLK가 LOW → HIGH로 올라가는 순간(상승 엣지) 에 데이터를 읽습니다. 그래서 SPI도 상승 엣지에서 데이터를 읽도록 설정해야 하고, 아래 두 가지 중 하나면 정상 동작합니다. CPOL Low + CPHA 1Edge ← 수강생님 설정 CPOL High + CPHA 2Edge 강의에서 설정한 CPOL High + CPHA 1Edge는 하강 엣지에서 데이터를 읽는 조합이라서, 보드나 배선에 따라 동작하지 않을 수 있습니다. 그래서 "평상시 SCLK가 High니까 CPOL도 High"가 기준이 아니라, 칩이 데이터를 읽는 엣지에 맞춰 CPOL과 CPHA를 같이 정하는 것 이 기준입니다. 강의에서 헷갈리게 설명드려 죄송합니다. 감사합니다.
안녕하세요! 답변을 정리하다 보니 이제서야 질문을 확인했네요. 너무 너무 늦어서 죄송합니다. ⭐ 가장 중요한 점: Live Expressions에는 전역 변수나 static 변수만 넣을 수 있습니다 main() 안에 선언된 temper 처럼 함수 안에서 만든 일반 변수(지역 변수)는 실행 중에 표시되지 않습니다. 이유는 Live Expressions가 실행 중에 변수의 메모리 주소를 계속 읽어서 값을 보여주기 때문입니다. 전역 변수와 static 변수는 프로그램이 도는 내내 항상 같은 메모리 위치에 있습니다. 그래서 디버거가 언제든 읽을 수 있습니다. 지역 변수는 함수가 실행될 때만 잠깐 만들어졌다가 함수가 끝나면 사라집니다. 그래서 실행 중에 계속 읽을 수 없습니다. 이 예제에서는 ds18b20.c 에 전역으로 선언된 temperSensor.Temperature 를 사용하시면 됩니다. 1. 디버그 모드로 실행하기 벌레 모양 Debug 버튼을 눌러 디버깅을 시작합니다. 화면이 디버그 화면으로 바뀌고, main() 첫 줄에서 잠깐 멈춥니다. 2. 브레이크포인트 걸기 heaterController.c 에서 히터를 켜는 줄( heaterOnOff(ON_t); )을 찾습니다. 그 줄 왼쪽의 줄 번호 옆 여백을 더블클릭 합니다. 파란 점이 생기면 브레이크포인트가 걸린 것입니다. 3. Live Expressions 창 열기 메뉴에서 Window → Show View → Live Expressions 를 선택합니다. 보통 오른쪽 위 Variables, Breakpoints 탭 옆에 생깁니다. 4. 변수 추가하기 Live Expressions 창의 Add new expression 을 클릭하고 temperSensor.Temperature 를 입력합니다. 5. Resume(F8)으로 실행하기 Resume 버튼을 누르면 프로그램이 돌면서 Live Expressions의 온도 값이 실시간으로 바뀝니다. 온도가 45도보다 낮아져 히터를 켜는 줄이 실행되는 순간, 프로그램이 멈추고 화면이 그 줄로 자동으로 이동합니다. 따로 설정할 것은 없고, 2번처럼 브레이크포인트만 걸어두면 됩니다. 참고 브레이크포인트에서 멈춘 동안에는 Live Expressions 값이 갱신되지 않습니다. 이때는 코드의 temper 위에 마우스를 올리거나 Variables 탭에서 그 순간의 값을 볼 수 있습니다. Live Expressions에 값이 안 나오면 Run → Debug Configurations → Debugger 탭 에서 Enable live expressions 가 체크되어 있는지 확인해 주세요. 다시한번 너무 늦은 답변 죄송합니다. ㅠ_ㅠ
안녕하세요 ㅠ_ㅠ 질문 답변을 정리 하다 보니 지금에서 발견했네요. 너무 죄송합니다. 답변을 드릴게요. 먼저, Resume 버튼이 비활성화된 건 프로그램이 멈춘 게 아니라 지금 실행 중 이라는 뜻입니다. 프로그램은 돌고 있는데 두 번째 브레이크포인트 줄까지 가지 못하고 있는 상황입니다. 아래 순서대로 확인해 보세요. 1. 빌드부터 다시 해주세요 빌드가 실패했는데 그대로 디버깅을 시작하면, 보드에는 예전 코드가 올라가 있어서 브레이크포인트 위치가 어긋납니다. Project → Clean 후 다시 Build 해주세요. Console 창에 에러가 없는지 확인해 주세요. 디버그 시작할 때 “Errors exist in project. Proceed with launch?” 창이 뜨면 Proceed를 누르지 말고 에러부터 해결해 주세요. 2. 지금 어디서 실행 중인지 확인해 주세요 빌드해도 같은 증상이면, 상단의 Suspend(⏸) 버튼 을 눌러보세요. 프로그램이 멈추면서 현재 실행 중인 줄이 표시됩니다. 버튼 입력이나 조건을 기다리는 코드에 있다면, 그 조건이 만족돼야 다음 줄로 넘어갑니다. HardFault_Handler 나 Error_Handler 안에 있다면, 그 전에 에러가 발생한 것입니다. 3. 브레이크포인트 개수도 확인해 주세요 STM32F103은 브레이크포인트를 6개까지만 걸 수 있습니다. Breakpoints 창 (Window → Show View → Breakpoints)에서 예전에 걸어둔 게 남아 있지 않은지 확인해 주세요. 그래도 해결이 안 되면, 소스코드 좀 보내주세요. 제가 확인해드릴게요. ohjiwan@gmail.com 감사합니다.
안녕하세요! 타이밍도와 회로도를 같이 보시고 정확하게 짚어주셨네요 👍 결론부터 말씀드리면, 원칙적으로는 말씀하신 대로 Open Drain이 맞습니다. 제가 CubeMX에서 습관적으로 Push-Pull로 설정했는데, 이 예제에서는 그 설정이 실제 동작에 영향을 주지 않아서 문제없이 동작했습니다. 1. 왜 Open Drain이 맞을까요? 1-Wire는 MCU와 센서가 선 하나를 같이 쓰는 방식입니다. 그래서 각 장치는 선을 LOW로 당기기만 하고, HIGH는 10K 풀업 저항이 만들어 줍니다. 말씀하신 대로 타이밍도에서 LOW만 강하게 당기는 이유가 이것입니다. Open Drain: LOW 출력과 손 놓기(High-Z)만 할 수 있어서 1-Wire와 잘 맞습니다. Push-Pull: HIGH도 직접 출력합니다. MCU가 HIGH를 출력하는 동안 센서가 LOW로 당기면 두 출력이 부딪혀(쇼트) 신호가 깨지거나 핀에 무리가 갈 수 있습니다. 2. 그런데 이 예제에서는 왜 괜찮았을까요? 이유는 두 가지입니다. ① 온도 센서 라이브러리(onewire.c)가 통신할 때마다 핀 모드를 직접 다시 설정합니다. LOW로 당길 때는 GPIO_MODE_OUTPUT_OD (Open Drain), 선을 놓을 때는 GPIO_MODE_INPUT 으로 바꿉니다. 그래서 CubeMX에서 정한 Push-Pull 설정은 통신이 시작되면 바로 덮어써집니다. ② HIGH가 필요할 때도 라이브러리는 HIGH를 직접 출력하지 않고, 핀을 입력 모드로 바꿔서 풀업 저항이 HIGH를 만들게 합니다. 그래서 출력끼리 부딪히는 상황이 생기지 않습니다. 3. 정리하면 이론적으로 맞는 설정은 Open Drain입니다. 질문하신 내용이 정확합니다. 이 예제에서는 라이브러리가 모드를 직접 바꿔서 Push-Pull로 둬도 동작에 차이가 없었습니다. 직접 하실 때는 CubeMX에서 GPIO Output Open Drain / No pull 로 설정하시는 걸 추천드립니다. 그렇게 바꿔도 동작은 똑같습니다. 결론은 저의 실수네요. 감사합니다.
안녕하세요. 답변이 너무 늦어서 죄송합니다. 확인해 보니 crdb.zip 다운로드 오류는 ST 공식 커뮤니티에서도 보고된 문제입니다. 최신 버전에서는 해결될 것으로 예상하고 있으니, 우선 STM32CubeIDE 최신 버전인 2.2.0 을 설치해서 다시 시도해 보시면 좋을 것 같습니다. 이후 혹시 빌드 과정에서 문제가 발생한다면, 최신 강의 자료를 다운로드하신 후 "could not verify ST ... .zip" 파일을 확인해 주세요. 해당 파일 안에 문제 해결을 위한 매뉴얼과 필요한 파일들이 포함되어 있습니다. 추가로 한 가지 확인 부탁드립니다. 혹시 Windows 사용자 계정 이름이 한글로 되어 있나요? 프로젝트 경로가 영문이더라도 Windows 사용자 계정 이름이 한글이면 일부 개발 도구에서 경로 관련 문제가 발생하는 경우가 있더라고요. 우선 위 방법으로 진행해 보시고, 문제가 계속되면 다시 질문 남겨주세요. 감사합니다.
안녕하세요. 답변이 너무 늦어서 죄송합니다 ㅠ_ㅠ. 말씀하신 것처럼 data[0] ~ data[8]까지 모두 255(0xFF)가 들어온다면, 온도값을 계산하는 부분보다는 그 이전의 OneWire 통신 과정에서 센서의 데이터를 제대로 읽지 못하고 있는 것으로 보입니다. 특히 단순화하기 전의 기존 소스에서는 같은 보드와 센서로 정상적으로 온도값이 들어왔다면, 우선 하드웨어 문제보다는 단순화한 소스와 기존 소스 사이의 차이를 확인해보는 게 좋을 것 같습니다. 이 경우에는 일부 코드만 보고 원인을 추측하는 것보다 제가 프로젝트를 직접 비교해보는 게 빠를 것 같습니다. 기존에 정상적으로 동작했던 프로젝트 현재 단순화한 뒤 동작하지 않는 프로젝트 두 프로젝트를 압축해서 보내주세요. (ohjiwan@gmail.com) 제가 두 소스의 OneWire 초기화 부분과 GPIO 설정, DS18B20을 읽는 과정을 비교해보고 어디에서 차이가 발생했는지 확인해보겠습니다.
안녕하세요. 보통은 Debug 모드로 펌웨어를 올려도 ST-Link를 제거한 상태에서 정상적으로 동작합니다. 다만 디버깅 과정에서 설정이나 코드에 따라 ST-Link가 연결되어 있을 때와 제거했을 때 동작이 달라지는 경우가 있습니다. 보통 개발이 완료되면 최종적으로 Release 모드로 컴파일해서 펌웨어를 올리기 때문에, 우선 아래와 같이 한번 진행해보세요. STM32CubeIDE 상단의 Debug 설정을 Release로 변경합니다. 다시 Build 합니다. ST-Link를 연결한 상태에서 펌웨어를 다운로드합니다. 다운로드가 끝나면 전원을 끕니다. ST-Link를 완전히 제거합니다. USB 전원만 연결해서 다시 켜봅니다. BOOT0 핀을 GND에 연결하신 것은 맞습니다. 위와 같이 했는데도 동작하지 않는다면 Release/Debug 문제는 아닐 가능성이 높습니다. 그 경우에는 원인을 하나씩 확인해봐야 하니, Release로 다시 올린 후 ST-Link를 제거했을 때 LED와 FND가 어떻게 동작하는지 알려주세요. 그 결과를 보고 다음 확인할 부분을 안내드리겠습니다.
안녕하세요. 일단 전압이 정확히 나오는지 확인해보세요. (멀티미터기를 활용하셔야해요.) 전압이 출력이 안 된다면, 일단 설정들과 코드를 점검해보셔야하고요. 출력이 되는데도 LED가 안나오면 LED 고장입니다. GPIO 제어 자체가 고장나는 경우는 극히 드물고, 사실 LED 고장도 드물긴해요. 그래도 가능성은 있어요. 만약 보드에 있는 기본 LED가 고장이라면, 부품 세트에 있는 다리가 긴 led 하나 쓰셔도 됩니다. 그래도 동일한 효과를 볼 수 있어요. 모두 확인해보고 led 고장이라고 판명이 나면, 보드 하나 보내드릴게요. 화이팅!
