최신 센서와의 인터페이스:폴링된 ADC 드라이버

지난 포스트에서 우리는 현대적인 임베디드 애플리케이션에서 개발자가 애플리케이션 코드에서 저수준 드라이버 구현 세부 사항을 분리하는 인터페이스를 만드는 방법을 조사했습니다. 이 인터페이스는 하드웨어 의존도를 낮추어 애플리케이션 코드의 확장성과 이식성을 높이는 아키텍처 추상화를 제공합니다.

이제 우리는 마이크로컨트롤러를 위한 3가지 드라이버 설계 기술에서 논의한 기술을 기반으로 개발자가 ADC 드라이버를 구현할 수 있는 몇 가지 다른 방법을 살펴보기 시작합니다. 이 기사에서는 폴링 기술을 사용하는 방법을 더 자세히 살펴보고 차단 드라이버와 비차단 드라이버의 차이점에 대해 논의합니다.

차단이냐 차단이냐 그것이 문제로

마이크로컨트롤러용 드라이버를 개발할 때 개발자는 드라이버가 차단할지 아니면 비차단할지 결정해야 합니다. 차단 드라이버는 기본적으로 드라이버가 작업을 완료할 때까지 코드 실행을 중단합니다. 예를 들어 UART에 매핑되는 printf의 일반적인 구현은 차단입니다.

다음과 같이 전화를 걸 때:

printf("안녕하세요!");

개발자는 해당 명령문 뒤에 오는 코드 줄이 전체 "Hello World!"가 될 때까지 실행되지 않는다는 것을 알고 있습니다. 성명서가 UART로 인쇄되었습니다. "안녕 월드!" 12바이트, 96비트를 포함하지만 명령문이 차단되는 시간은 UART 전송 속도에 따라 다릅니다. 1Mbps로 구성된 UART의 경우 약 96마이크로초가 예상됩니다. 9600bps로 구성된 UART의 경우 약 10,000마이크로초가 예상됩니다! 하드웨어를 어떻게 구성하느냐에 따라 큰 차이가 나고 UART 드라이버를 블로킹 드라이버로 구성해 프로그램 실행에 큰 영향을 미칠 수 있다.

비차단 드라이버는 드라이버가 작업을 완료하는 동안 프로그램 실행을 지연시키지 않는 드라이버입니다. 예를 들어, 이전 예제의 printf 및 UART 드라이버는 차단하지 않고 대신 각 바이트가 UART 밖으로 전송되는 동안 애플리케이션이 계속 실행되도록 구성할 수 있습니다. 이것은 올바른 상황에서 보다 효율적인 애플리케이션을 만들 수 있지만 인터럽트, DMA 또는 적어도 전송 버퍼를 사용하는 것과 같은 추가 설정이 필요합니다.

드라이버를 설계하는 방법을 결정하는 것은 응용 프로그램과 하드웨어에 따라 다릅니다. 예를 들어 UART가 1Mbps로 구성된 경우 비차단 드라이버를 작성하는 것은 효율성 측면에서 많은 이점을 얻지 못할 것이며 실제로 추가 프로그램 복잡성을 통해 해결하는 것보다 더 많은 문제를 일으킬 수 있습니다. 그러나 애플리케이션이 9600bps를 요구하는 경우 애플리케이션 코드가 10밀리초 동안 차단되는 경우 비차단 드라이버를 사용하면 프로그램 효율성이 크게 향상되고 추가 타이밍 복잡성 문제에 대한 위험이 훨씬 줄어들고 관리하기 쉬워집니다.

내장 ADC 드라이버 개요

하나의 블로그에서 전체 ADC 드라이버를 작성하는 데 필요한 모든 단계를 수행할 수 없다는 점에 유의하는 것이 중요합니다. 20페이지 분량의 논문을 쉽게 작성하거나 전체 웨비나를 제공할 수 있으며 여전히 모든 세부 사항을 다루지는 않을 수 있지만 최소한 핵심 부분은 볼 수 있습니다.

ADC 드라이버를 구성하는 방법에는 여러 가지가 있지만 제가 좋아하는 구성에는 세 가지 구성 요소가 필요합니다.

<울>

저수준 드라이버

응용 프로그램 코드

구성 모듈

저수준 드라이버는 초기화 중에 구성 모듈을 가져와 구성을 기반으로 하드웨어를 설정합니다. 저수준 드라이버는 응용 프로그램 코드에서 사용할 수 있는 공통 하드웨어 추상화 계층(HAL)을 제공합니다. ADC HAL 호출은 고급 응용 프로그램이 필요한 방식으로 하드웨어를 구성하고 재사용 및 확장할 수 있도록 일반적이어야 합니다. 예를 들어 과거에 사용한 몇 가지 ADC HAL 호출은 다음과 같습니다.

<울>

AdcError_t Adc_Init(const AdcConfig_t * 구성);

AdcError_t Adc_StartConversion(무효);

bool Adc_ConversionComplete(무효);

무효 Adc_RegisterWrite(uint32_t const 주소, uint32_t const 값);

uint32_t Adc_RegisterRead(uint32_t 주소);

무효 Adc_CallbackRegister(AdcCallback_t const 함수, 유형(*CallbackFunction)(유형));

처음 세 API는 ADC 하드웨어를 초기화하고 변환을 시작한 다음 변환 상태를 확인하는 기능을 제공합니다. 마지막 세 가지 기능은 저수준 하드웨어로 확장할 수 있도록 설계되었습니다. 예를 들어 HAL이 단일 ADC 채널 변환과 같이 애플리케이션에서 필요한 옵션을 제공하지 않는 경우 Adc_RegisterRead 및 Adc_RegisterWrite 함수를 사용하여 HAL을 확장할 수 있습니다. 이는 압도적인 API를 생성하지 않고도 애플리케이션 요구 사항에 따라 유연성을 제공합니다.

간단한 차단 ADC 드라이버 작성

하드웨어 계층 위에 있는 정말 간단한 ADC 드라이버를 작성할 수 있습니다. 예를 들어 ADC 하드웨어를 시작한 다음 모든 결과를 응용 프로그램에서 액세스할 수 있는 버퍼에 저장하는 Adc_Sample이라는 간단한 함수를 만들 수 있습니다. 아날로그 값 카운트 값을 저장하는 버퍼는 단일 값만 저장할 필요는 없지만 나중에 애플리케이션 요구에 따라 평균화하거나 필터링할 수 있는 여러 값을 저장할 수 있습니다. 샘플링 기능의 차단 버전은 다음과 같을 수 있습니다.

이 코드에서 볼 수 있듯이 while 루프는 ADC 하드웨어가 변환을 완료할 때까지 실행을 차단한 다음 애플리케이션 버퍼에 값을 저장합니다.

간단한 비차단 ADC 드라이버 작성

차단 드라이버를 비차단 코드로 변환하는 것은 매우 간단하지만 더 높은 수준의 애플리케이션 코드를 변경해야 합니다. 예를 들어, 지금 애플리케이션이 센서를 샘플링하려는 경우 개발자는 다음을 호출합니다.

Adc_Sample();

비차단 버전에서 개발자는 샘플이 완료되고 사용할 준비가 되었는지 확인하기 위해 Adc_Sample의 반환 값을 확인해야 합니다. 이렇게 하면 샘플이 백그라운드에서 실행되고 애플리케이션 코드가 드라이버 코드에 대한 다음 업데이트와 함께 계속 실행될 수 있습니다.

결론

이 게시물에서 보았듯이 ADC를 작성하는 방법에는 여러 가지가 있으며 구현은 필요에 따라 차단 또는 비차단이 될 수 있습니다. 차단 드라이버는 비 차단 드라이버보다 간단하고 덜 완전한 경향이 있지만 비효율적일 수 있습니다. 비차단 드라이버를 사용하면 드라이버가 작동하는 동안 다른 코드를 실행할 수 있지만 애플리케이션 코드는 여전히 폴링 구현에서 그 자체로 비효율적인 상태를 체크인해야 합니다.

이 시리즈의 다음 기사에서는 인터럽트를 사용하는 ADC 주변기기를 통해 센서를 샘플링하는 애플리케이션을 작성하는 방법을 살펴보겠습니다.