BLE 관련 대표적인 제조 업체인 Nordic에서 판매 하는 제품입니다.

배터리를 사용 하는 저전력 IoT 제품의 경우 개발 중에 소모 전류 검증이 필요 한데요.

보통 저전력 제품들은 아래와 같이 여러 power state로 나눠어져 동작 하게 됩니다.

sleep : 최소 소모 전류 상태

idle : sleep - run 중간 상태

run : 동작 상태

기타..

위와 같인 이유로 전류값이 동적으로 빠르게 변하기 때문에 측정 하고자 하는 시간에 대해 평균 전류를 구해야 합니다.

따라서 빠르게 전류 값이 로깅되는 기능이 없는 일반적인 멀티미터로 정확하게 측정 하는게 어렵습니다.

대부분의 벤치형 DMM은 PC와 연동되는 측정 프로그램을 따로 구매 하거나 해야 합니다.

그래서 아래와 같은 측정 보조 장비로 세밀하게 전류 샘플링 후 평균값을 도출 하게 됩니다.

가격은 12~13만원 정도 하는 것 같습니다.

https://www.nordicsemi.com/Products/Development-hardware/Power-Profiler-Kit-2/Download#infotabs

아래와 같이 USB전원을 이용해 자체 전원을 만들어 낼 수도 있고(프로그래머블 물론 5V 이하 전압), 전류계처럼 기존 파워라인에 삽입되어 측정이 가능합니다(이것도 5V 이하 전압). 약간 아쉽게도 5V이내 전원만 사용이 가능합니다. 

프로그램 상에서는 샘플링 주파수 조절에 따라 장시간 측정도 가능합니다.(몇 시간)

주의 할 점은 NORDIC 프로그램들이 WIN7을 제대로 지원을 하지 않습니다. 가급적 WIN10 이상 사용 하시는게 좋습니다.

개발 환경에 어울리는지 잘 검토 하시고, 사용 해보시길 바랍니다.

먼지 센서?  

Particle Sensor

기존 센서들이 미세 먼지가 심한 중국에서 만든 제품들이 많았는데요.

먼지 센서 모듈들의 문제점은 다음과 같습니다.

1. 소형 팬을 동반하기 때문에 팬 수명과 제품 수명이 동일하게 된다.

   (일반적으로 반도체보다 모터 구동의 팬 수명이 짧다)

2. 모듈 특성에 의해 먼지을 포함한 공기들이 순환되면서

   오랜 시간 먼지에 노출 되면 내부에 이물질이 쌓여서 측정 데이터가 신뢰할 수 없는 상태가 됩니다.

개인적으로는 실내에서 사용하는 제품들은 크게 상관없을 것 같기는 한데, 

Outdoor용 제품이 되면 문제가 있을 것 같습니다.

그런 부분들을 해결한 제품이 Sensirion에서 새로 나온 것 같습니다.

Digikey나 Mouser에서도 구매 가능한 상태 입니다.

제품 링크

https://www.sensirion.com/en/environmental-sensors/particulate-matter-sensors-pm25/

제품 리뷰?

https://www.azosensors.com/article.aspx?ArticleID=1447

제품 리뷰?

https://www.mistywest.com/posts/teardown-sensirion-particle-matter-sensor/

컴파일러마다 build/debug 단축키가 다르죠..

SDTM32CubeIDE에서 단축키 설정 하는 방법 입니다.

Shortcut 용어가 아닌 Binding 용어가 사용되네요.

저는 컴파일은 F7 디버그는 F5로 사용 합니다!!

아래와 같은 CubeIDE 버젼 사용중입니다.

STM32CubeIDE
Version: 1.2.1

CubeIDE Ver

간단하게 STM32G4 테스트 하기 위해 NUCLEO-G474RE보드를 사용 했습니다.

freertos옵션없이 생성된 코드에서는 uart printf가 정상 동작 하지만

freertos옵션을 enable하여 생성된 코드에서 printf가 정상 동작 하지 않고 hardfault로 빠져 버립니다.

검색 중에 다음과 같은 내용이 있어서 "Memory Management scheme" 항목에서 heap_5에서 heap_3로 변경하니 문제가 해결 되었습니다.

관련 내용 링크 입니다.

https://docs.aws.amazon.com/ko_kr/freertos-kernel/latest/dg/troubleshooting.html

freertos 메모리 관리 방법

https://docs.aws.amazon.com/ko_kr/freertos-kernel/latest/dg/heap-management.html#memory-allocation-schemes

검색 중에 재미난 디바이스가 있어서 소개 드립니다.

보통 메모리 특성은 아래와 같습니다.

EEPROM은 작은 용량의 데이터를 반복적으로 많은 횟수로 기록 할때 적합한 디바이스 입니다.

단점은 쓰기가 느리다는 겁니다. 

RTOS상에서 구현하다 보면 5ms~15ms 까지 delay상황이 연출 되는데,

단순히 쓰기 완료을 기다릴지, 큐등으로 버퍼링 해서 독립적으로 관리 할지 여러가지 선택 상황에 놓이게 됩니다.

제일 좋은건 짧은 write시간으로 고민 없이 지나가는 겁니다.

그래서 위의 표와 같이 FRAM이 나오게 되고 이런 고민을 없게 만듭니다.

하지만 가격이 비싸죠.

자동차도 하이브리가 있듯이 EEPROM도 하이브리드 형태의 디바이스가 Micochips에서 나왔네요.

아래 영상 보면 그냥 이해가 될겁니다.

전원이 안정된 상태에서는 SRAM처럼 고속 write을 지원하고, 

전원이 off되면 캐패시터의 남아 있는 전기를 활용해서 SRAM내용을 EEPROM에 기록 하는 형태 입니다.

디바이스 마다 틀리겠지만 약 33uF Capacitor을 권장 하네요. small이라면서... -_-;; 

참고로 FRAM 소개 자료도 링크로 남겨둡니다.

https://www.fujitsu.com/global/documents/products/devices/semiconductor/fram/overview/brochure/AD05-00033-11K.pdf

노르딕 SDK는 여러 컴파일러를 지원 합니다.

기존 상용 컴파일러를 지원 하던 중에( Keil, IAR ) 현재는 SEGGER사(JLink 만드는 독일 회사)와 계약을 했는지

nRF 씨리즈에 한정하여 무료로 사용 할 수 있습니다.

SDK 업데이트 하면서 기존 Keil버젼은 더 이상 지원하지 않아서 SEGGER로 변경 해보았는데,

생각 보다 괜찮습니다.

JLink 기술의 원천 회사 라서 그런지 괴랄하게 빠른 flash download속도와 디버깅 속도를 보여 주네요.

아무튼...

SDK 사용중에는 sdk_config.h을 자주 건드리게 되는데, 기존에 Keil의 경우 GUI Wizard형식으로 보기가 편하게 

되어 있습니다.

이게 SEGGER에서는 지원하지 않는 줄 알고, 우울해지려고 할 타임에 검색 해보니 플러그인 형태로 지원 하는게 있네요.

설정 하는 법 유튜브 링크

https://www.youtube.com/watch?v=b0MxWaAjMco&list=PLx_tBuQ_KSqGHmzdEL2GWEOeix-S5rgTV&index=4

설정법

File-Open Studio Folder..-External Tools Configuration 에서 아래 문구를 넣어 주면 됩니다.

<tools>

  <!-- PC-lint - http://www.gimpel.com/html/pcl.htm -->

  <if host_os="win">
    <item name="Tool.PClint">
      <menu>&amp;PC-lint (Unit Check)</menu>
      <text>PC-lint (Unit Check)</text>
      <tip>Run a PC-lint unit checkout on the selected file or folder</tip>
      <key>Ctrl+L, Ctrl+P</key>
      <match>*.c;*.cpp</match>
      <message>Linting</message>
      <commands>
        &quot;$(LINTDIR)/lint-nt&quot; -v -incvar(__CW_ARM) -i$(LINTDIR)/lnt co-gcc.lnt $(DEFINES) $(INCLUDES) -D__GNUC__ -u -b +macros +macros -w2 -e537 +fie +ffn -width(0,4) -hF1 &quot;-format=%f:%l:%C:\s%t:\s%m [-e%n]&quot; &quot;$(InputPath)&quot;
      </commands>
    </item>
    <item name="Tool.CMSIS_Config_Wizard" wait="no">
      <menu>&amp;CMSIS Configuration Wizard</menu>
      <text>CMSIS Configuration Wizard</text>
      <tip>Open a configuration file in CMSIS Configuration Wizard</tip>
      <key>Ctrl+Y</key>
      <match>*config*.h</match>
      <message>CMSIS Config</message>
      <commands>
        java -jar &quot;$(CMSIS_CONFIG_TOOL)&quot; &quot;$(InputPath)&quot;
      </commands>
    </item>
  </if>

</tools>

추가로

sdk_config.h 설정에 관한 문법 설명 입니다.

https://www.keil.com/pack/doc/CMSIS/Pack/html/configWizard.html

Nordic의 경우 일반적인 PDF보다 Online Support가 더 활성화 되어 있습니다.

Infocenter나 DevZone이 그렇죠. 

일반적인 예제 활용부터 시작해서 SDK API 함수까지 모든 설명을 Online Infocenter에서 찾아 볼 수 있습니다.

근데 Online이라 좀 느려요.

아래 링크에서 Offline문서를 다운 받아서 index.html을 크롬으로 보시면 훨씬 쾌적하게 문서들을 살펴 볼 수 있습니다.

https://developer.nordicsemi.com/

nRF52832의 경우 내부 Core전압으로 1.3V 사용 합니다.

이때 필요한게 Regulator인데, nRF52832의 경우 외부 회로에 L,C 만 추가 하면 LDO/DCDC 모두 사용 가능 합니다.

당연 하게도 DCDC일 경우 소모 전류는 드라마틱 하게 줄어 들게 됩니다.

단순 Advertise Mode에서 약 42%이상 소모 전류를 줄일 수 있습니다.

사용자가 SW 설정을 안 할 경우 Default LDO입니다.

따라서 SDK에서 제공하는 모든 기존 예제들은 Default LDO 모드로 동작 하게 됩니다.

DCDC일 활성화 위해서는 아래와 같은 함수를 Call하면 됩니다.

  ble_stack_init();
  /* 외부 회로가 dcdc 지원하면, dcdc mode enable하여 전류를 소모를 많이 줄일 수 있다 */
  /* 아무데서나 호출하면 안되고 ble_stack_init() 후 호출 */
  sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);  

일반적으로 DCDC는 Noise성분을 많이 발생 시키는데, 이에 따른 RF성능 저하는 따로 확인 되지 않았습니다.

Nordic Online Power Profiler Link

https://devzone.nordicsemi.com/nordic/power

CAN 작업중에 CubeMx의 HAL 함수 단에서 DeInit과 Init을 해도 CAN Register가 초기화가 안됨. 

특히 CAN 오류 발생시 ESR Register들의 값들이 DeInit또는 Init후 그대로 남아 있음.

HAL_StatusTypeDef HAL_CAN_Init(CAN_HandleTypeDef *hcan)
HAL_StatusTypeDef HAL_CAN_DeInit(CAN_HandleTypeDef *hcan)

MspInit/DeInit에서 CLK 관련 매크로들이 호출 되어 이상 없는 듯 했으니 그건 아니고...

"CAN_MCR_RESET" Define이 포함되어 있어 당연히 Reset이 될것 같으나 그것도 아니고..

void HAL_CAN_MspInit(CAN_HandleTypeDef* hcan)
void HAL_CAN_MspDeInit(CAN_HandleTypeDef* hcan)
    
__HAL_RCC_CAN1_CLK_ENABLE();
__HAL_RCC_CAN1_CLK_DISABLE();
SET_BIT(hcan->Instance->MCR, CAN_MCR_RESET);

아래와 같은 매크로 사용자가 수동으로 호출을 해서 CAN Register 초기화 필요함. 필요시....

__HAL_RCC_CAN1_FORCE_RESET();
__HAL_RCC_CAN1_RELEASE_RESET();

이건 CAN관련 뿐만이 아니라 다른 Peripheral Register도 마찬가지

하고 싶은 이야기는 HAL 드라이버의 Init/DeInit을 해도 관련 Peripheral Register가 HW적으로 리셋되는건 아니라는것..

수고..........

ST에서 맨 처음에 나온게 SPL 드라이버 입니다. (Standard Peripheral Library)

현재 포지션에서도 그렇게 예전에도 그렇고 딱 중간 만큼 좋은 드라이버 입니다. 위,아래로 커버가 가능한..

그 다음에 STM32Cube HAL 드라이버인데....

이게 좀 처음 나왔을때는 겁나 좋은건가?? 했는데... 기존에 SPL드라이버 쓰던 사람들은 적응 불가 입니다.

더구나, SPL드라이버 베이스로 작업해놓은 FW LIB들이 모두 무용지물이 됩니다. 혼용 불가...

더해서 ST에서는 새로운 MCU제품군에서는 SPL드라이버 지원을 하지 않게 됩니다. F7, L0, L4

외국 포럼등에서도 저와 같이 SPL드라이버를 계속 지원 요청하는 글들이 많이 보입니다.

하지만 다 나쁠수는 없고, STM32Cube HAL 드라이버는 ST에서 나오는 수백가지 MCU제품군을 단 몇 분만에 사용자 정의 실행 가능한 기본 코드가 생성하는 

대단한 면도 있습니다. 개발자로서는 포기 하기 어렵죠.

위와 같은 cube 단점을 커버하기 위해? ST에서 STM32Cube LL(LowLevel) 지원을 하면서 사실상 SPL은 더 이상 지원하지 않을 것 같습니다.

LL드라이버는 CUBE설치후 LIB Update하면 볼 수 있는데, 대부분의 code가  header 에서 inline 함수로 register direct access 위주로 만들어져 있습니다.

올해 1분기에 모든 제품군에 대해서 LL 드라이버 지원을 하게 됩니다. 

사실상 CUBE 가 Main이 되는거죠