Os periféricos são fundamentais para a migração.
Muitos projetos começam por especificar as funções que o sistema irá fornecer e como os utilizadores acederão a essas funções.
Isto determinará os circuitos necessários e os periféricos que precisam de ser integrados no microcontrolador para os controlar. Se, por exemplo, o projetista quiser incluir uma Interface Homem-Máquina (IHM) industrial, o microcontrolador terá de suportar um LCD e alguns botões ou um ecrã táctil; uma interface de comunicação com a máquina; LEDs; e um alarme sonoro ou outro componente áudio. Assim sendo, o microcontrolador necessitará de integrar um controlador CAN para comunicação; um conversor A/D para o ecrã táctil; e um temporizador PWM para o alarme sonoro. Quanto maior for a funcionalidade do periférico, menos circuitos externos serão necessários, o que pode reduzir a quantidade de código que o projetista necessita de escrever. Assim, com um alarme sonoro, é mais simples ajustar um PWM para obter o mesmo resultado.
Normalmente, os designers querem saber duas informações fundamentais sobre o kernel: é suficientemente rápido para executar todas as tarefas de software necessárias para suportar todas as características oferecidas pelo produto final? E ele executa todas estas tarefas de forma eficiente? Se a resposta a ambas as questões for sim, a maioria dos projectistas não se preocupará muito com o tipo de kernel utilizado.
Mais relevante é a quantidade de software e firmware existentes que podem ser migrados de um kernel para outro para fornecer suporte a periféricos. Como a maior parte do código dos microcontroladores de 32 bits está escrito em C, grande parte pode ser recompilado para qualquer kernel. No entanto, cada fabricante de microcontroladores terá funções periféricas e modelos de programação exclusivos para os seus próprios produtos, independentemente do kernel utilizado. É isso que torna a portabilidade de código um desafio.
Portabilidade de Firmware:
Cada fabricante de microcontrolador disponibiliza uma biblioteca de firmware contendo o código para configurar e executar os periféricos integrados no seu microcontrolador. No entanto, cada fabricante também implementa estes periféricos de forma diferente, e cada periférico pode ter funções distintas. Isto significa que portar uma aplicação de um microcontrolador para outro não é uma tarefa simples.
A ARM resolveu este problema definindo uma camada de abstração de firmware padrão denominada Cortex™ Microcontroller Software Interface Standard (CMSIS), que foi adotada por todos os fabricantes de microcontroladores que utilizam núcleos Cortex-M e é utilizada nas suas bibliotecas de firmware. No entanto, esta norma não aborda os desafios da portabilidade de periféricos, nem estabeleceu uma convenção de nomenclatura padrão para as variáveis ou funções. Como resultado, pouco contribui para reduzir o esforço e o trabalho necessários para portar uma aplicação entre diferentes fornecedores de microcontroladores ARM.
Projetos de portabilidade:
Embora os fornecedores de microcontroladores possam utilizar o mesmo núcleo ARM, não têm qualquer incentivo para simplificar a portabilidade para microcontroladores de outros fornecedores. O desafio de tornar um projeto portátil recai, portanto, sobre o engenheiro de projeto. Para simplificar a portabilidade, o projetista pode implementar uma camada de abstração para criar uma interface de programação padrão entre o microcontrolador, o hardware periférico e o código da aplicação. Existem pelo menos duas formas de o realizar:
- Pode ser desenvolvida uma camada de compensação ou cobertura para a tradução entre a biblioteca de periféricos do fabricante do microcontrolador e o código da aplicação. Embora esta seja provavelmente a solução mais eficiente em termos de tempo, irá adicionar mais código aos caminhos de comando e de dados.
- Defina um método padrão de nomenclatura de funções e variáveis e aplique-o a cada biblioteca de periféricos. Embora isto evite adicionar código, pode ser demorado, especialmente para periféricos complexos.
A portabilidade deve fazer parte do processo de desenvolvimento desde as fases iniciais. Para além do firmware/software, existe a questão da compatibilidade dos pinos, que geralmente envolve a reconfiguração da placa de circuito impresso quando se muda de fornecedor de microcontroladores. Os componentes externos, como condensadores e reguladores, também podem precisar de ser substituídos.
Portabilidade no mundo real:
A fácil portabilidade entre microcontroladores de 32 bits de diferentes fornecedores continua a ser um desejo da indústria até que os problemas de portabilidade de periféricos e bibliotecas de firmware sejam resolvidos. Até lá, os projetistas devem assumir a responsabilidade pela portabilidade dos seus projetos. Uma forma de mitigar isto é escolher um microcontrolador que facilite a migração para outros microcontroladores dentro da mesma linha de produtos do fabricante.
Por exemplo, a Microchip simplificou recentemente o seu portefólio de compiladores C com o pacote MPLAB® XC, que oferece um compilador para cada uma das suas arquiteturas de 8, 16 e 32 bits e suporta todos os microcontroladores PIC® e controladores de sinal digital (DSC) dsPIC®. Isto, combinado com a compatibilidade entre arquiteturas para conservar o investimento no desenvolvimento de código e a compatibilidade de pinos entre vários pacotes para simplificar o layout da placa de circuito impresso para substituição direta, torna-o ideal para este fim.
Portanto, enquanto os projetistas ainda aguardam a conclusão de um núcleo padrão com periféricos e firmware padronizados, podem pelo menos criar projetos à prova de futuro, avaliando a relação custo/benefício da migração para o catálogo de um único fabricante no início de cada projeto.
