Reorganizing the File Structure of mbed Sys & Solving MACRO Issues!

STM32F401RET6 Nucleo Dev-Board

 

Build Initial Project(Basic template)

 

CubeMX를 통해 라이브러리 파일 generate 까지 진행하였다.

그런데 Git Repository에 Push한 소스 코드를 확인해보니, 중복된 코드가 있었다.

ap.c 와 bsp.c의 각 Init 초기화 함수에
GPIO Ports Clock Clock Enable 이라고 GPIO 포트 클럭 활성화 설정 함수가 있었다.

 

 

 

여기서 ap는 application layer이고,
bsp는 board support package layer라 hardware 쪽에 근접한데,

main 함수에서 가장 먼저 호출되는 함수가 hwInit 함수이다.
호출된 hwInit함수는 bspInit()을 호출하여 가장 먼저 초기화가 이루어지는 함수이다.

정리해본 결과, 다음과 같이 진행하기로 하였다.
우선 main 함수를 통해 초기화 함수의 순서를 살펴보자면,

hwInit() -> bspInit() -> apInit() 이다.

 

따라서,

하드웨어 초기화 함수(hwInit)에서는 기본적인 하드웨어 설정을 수행하기 때문에

HAL_Init(), SystemConfig() 함수를 넣을 것이다.

그리고 bspInit 함수 호출을 할 것이다.

Board Support Package 초기화 함수(bspInit)는 특정 보드(하드웨어 플랫폼)에 대한 설정을 수행할 것이다.
따라서 generate된 gpio.c 코드 내 MX_GPIO_Init 함수 내의 함수들,
GPIO Ports Clock Enabel, Configure GPIO pin Output Level,
Configure GPIO Pin : XX 등의 함수들이 들어갈 것이다.

Application 초기화 함수(apInit)에서는 리소스 및 서비스 초기화를 담당한다.
즉, 애플리케이션에 필요한 데이터 구조의 초기화, 특정 로직을 위한 초기설정(예: 타이머
설정, 애플리케이션 상태 머신 초기화, 사용자 인터페이스 등)과 네트워크 설정이나
애플리케이션 레벨의 프로토콜 초기화도 이 단계에서 수행된다.
따라서 여기에는 사용자 정의함수로 delay, millis 함수가 ap.c 소스 코드내에
함수 정의가 되어서 사용되면 될 것으로 보인다.

 

---

궁금한 부분 하나는, 프로젝트 properties에서

C/C++ Build의 Settings의 MCU GCC Compiler의 Preprocessor에 대해서이다.

 

 

위 부분인데, Define symbols의 기준이 무엇인지. 자세히 알아야 될 것 같다.

 

정리하자면, 프로젝트마다 타겟되는 하드웨어플랫폼이 다른데 거기에서 사용되는
지시어 말고도 전체적으로 사용될 매크로를 정의하여 넣는 것이다.

2024.02.18 - [Embedded System/ARM] - How to MACRO be configured to match the target HW Platform

 

 

CubeMX 통해 generated 된 파일 중,
Drivers/CMSIS/Devicees/ST/STM32F4xx/Include/stm32f4xx.h
중에서 위와 같은 주석 처리된 코드를 확인 할 수 있는데,

위 설명으로는 사용 하는 STM32 Device에 맞춰 주석 해제하라고 한다.
지금 현재 사용하고 있는 것은 STM32F401RE라서 하이라이팅된 STM32F401xE를
주석 해제를 해주는 것이 맞다.
하지만, 이걸 전체적으로 사용할 수 있게 “MACRO” 등록하여 활용되게끔 하는 것으로 보여진다.

 

 

결과적으로는 위와 같이 추가하고 Apply and Close..

 

---

 

다음과 같은 문제가 발생하였다.
프로젝트 빌드 시 bsp 폴더 내 각 파일에서 main.h를 컴파일러가 찾을 수 없다는 것이다.
이전과 함수 구조를 달리 만들어서 발생하는 문제라 경로가 서로 꼬인 것 같다.

 

그렇다면, 처음으로 다시 돌아가서 기존의 코드 순서를 확인해봐야 할 것 같다.

 

프로젝트 빌드는 문제없이 수행되었으나, 디버깅 중 LED 점멸이 되지 않아

원래의 코드로 변경 후 빌드하여 정상적으로 LED 점멸 여부 확인 되었다.

그렇다면 이전 코드에서 문제가 있었던 것이 맞았다.

---

• 따라서 두가지 해야될 일이 있는데, 순서를 정해야 할 것으로 보인다.

1. 재구성한 파일 구조로 정상적으로 동작되게끔 확인 및 수정한다.
2. 기존의 파일 구조 그대로 BlackPill 개발 보드(3개) Soldering 이후 하드웨어 확인

 

그런데 어차피 ‘2번’ 이슈를 확인한다해도, 다시 1번 이슈를 제대로 확인해야되니
1번의 파일 구조부터 제대로 정립이 필요할 것으로 보인다.

 

— 확인 완료.

How to Solving this Problem.

이전 프로젝트를 생성하며 깨달은건데, debug configuration 할 때,
다른 프로젝트로 만든 디버거로 실행한 것이어서 그랬다.

 

 

이렇게 새로 Debug를 해주어야한다.
Project Name 도 제대로 다시 확인 필요.