Interface com sensores modernos:Drivers ADC pesquisados ​​

Na última postagem, examinamos como em um aplicativo integrado moderno um desenvolvedor deve criar uma interface que desacopla os detalhes de implementação do driver de baixo nível do código do aplicativo. Essa interface fornece uma abstração arquitetônica que aumenta a escalabilidade e a portabilidade do código do aplicativo, tornando-o menos dependente do hardware.

Agora vamos começar a ver as várias maneiras diferentes pelas quais um desenvolvedor pode implementar um driver ADC com base nas técnicas que discutimos em 3 técnicas de design de driver para microcontroladores. Neste artigo, examinaremos com mais detalhes como podemos usar a técnica de pesquisa e discutiremos a diferença entre drivers bloqueadores e não bloqueadores.

Para bloquear ou não bloquear, essa é a questão

Ao desenvolver qualquer driver para um microcontrolador, o desenvolvedor deve decidir se seu driver bloqueará ou não bloqueará. Um driver de bloqueio basicamente paralisa a execução do código até que o driver conclua sua tarefa. Por exemplo, a implementação típica de printf mapeada para um UART é o bloqueio.

Quando você faz uma chamada como:

printf (“Olá, mundo!”);

Um desenvolvedor sabe que qualquer linha de código que segue essa instrução não será executada até todo o “Hello World!” declaração foi impressa no UART. "Olá Mundo!" contém doze bytes, 96 bits, mas a quantidade de tempo que a instrução bloqueará depende da taxa de transmissão UART. Para um UART configurado a 1 Mbps, você esperaria cerca de 96 microssegundos. Para um UART configurado a 9600 bps, você esperaria cerca de 10.000 microssegundos! Isso é uma grande diferença dependendo de como o hardware está configurado e pode afetar a execução do programa drasticamente com o driver UART sendo configurado como um driver de bloqueio.

Um driver sem bloqueio é aquele que não paralisa a execução do programa enquanto o driver está concluindo sua tarefa. Por exemplo, printf e o driver UART do exemplo anterior podem ser configurados para não bloquear e, em vez disso, permitir que o aplicativo continue em execução enquanto cada byte é transmitido para fora do UART. Isso pode tornar a aplicação mais eficiente nas circunstâncias certas, mas requer configuração adicional, como o uso de interrupções, DMA ou pelo menos um buffer de transmissão.

A decisão de como projetar seu driver depende de seu aplicativo e hardware. Por exemplo, se o UART estiver configurado para 1 Mbps, escrever um driver sem bloqueio provavelmente não ganhará muito do ponto de vista de eficiência e pode realmente causar mais problemas do que corrige por meio da complexidade adicional do programa. No entanto, se o aplicativo solicitar 9600 bps, em que o código do aplicativo é bloqueado por 10 milissegundos, ter um driver sem bloqueio pode melhorar drasticamente a eficiência do programa e o risco de problemas adicionais de complexidade de temporização é muito menor e mais gerenciável.

Visão geral de um driver ADC incorporado

É importante observar que em um único blog, não consigo percorrer todas as etapas necessárias para escrever um driver ADC completo. Eu poderia facilmente escrever um artigo de vinte páginas sobre ele ou dar um webinar inteiro e provavelmente ainda não cobriria todos os detalhes, mas podemos pelo menos dar uma olhada em algumas das peças principais.

Existem várias maneiras de organizar um driver ADC, mas a maneira que gosto de organizá-los requer três componentes:

• O driver de baixo nível
• O código do aplicativo
• Um módulo de configuração

O driver de baixo nível pega o módulo de configuração durante a inicialização e define o hardware com base na configuração. O driver de baixo nível fornece uma camada de abstração de hardware (HAL) comum que o código do aplicativo pode usar. As chamadas ADC HAL devem ser genéricas para que o aplicativo de alto nível possa configurar o hardware de qualquer maneira que seja necessária e que possa ser reutilizável e escalonável. Por exemplo, algumas chamadas ADC HAL que usei no passado incluem:

• AdcError_t Adc_Init (const AdcConfig_t * Config);
• AdcError_t Adc_StartConversion (void);
• bool Adc_ConversionComplete (void);
• void Adc_RegisterWrite (uint32_t const Address, uint32_t const Value);
• uint32_t Adc_RegisterRead (endereço uint32_t);
• void Adc_CallbackRegister (AdcCallback_t const Function, TYPE (* CallbackFunction) (type));

As três primeiras APIs fornecem a capacidade de inicializar o hardware ADC, iniciar uma conversão e, em seguida, verificar o status da conversão. As últimas três funções são projetadas para permitir escalabilidade para o hardware de baixo nível. Por exemplo, se o HAL não fornece uma opção que é necessária para o aplicativo, como a conversão de um único canal ADC, o HAL pode ser estendido usando as funções Adc_RegisterRead e Adc_RegisterWrite. Isso fornece flexibilidade com base nas necessidades do aplicativo sem criar uma API excessiva.

Escrevendo um driver ADC de bloqueio simples

Podemos escrever um driver ADC realmente simples que está acima da camada de hardware. Por exemplo, podemos criar uma função simples chamada Adc_Sample que inicia o hardware ADC e, a seguir, armazena todos os resultados em um buffer que pode ser acessado pelo aplicativo. O buffer que armazena os valores de contagem de valores analógicos não precisa necessariamente armazenar apenas um único valor, mas pode armazenar vários valores que podem posteriormente ser calculados ou filtrados com base na necessidade do aplicativo. A versão de bloqueio para a função de amostragem pode ser semelhante a esta:

Como você pode ver neste código, o loop while bloqueia a execução até que o hardware ADC conclua sua conversão e, a seguir, armazena os valores no buffer do aplicativo.

Gravando um driver ADC simples sem bloqueio

Converter o driver de bloqueio em código sem bloqueio é bastante simples, mas exigiria alterações no código do aplicativo de nível superior. Por exemplo, agora, se o aplicativo deseja amostrar os sensores, um desenvolvedor chama:

Adc_Sample ();

Na versão sem bloqueio, um desenvolvedor deve verificar o valor de retorno de Adc_Sample para ver se as amostras estão concluídas e prontas para uso. Isso permite que as amostras sejam executadas em segundo plano, e o código do aplicativo continue em execução com as seguintes atualizações em nosso código de driver:

Conclusões

Como vimos nesta postagem, existem várias maneiras de escrever um ADC e a implementação pode ser bloqueadora ou não, com base em nossas necessidades. Os drivers de bloqueio tendem a ser mais simples e menos completos do que os drivers de não bloqueio, mas podem ser ineficientes. Os drivers sem bloqueio permitem que outro código seja executado enquanto o driver funciona, mas o código do aplicativo ainda precisa verificar o status, que por si só é ineficiente em uma implementação com polling.

No próximo artigo desta série, examinaremos como podemos escrever um aplicativo que faz a amostragem de um sensor por meio de um periférico ADC que usa interrupções.