STM32F4 및 HAL

그래서 STM32F407 (ARM에 익숙하지 않음)을 사용하여 잠시 실험을 해왔으며 ST가 표준 주변 장치 라이브러리를 중단 한 것처럼 보이기 때문에 HAL 라이브러리를 사용하여 간단한 앱을 작성하기로 결정했습니다. 제 질문은 HAL의 요점이 무엇입니까? StdPeriph가 업무를 수행하지 않았습니까? 왜 그들은 HAL을 위해 중단합니까? 나에게 그것은 HAL이 완전한 엉망인 것처럼 보입니다.

문서는 이상합니다. 적어도 StdPeriph의 경우 원하는 것을 쉽게 찾을 수 있도록 충분히 잘 정리 된 참조가 있습니다 ( http://stm32.kosyak.info/doc/ ). HAL의 경우 무작위로 보이는 엉터리 PDF ( http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00105879.pdf )가 있습니다. 주변 장치와 같은 섹션을 읽으면 구성 및 사용자 정의 요구 사항을 이해하지 못하는 것 같습니다. 참조보다 물건을 잊고 싶지 않은 사람의 개인 메모처럼 보입니다.

CubeMX를 사용하여 GPIO를 초기화하고 주변 장치를 구성 할 수 있다는 것을 알고 있지만, 저의 목표는 직접 작동하는 것이므로 소프트웨어 작동이 나에게 도움이되지는 않습니다. 내가 뭔가 잘못하고 있습니까? 나를 혼란스럽게하는 것은 ARM의 초보자입니까? 아니면 사용 가능한 문서가 나쁜가요?

자신 만의 라이브러리를 만드는 것은 매우 간단합니다. 레지스터 사양 문서는 대부분의 주변 장치가 설정하기 쉽지는 않지만 매우 좋습니다. 그들의 라이브러리를 사용하는 것이 훨씬 더 고통 스럽습니다. 그러나 아마도 그것은 단지 나일 것입니다. 이것은 st, nxp, ti, atmel에게는 몇 가지 이름이 있습니다 (인텔 및 마이크로 칩에는 그다지 중요하지 않습니다).

왜 그들은 도서관을 바꾸고 여러 가지 이유가있을 수 있으며, 일부 새로운 상사가 인수하고, 일부 부서는 다른 사업부를 인수했습니다. 마케팅은 제품에 대한 새로운 이미지를 원했습니다. ElectronS가 언급했듯이, 베어 메탈을 기꺼이 할 수 없거나 할 수없는 사용자를 끌어 들이기 위해 하드웨어에서 더 멀리 추상화하려는 시도 일 수 있습니다. 나는 그것에 대해 더 나아가서 아마 Arduino 현상과 경쟁하려고한다고 말합니다. 어느 mbed와 다른 모든 사람들이 항상 시도하고 실패했습니다 (Arduino 이전에도).

어쨌든 하드웨어에서 멀어 질수록 부풀어 오르고 느려지기 때문에 단위 당 rom, ram 및 mhz에 더 많이 소비해야합니다. 프로그래밍에 같은 시간을 소비 할 수 있습니까? 그냥 다르게 해?

당신은 PIC 세계에서 왔다고 말합니다. 이제 그들은 도구로 괜찮은 일을했고 칩 문서는 끔찍했습니다. 그들은 라이브러리와 샌드 박스로 보상했습니다.

하루가 끝나면 다양한 옵션을 시도하고 경쟁 제품을 사용하여 도구를 비교하십시오. 그것이 의미가 있는지 확인하고 물건을 컴파일 할 수 있는지 확인하기 위해 많은 것을 무료로 할 수 있습니다. 아마도 명령어 세트 시뮬레이터를 사용할 수도 있습니다. 당신에게 맞는 것을 찾으십시오.

미리 준비된 라이브러리가없는 옵션은 항상 사용할 수 있습니다. 어떤 툴체인을 사용할 수 있는지, 어떤 호스트 운영 체제, 어떤 IDE, 편집기 등으로 제한되지는 않습니다. 부품 측면에서 옵션이 극도로 제한되어 있으면 부품을 프로그래밍하는 데 도움이 될 수 있습니다. 다른 칩으로 이동하십시오. 또는 가능하다면 공급 업체.

이와 같은 칩 제품을 판매하기 위해서는 모든 것이든지 또는 결합 된 무료 제품이든 개발 환경을 제공해야합니다. 그리고 그들은 일종의 도서관을 모으는 경향이 있습니다. 그것은 단지보기 만하면 좋을뿐 아니라 LED 예제는 경영진이나 하드웨어 팀이 제품을 디자인 할 수있을 정도로 잘 작동해야합니다. 그런 다음 보드 제품이 소프트웨어를 통해 벽에 던져 질 때 도착하거나 도착하지 않습니다. 그것이 거의 효과가 있지만 칩 벤더에게는 큰 승리가 아니라면 이제 마지막 부분에 대한 기술 지원 비용을 지불하게됩니다. 따라서 거의 거기에 있지만 완전히 그렇지 않은 것이 그들의 최선의 이익입니다.

칩 벤더는 설계에서 이길 수있을 정도로만 좋아야합니다. 신규 및 기존 고객을 유치하기 위해 제품을 계속 개선 (? 변경)해야합니다. 그래서 그들은 계속 지원하고있는 얼마나 많은 이전 라이브러리들과 얼마나 많은 선행 라이브러리들을 가질 것입니다. 따라서 익숙한 라이브러리는 결국 사라질 것입니다. 따라서 적응하는 법을 배우십시오 (또는 자신의 물건을 사용하지 말고 자신의 것을 가십시오. 무한하게 지원할 수 있습니다). 이상적으로는 제품 당 한 번만 응용 프로그램을 개발하고 펌웨어를 완벽하게 만들면 (타사 라이브러리를 사용하는 경우 행운을 빕니다), 다시 찾아서 툴체인을로드 할 컴퓨터를 찾을 필요가 없습니다. 그 사본을 복사하고 오래된 라이브러리를 사용하는 방법을 기억하십시오. 소스 코드를 저장해야 할뿐만 아니라 모든 도구와 문서를 저장해야합니다.

그들의 라이브러리는 일반적으로 하나의 툴체인, 하나의 두 IDE에서, 때로는 Windows 및 특정 버전에서만 지원됩니다. 다시 말하지만 자신의 일을하는 경우 ARM에는 적용되지 않는 제한 사항이 없습니다. 라이브러리의 모든 / 모든 라이브러리를 읽고 어떻게 작동하는지 확인할 수 있습니다. 그러나 그것은 종종 매우 무섭습니다. 그들은 A 팀 개발자를 도서관에 사용하지 않습니다. 인터뷰 후보자 에게이 코드의 문제점을 묻기 위해 몇 줄의 코드를 추출했습니다.

실리콘 측면과 소프트웨어 측면 모두에서 시간과 노력을 절약하기 위해 종종 동일한 IP를 재활용하므로 주변 장치가 칩 중 하나에서 어떻게 작동하는지 알게되면 다른 많은 칩에서도 동일한 방식으로 작동합니다. 예. 시계 시스템은 라이브러리 유무에 관계없이 까다로울 수 있습니다. 칩을 브릭 킹 할 가능성이 높습니다. 즉, 대부분의 칩 / 보드 브릭 킹이 발생했습니다. 칩이 리셋되는 동안 칩이 작동하는 방식을 이해하는 데 도움이됩니다 .AVR은 대부분은 아니지만 칩을 리셋하는 동안 다시 프로그래밍 할 수 있으므로 다시 프로그래밍하는 데 필요한 핀을 엉망으로 만들거나 다시 프로그래밍하는 데 필요한 로직을 중단시키는 잘못된 코드 문제는 칩을 다시 프로그래밍 할 수 있다는 것입니다. 이러한 공급 업체 중 일부 (하나는 하나임)에는 스트랩을 사용하여 선택할 수있는 내부 부트 로더 (예 : 세계에서는 BOOT0)가 있습니다.

하나의 크기는 모든 사람에게 잘 맞습니다. 소프트웨어의 경우 특히 그렇습니다. 따라서 하드웨어를 추상화하려는 시도는 느리고 부풀어 오른다. 더 큰 칩을 얻고 리눅스를 실행할 수도 있습니다. 그러나 이것의 많은 부분은 개발자의 결과이며, 손을 더럽 히고 싶지 않기 때문에 기본적으로이를 요구했으며 공급하려고합니다.

다시 말하지만 st 또는 한 공급 업체에 얽매이지 마십시오 (너무 늦고 관리 및 하드웨어 팀이이를 고수하지 않는 한 stm32 제품은 훌륭하고 사용하기 쉽습니다). 주변에 물색. TI는 cortex-m4 바구니에 많은 알을 넣습니다. 공급 업체가 지원하는 솔루션뿐만 아니라 이러한 여러 팔 제품에서 mbed 작업을 수행 할 수 있습니다.

항상 의지 할 수있는 것은 라이브러리가 때때로 라이브러리를 변경하고 결국 익숙했던 라이브러리의 지원을 중단한다는 것입니다.

우리 중 많은 사람들이 HAL 라이브러리와 똑같은 실망을 공유한다고 말하고 싶습니다. 실제로 가볍고 모호하게 문서화되어 있으며 여전히 새로운 버그가 많이 있습니다.

귀하의 질문에 대답하기 위해 ST가 HAL을 결정한 이유는 간단합니다.

1. 그들은 평범한 영어로 소프트웨어 개발과 코드가 마이크로 컨트롤러와 독립적이기를 원한다는 것을 의미하는 하드웨어 추상화 계층을 만들고 싶어합니다. 따라서 오늘 stm32f4의 코드를 작성하고 몇 년 후에 stm32f7로 마이그레이션 해야하는 경우 쉬울 것이고 코드는 고도로 모듈화 될 것입니다.

2. 또한 소프트웨어 프로그래머와 같은 더 많은 개발자가 하드웨어가 작업을 수행하는 방법에 대한 자세한 내용을 이해하거나 이해하지 않고도 마이크로 컨트롤러를 사용할 수 있습니다. ST와 TI와 같은 회사 (지금이 도로에서 시작)는 고급 드라이버를 사용하여 코드 FAST를 개발하는 PC 코드 개발과 유사한 임베디드 개발을 시도하고 있습니다. 드라이버 및 라이브러리의 어색함과 최적화 부족은 ARM 장치의 고성능으로 보상됩니다.

3. HAL 라이브러리를 사용하는 경우 STM32cubeMX가 가장 유용한 도구라고 생각합니다. 가장 많은 시간이 걸리는 작업은 주변 장치를 초기화하는 것이며 이제는 사용자 코드에 영향을주지 않고 쉽게 변경할 수있는 시각적 인터페이스를 통해 매우 짧은 시간 안에 수행 할 수 있기 때문입니다 ( 적절한 위치에 코드를 작성하십시오.) Stm32cubeMx를 사용하여 코드를 검토하고 각 기능을 사용하는 방법과 이유를 이해하려고 시도합니다. 이러한 방법으로 운동을 해결하려고 시도하고 수정을 위해 솔루션 매뉴얼을 근처에 배치하려고합니다. 훌륭한 IMO.

4. ARM 코어는 조용히 복잡하므로 레지스터를 직접 처리 (조립 방식으로 C 작성)하는 등 8 비트 마이크로 컨트롤러에서 사용했던 기존 방법은 불가능하며 시간이 많이 걸리고 복잡한 아키텍처로 인해 코드를 유지하기가 어렵습니다 ( 예를 들어 시계 설정)

나는 이것이 길고 의견이 많을 것이라는 것을 알고 있지만 우리가 HAL을 사용하여 새 제품을 방금 성공적으로 출시 했으므로 고려할 가치가 있다고 생각합니다. 또한 ST에서 일하지 않고 HAL의 모든 부분을 싫어하고 StdPeriph로 프로젝트를 거의 다시 시작했지만 고통을 느꼈지만 이제는 이유를 이해합니다.

첫째, 약간의 배경. 초 저전력 원격 측정 시스템을 개발하고 STM32L1로 제품을 구동합니다. 펌웨어 작업을 시작했을 때, 우리는 (베어 메탈) ST 장치에 대한 일반적인 선택을했습니다. 손으로 모든 작업을 수행하거나 StdPeriph 라이브러리를 사용하거나 HAL을 사용하십시오. ST 직원들은 우리에게 HAL과 함께 갈 것을 확신 시켰습니다. 그것은 고통스럽고 소프트웨어의 버그를 해결해야했고 (I2C 부분은 꽤 오랫동안 우리를 미치게했습니다) 나는 여전히 전체 아키텍처를 싫어합니다. 그러나 작동합니다.

1 년 전에 데스크탑에서 임베디드로 전환했을 때, 나는 이름을 알지 못하거나 파악조차 할 수 없었던 무언가에 놀랐습니다. 시간이 지남에 따라 나는 무엇이 진행되고 있는지, 무슨 일 이 일어나고 있는지 이해할 수 있었다 . 임베디드 세계는 변화하고있다. 실리콘은 매일 더 저렴 해지고 MCU는 더욱 강력하고 다재다능합니다. 크기, 전력 요구에 관계없이 점점 더 많은 장치가 일반 MCU에 의존합니다. 점점 더 많은 회사가 게임에 참여하여 다양한 배경을 가진 많은 새로운 개발자를 불러옵니다. "평균"문화는 전통적인 "프로그래밍 마법사 기술을 가진 EE 녀석"에서 "모호한 하드웨어 지식을 가진 SW 녀석"으로 표류합니다.

이것이 좋든 나쁘 든 상관 없습니다. 그냥 일어난다. 실제로 소프트웨어 소프트웨어에도 두 번 이상 발생했습니다. 2000 년 웹 붐은 PHP / MySQL 초보자를 끌어 들였습니다. CPU에 레지스터가 있다고 말하면 "Linux를 사용하고 있으므로 OS에 레지스트리가 없습니다"라고 대답합니다. 이전에는 보호 모드에서 실행되는 다중 사용자 OS를 사용하여 게으른 개발자가 전체 경력에서 ISR을 설정하지 않고 괜찮을 수 있었습니다. 이전에는 키보드와 스크린으로 카드 펀처와 프린터 제조업체가 열광했습니다.

_{그리고 그렇습니다. 현재의 트렌드는 개인적으로 슬프게 만듭니다. 저는 무지한 개발자가 최신 빛나는 기술에 경외심을 느끼지만 완전히 역사와 연결할 수는 없습니다. 2015 년에 WebGL을 사용하여 Javascript로 게임을 코딩하는 어린 시절을 보았을 때, "새로운 것이 없다! 1995 년에 C ++과 3Dfx SDK로 같은 일을했다고!" 이야기에서 알 수없는 것은 그의 게임이 내 휴대 전화에서 실행되는 반면 내 게임에는 게이머 PC (및 설치 프로그램이 필요했으며 웹으로 업데이트를 푸시 할 수 없음)였습니다. 사실, 그가 개발할 수있는 것은 한 달 만에 게임이며, 여기서 6 살에서 12 살까지 똑같이했습니다.}

분명히 ST 나 TI, 인텔 또는 칩을 제조하는 사람은 그 방향을 놓치고 싶어하지 않습니다. 그리고 그들은 옳습니다. HAL은 ST의 답변이며 실제로 비즈니스 또는 마케팅 측면뿐만 아니라 엔지니어링 측면에서도 상당히 건전합니다. 소리가 나는 이유는 이름에 있습니다.

하드웨어 추상화 계층

다른 것이 있다면, 이것은 당신이 기억해야 할 것입니다. HAL은 하드웨어에서 벗어나기위한 노력입니다. 기능을 세부 사항에서 분리 할 수 ​​있기 때문에 훌륭한 엔지니어링입니다. 계층화는 복잡한 프로그램을 개발할 수있게 해주는 것입니다. 하나는 추상화에서 다른 것까지, 하드웨어에 이르기까지 다양합니다. 추상화는 실제로 복잡성을 관리하는 데 가장 강력한 도구 입니다. 나는 지구상의 누군가가 특정 CPU를 위해 어셈블리로 웹 브라우저를 프로그래밍 할 수 있을지 의문이다.

문화적 변화는 실제로 소화하기는 어렵지만, 웹 애플리케이션을 개발하기 위해 Knuth의 컴퓨터 프로그래밍 기술을 읽을 필요가 없기 때문에 EE 세계는 임베디드 코드를 개발할 수있는 새로운 사람들이 있다는 것을 인정해야합니다. Fucking Holy Reference Manual 을 읽지 않고 .

좋은 소식은 새로운 선수가 나이가 많은 선수의 업무를 덜 의미하지는 않는다는 것과는 정반대의 IMHO입니다. 일이 "작동하지 않을 때"누구에게 전화 할 것입니까? RTFM이 있고 (그것과는 달리)이 모호한 구성 레지스터의 각 비트가 무엇을 하는지를 알고 있다면 이점이 있습니다.

독서와 실험 사이에 HAL을 사용하십시오. 새로운 MCU? 문제 없어. 새로운 MCU 라인? 문제도 없습니다 (CubeMX로 하루 만에 STM32F4 Nucleo에서 테스트를 코딩 한 다음 단순히 장치에 이식했습니다 ... 방금 느꼈 습니다 ). 단위 테스트를위한 조롱? 문제 없어. 추상화가 좋기 때문에 목록이 계속 진행됩니다.

물론 HAL 자체는 100 % 괜찮습니다. 그것은 문서가 끔찍합니다 (그러나 RT F HRM이 있지만 그렇지 않습니까?), 버그가 있습니다 .ST는 단지 베타 버전을 우리에게 버렸습니다 (요즘 꽤 표준으로 보입니다). 그리고 그들의 공공 지원은 농담입니다. 그러나 HAL을 공개하지 않으면 더 나빴을 것입니다.