Sugestões de design de aplicativos principais em tempo real
Importante
Esta é a documentação do Azure Sphere (Legado). O Azure Sphere (Legado) será desativado em 27 de setembro de 2027 e os usuários devem migrar para o Azure Sphere (Integrado) até esse momento. Use o seletor de versão localizado acima do sumário para exibir a documentação do Azure Sphere (Integrado).
As aplicações principais em tempo real (RT) são executadas em bare metal ou com um sistema operativo em tempo real (RTOS) nos núcleos em tempo real. Muitas das recomendações de design para aplicativos HL-core também se aplicam ao projeto de aplicativos RT-core. Este tópico discute outras sugestões de design a serem consideradas ao projetar aplicativos RT-core.
- Use um temporizador de vigilância: Recomendamos que você habilite e implemente o temporizador de vigilância MT3620 para que você possa detetar o deadlock e implementar a lógica de recuperação adequada. Para obter detalhes, consulte Usar um temporizador de vigilância em um RTApp. Este também pode ser um ponto importante onde o aplicativo RT pode sinalizar ao aplicativo HL-core (por exemplo, através da caixa de correio inter-core) que algo deu errado para que a ação apropriada possa ser tomada por qualquer aplicativo, como redefinir o dispositivo. Isso pode ser feito das seguintes maneiras:
- Reinicie o dispositivo chamando a
PowerManagement_ForceSystemReboot
função do aplicativo HL-core. Consulte Níveis de reinicialização em um dispositivo. - Ignorando as APIs HL-core executando uma redefinição de hardware através de um GPIO dedicado com os pinos de gerenciamento de energia do MT3620 (PMU_EN, EXT_PMU_EN ou SYSRST_N). Para obter mais informações sobre PMU_EN e EXT_PMU_EN, consulte Considerações sobre desligamento. A redefinição de hardware com SYSRST_N normalmente envolve a conceção dos esquemas do dispositivo com até três (um por cada núcleo) GPIOs de redefinição dedicados, conectados através de diodos e filtros RC ao pino SYSRST_N do dispositivo. A execução de uma redefinição de hardware permite uma ação independente de qualquer um dos aplicativos HL-core e RT-core se o design exigir recuperação determinística de qualquer aplicativo em execução em qualquer núcleo.
- Reinicie o dispositivo chamando a
Nota
Considere cuidadosamente o uso de GPIOs para redefinir o dispositivo a partir de um aplicativo RT-core, pois um efeito não intencional de programação ou design desse aplicativo (por exemplo, redefinir continuamente o dispositivo) pode impedir que o dispositivo receba atualizações do sistema operacional e do aplicativo.
- Implementar comunicações entre núcleos em projetos que combinam aplicativos HL-core e RT-core: mesmo que não seja explicitamente necessário, é sempre recomendável implementar uma troca de comunicação mínima entre os aplicativos HL-core e RT-core. Para obter mais informações, consulte Comunicar-se com um aplicativo capaz de tempo real. Além da troca de dados óbvia quando a comunicação entre núcleos é explicitamente projetada como parte da arquitetura geral do aplicativo, é útil e importante que as duas partes sejam sincronizadas em relação ao status uma da outra para que um melhor status geral do dispositivo possa ser gerenciado uma pela outra (consulte o exemplo de comunicação entre núcleos).
Para obter informações de referência adicionais sobre o desenvolvimento de aplicativos RT-core, incluindo drivers e exemplos para o uso de periféricos e recursos MT3620, consulte:
- Documentação do MediaTek MT3620
- Driver MediaTek MT3620 M4 & Código de exemplo de aplicativo em tempo real
- Drivers para núcleos em tempo real do Azure Sphere MT3620 (CM4) da Codethink Labs - Esses drivers foram desenvolvidos usando interfaces fáceis de usar (APIs) que imitam de perto as disponíveis para os aplicativos HL-core.
- Exemplos para núcleos em tempo real do Azure Sphere MT3620 (CM4) da Codethink Labs