Padrões de design para comunicação interprocessos em software embarcado (1/2)

A quem interessar: A depender do dispositivo em que escrevi parte dos textos, algumas palavras estão grafadas em português brasileiro (o meu nativo) ou português europeu (quando o auto corretor assim desejou).

1. Introdução

Nos dois últimos artigos demonstrei um pequeno kernel com escalonador de tarefas cíclico, porém preemptivo (round-robin) implementado em um ARM Cortex-M3. Além do escalonamento de tarefas também separavam-se os processos de usuário dos processos de supervisor, o que trouxe a necessidade da implementação de mecanismos de System Calls.

Durante os artigos, muitas vezes mencionei que o kernel ainda não estava preparado para a sincronização de tarefas e gerenciamento de recursos, ou de forma geral, não havia mecanismos para comunicação interprocessos.

Se quisermos generalizar o uso deste kernel – i.e., reutilizá-lo para uma solução em que as tasks não atuam isoladamente, um ou mais mecanismos de IPC é fundamental. Se por um lado os processos precisam cooperar para atingir determinados objetivos, por outro eles concorrem pelo uso limitado de recursos. [4]

2. IPCs: proteger e coordenar

O fenômeno que nos leva à necessidade de comunicação interprocessos é o da  Concorrência: os recursos finitos de um computador faz com que seja necessário coordenar as diversas actividades que concorrem simultaneamente ou paralelamente. Isto nos leva a ter que proteger uma atividade dos efeitos de outra e sincronizar atividades que são mutualmente dependentes. [4]

Figura 1. Multithreading e multiprocessing, conceitualmente [2]

Na publicação passada em que três tasks acessavam o mesmo hardware para imprimir na tela do PC, a coordenação para compartilhar o recurso foi feita com o sinal de TX_READY lido no registro do próprio dispositivo. Independente da quota de tempo que cada task tinha para ser executada, o kernel só liberava o processador após garantir que os dados da UART haviam sido transmitidos ao computador. Uma forma de IPC que não abstrai o hardware (UART) ou a aplicação (transmitir dados).

static void SysCallUART_PrintLn_(const char* args)
{
    __disable_irq(); // sessão crítica inicio
    uart_write_line(UART, args); // transmite dados        
    while (uart_get_status(UART) != UART_SR_TXRDY); //aguarda fim da transmissão
    __enable_irq(); // sessão crítica fim
    exitKernel_();
}

Lista 0. System Call lendo diretamente o sinal de TX_READY em uma critical region para coordenar as tarefas de acesso à UART

2.1. A Unidade Concorrente

O design do modelo de concorrência é uma parte crítica na arquitetura do sistema a ser desenvolvido. Vamos definir Process, Task e Thread.

Entendo um Process como algo estático (previamente definido) e encapsulado. Uma Task é um processo em execução. As Threads são tasks que acabam por ser dependentes entre si: uma consequência da topologia do sistema em que estes processos são executados [2, 3]. Se analisarmos a Figura 1, é intuitivo notar que a multithreading implica em complexidade de implementação em troca de economia/limitação de recursos.

Para efetivamente entender estes conceitos e modelar a arquitectura mais adequada ao gerenciamento da concorrência de tarefas em um dado sistema, a melhor definição que eu conheço é a de Unidade Concorrente [1]: 

«Unidade Concorrente é um conjunto de ações seqüenciais no mesmo segmento de execução. Também conhecido como task ou thread.» Em [2] uma Thread é definida como o «contexto de um processo em execução» – i.e., o contexto de uma Task – o que não se sobrepõe ou contradiz a definição dada por [1], e complementa a ideia de que uma thread é essencialmente dinâmica. Não à toa, a estrutura de dados em que salvamos o contexto de uma task é classicamente chamada de Thread Control Block.

Powell em [1] ainda observa: «muitos fazem uma distinção entre Task, Thread e Process. Entretanto, todos são o mesmo conceito em diferentes escopos.» Novamente analise a Figura 1. Se o “escopo”for a granularidade, diante do que consta na literatura apresentada, podemos dizer sem danos que: a thread é a menor unidade concorrente de um sistema quando em execução.

Figura 2. A, B, C e D são Unidades Concorrentes: a) A compartilhar um único core (pseudoconcorrentes)  b) Cada unidade tem seu próprio core c) Em execução, somente uma unidade concorrente estará activa em um dado instante de tempo (adaptado de [3])

2.2 A necessidade de sincronização

Antes de prosseguirmos, mais uma definição:

«Pontos de sincronização são aqueles em que as tasks compartilharão informações e/ou garantirão que determinadas pré-condições estejam satisfeitas antes  de prosseguirem.» [1]

A Figura 3 ilustra esta ideia. A barreira de sincronização só permite que o programa siga adiante quando todos os processos tiverem atingido aquele ponto – i.e., as condições para que todas as ações do sistema estejam corretamente sincronizados são verdadeiras.

Figura 3. a) Processos em execução b) Todos os processos exceto C estão prontos c) Assim que o processo C atinge o ponto de sincronização, o programa segue adiante. [3]

Eu prefiro o termo coordenação a sincronização, porque sincronia não é necessariamente um fenômeno desejável ou relacionado entre duas partes, portanto, gosto da ideia de pontos de coordenação. A literatura entretanto normalmente utiliza o termo sincronizado como sinônimo de coordenado.

A Figura 4 mostra unidades concorrentes, modeladas em três tasks. O que sabemos sobre elas? Se a analisarmos individualmente fica claro que na Task 1 a Acção A ocorre antes da B, que percorre um caminho condicional até chegar a E. O mesmo raciocínio  vale para as Tasks 2 e 3.

De que forma as acções individuais das Tasks 1, 2, e 3 relacionam-se entre si? Se a resposta (verdadeira) for “não se relacionam, ou não importa“, não há nenhum problema de concorrência a ser resolvido. E provavelmente o teu sistema é muito simples ou  muito bem desenhado.

Figura 4. Unidades concorrentes representadas como fluxogramas [1]

Entretanto, se em algum ponto é necessário garantir, por exemplo, que as Acções F, X e Zeta sejam executadas somente depois que as Ações E, Z e Gamma atingirem determinadas condições, precisamos de alguma forma reunir (join) cada um dos estados destas tasks em logicamente uma única thread, a partir de um ponto de sincronização. Após as condições necessárias terem sido atingidas no ponto de sincronização, as threads são novamente separadas (fork), e o programa segue.

Isto significa que sempre que houver condições entre dois ou mais processos para atingir determinado objectivo, precisamos criar mecanismos para que estes se comuniquem.

2.2.1. Mecanismos de Exclusão mútua

Recursos podem ser classificados como compartilháveis ou não compartilháveis. Isto depende da natureza física ou lógica de determinado recurso [4]. Por exemplo, a menor unidade de memória do sistema não pode ser lida e escrita ao mesmo tempo por dois processos distintos. Já uma estrutura de dados que guarda um resultado para ser consumido por um processo, precisa ser protegida para não ser sobrescrita antes de consumida (ou enquanto consumida, se pensarmos em pseudo-paralelismo), porque isto causará uma falha lógica no sistema. A exclusão mútua coordena o acesso de várias unidades concorrentes a um recurso.

2.2.2. Falha por deadlock

Quando processos concorrem por recursos, podemos chegar em uma situação em que nenhum deles consegue seguir adiante. Suponhamos dois processos A e B. O processo A está bloqueado, a espera de que um recurso seja liberado para seguir adiante. O processo B por sua vez só vai liberar este recurso quando determinada condição for satisfeita. Se esta condição depender do processo A, que já está bloqueado, temos um deadlock

3. Modelagem de Tasks em UML

Em UML há 3 maneiras de modelar concorrência [1]: objetos com o estereótipo «active» em diagramas estruturais, forks e joins em diagramas de seqüência, e regiões ortogonais em diagramas de máquinas de estado. Um objeto com o estereótipo «active» em geral é uma estrutura de outros objetos. O objeto ativo tem uma thread associada, que executa a ações sequenciais que correm em um contexto (contexto este que pode ou não estar representado ou inferido do diagrama). O símbolo de um objeto ativo pode tanto dar-se como um objeto comum com o estereótipo «active», ou com as bordas esquerda e direita destacadas. Na Figura 5, uma Task é modelada com cinco objetos ativos, um recurso (database) compartilhado e protegido por um semáforo e comentários com os metaparâmetros de cada thread associada (prioridade, período e deadline – parâmetros estes que dependem escalonador utilizado). Objetos «active» que não são um conjunto de outros objetos, como itsBuiltInTestThread  ou itsControlThread correm na sua própria thread. Por fim, em alguns casos utilizamos portas nas Tasks para conectarem-se diretamente com objetos – o que geralmente indica que passaremos estes valores por cópia, e em outros utilizamos links, o que normalmente indica que estes valores serão passados por referência.

4. Padrões para exclusão mútua

Quatro padrões de design serão aqui apresentados com os seus respectivos modelos UML: Critical Region, Guarded Call, Message Queue e Rendez-vous. Todos estes padrões estão descritos em [1].

4.1. Critical Region Pattern

Esta é a forma mais primitiva de coordenar tasks: desligar os mecanismos que poderiam interromper um trecho de execução, para evitar que a task ceda lugar a outra antes de as condições necessárias serem atendidas, ou para evitar a concorrência de acesso a um recurso.

Figura 6.Generalização do Padrão Critical Section em UML [1]

4.1.1. Rationale

Este padrão é utilizado em sistemas com escalonamento preemptivo, quando múltiplas unidades concorrentes podem acessar um mesmo recurso ou interromper uma tarefa em andamento. Ao desabilitarmos a troca de tarefas em determinado trecho de execução, garantimos a atomicidade da operação.

4.1.2 Elementos

CRSharedResource: O recurso a ser protegido é o  atributo value. Qualquer trecho de código que utilize os métodos setValue e getValue precisam ser colocados em regiões críticas.

TaskWithSharedResource: Este elemento simboliza o conjunto de tasks que acessam o recurso anteriormente mencionado (por isso a multiplicidade ‘*’ na associação de dependência). As tarefas não têm conhecimento de que recurso esta a ser utilizado; ele está encapsulado dentro do objeto CRSharedResource.

4.1.3. Implementação

Usualmente o kernel provê uma API com funções como osDisableTaskSwitch()/osEnableTaskSwitch(). Caso não, alguma diretiva em C/ASM pode ser utilizada para desabilitar as interrupções diretamente em hardware – no caso da API de abstração de hardware CMSIS para processadores ARM, esta diretiva seria __disable_irq()/__enable_irq(), e estamos na verdade a desabilitar toda e qualquer interrupção do sistema. Na publicação anterior, vários trechos do código do kernel estavam em critical regions porque necessitavam ser atômicos.

4.1.4. Exemplo

Na Figura 6, um hipotético sistema para mover o braço de um robô. Uma única Task move este braço (CRRobotArmManager). As entradas do usuário são as coordenadas (x, y, z) no espaço,  passadas por referência à Task.

É importante notar a estratégia para desacoplamento entre a Task e os objetos a ela associados: as regiões críticas são implementadas dentro dos métodos da Task, e não no método moveTo, por exemplo. A definição de regiões críticas dentro do método moveTo fatalmente acoplaria uma entidade que não é da natureza do kernel, o braço do robô - que deve poder ser movimentado por outros sistemas operacionais - à uma entidade totalmente acoplada ao kernel, a Task. Se não houver justificativa, o contrário é uma má escolha de design.
Figura 7. Exemplo de Task modelada que necessita do uso de sessão crítica [1]

Abaixo, o cabeçalho do programa, e a implementação de uma operação para facilitar a compreensão da linguagem UML [1]:

Lista 1. Cabeçalho da Task CRRobotArmManager [1]

#ifndef CRRobotArmManager_H
#define CRRobotArmManager_H
struct CRDisplay;
struct RobotArm;
struct UserInput;
typedef struct CRRobotArmManager CRRobotArmManager;
struct CRRobotArmManager 
{
  struct CRDisplay* itsCRDisplay;
  struct RobotArm* itsRobotArm;
  struct UserInput* itsUserInput;
};
/* Constructors and destructors:*/
void CRRobotArmManager_Init(CRRobotArmManager* const me);
void CRRobotArmManager_Cleanup(CRRobotArmManager* const me);
/* Operations */
void CRRobotArmManager_motorZero(CRRobotArmManager* const me);
void CRRobotArmManager_moveRobotArm(CRRobotArmManager* const me);
struct CRDisplay* CRRobotArmManager_getItsCRDisplay(const
CRRobotArmManager* const me);
void CRRobotArmManager_setItsCRDisplay(CRRobotArmManager* const
me, struct CRDisplay* p_CRDisplay);
struct RobotArm* CRRobotArmManager_getItsRobotArm(const
CRRobotArmManager* const me);
void CRRobotArmManager_setItsRobotArm(CRRobotArmManager* const me,
struct RobotArm* p_RobotArm);
struct UserInput* CRRobotArmManager_getItsUserInput(const
CRRobotArmManager* const me);
void CRRobotArmManager_setItsUserInput(CRRobotArmManager* const me,
struct UserInput* p_UserInput);
CRRobotArmManager * CRRobotArmManager_Create(void);
void CRRobotArmManager_Destroy(CRRobotArmManager* const me);
#endif

Lista 2. Método com o uso de critical regions [1]

void CRRobotArmManager_moveRobotArm(CRRobotArmManager* const me) 
{
 /* local stack variable declarations */
 int x, y, z, success = 1; 
 /*noncritical region code */
 /* note that the function below has its own critical region and so cannot be
 called inside of the critical region of this function
 */
 CRRobotArmManager_motorZero(me);
 x = UserInput_getX(me->itsUserInput);
 y = UserInput_getY(me->itsUserInput);
 z = UserInput_getX(me->itsUserInput);
 /* critical region begins */
 OS_disable_task_switching();
 /* critical region code */
 success = RobotArm_moveTo(me->itsRobotArm, x, y, z);
 /* critical region ends */
 OS_enable_task_switching();
 /* more noncritical region code */
 CRDisplay_printInt(me->itsCRDisplay, "Result is ", success);
}

4.2. Guarded Call Pattern

O padrão Guarded Call, serializa o acesso a um conjunto de serviços que potencialmente causam danos se chamados simultaneamente. Neste padrão, o acesso serializado é implementado através de um semáforo que previne que outras threads invoquem este serviço enquanto ele estiver em uso.

Figura 8. Generalização do Guarded Call Pattern modelado em UML [1]

4.2.1 Rationale

Múltiplas tarefas preemptivas acessam um recurso protegido invocando os métodos deste. O escalonador de tarefas por sua vez deve colocar a task que tentou acessar um recurso ocupado em uma fila de tasks bloqueadas, desbloqueando-a assim que o recurso for liberado.

4.2.2. Elementos

GuardedResource é um recurso compartilhado que emprega um Semaphore do tipo mutex para forçar a exclusão mútua entre múltiplas PreemptiveTasks (note que existe um único semáforo agregado a um único recurso, e portanto é um semáforo para um elemento, ou seja, um mutex1). Quando uma tarefa quer utilizar este recurso, as funções relevantes deste chamarão ao semáforo para colocá-lo em lock. Caso o recurso esteja livre, ele é locked e a tarefa pode utilizá-lo, e liberá-lo ao final. Caso o recurso já esteja em locked, este sinaliza ao escalonador para colocar a tarefa atual em estado blocked até que ele seja liberado. Outras tarefas que tentam acessar o recurso enquanto ele está bloqueado também tornar-se-ão blocked. Cabe ao escalonador do sistema fazer o manejo desta fila de tarefas bloqueadas a espera do recurso; ou seja, quais critérios serão utilizados para cada tarefa na fila – pode ser a prioridade, por exemplo.2

1 a implementação de semáforos/ mutexes é um assunto que será abordado na continuidade da construção do kernelzito já apresentado.

2 um problema comum nesta implementação é quando ocorre a chamada “inversão de prioridade”

4.2.3 Implementação

A parte mais complicada é a implementação dos semáforos. Normalmente o sistema operacional provê semáforos, acessados através de uma API do tipo:

  • Semaphore* osCreateSemaphore(): cria um semáforo e retorna um ponteiro para a instância.
  • void osDestroySemaphore(Semaphore*): destrói a instância semáforo para o qual aponta.
  • void osLockSemaphore(Semaphore*): trava o dispositivo associado ao semáforo se ele estiver livre. Caso não esteja, o contexto da tarefa que o requisitou é salvo, bem como a ID do semáforo do recurso requisitado, e a tarefa é colocada em blocked.
  • void osUnlockSemaphore(Semaphore*): destrava o dispositivo associado ao semáforo, e libera a tarefa que estava a sua espera.

4.2.4 Exemplo

A Figura 9 mostra a porção de um hipotético controlador de vôo. A classe KinematicData é compartilhada por diversos clientes. Para garantir a serialização de acesso um semáforo é instanciado neste recurso.

Figura 9. Padrão Guarded Pattern aplicado a um controlador de vôo

Isto evita que o método FlightDataDisplay::ShowFlightData()seja interrompido enquanto disponibiliza os dados de vôo, pelo método Navigator::updatePosition() por exemplo. Perceba que as Tasks não estão modeladas. A utilização do semáforo está acoplada ao escalonador – o seu estado quando a thread é disparada influencia no manejo da fila de threads no qual cada método em espera será executado. Abaixo snippets de parte da implementação para facilitar o entendimento.

Lista 3. Cabeçalho da classe KinematicData

#ifndef KinematicData_H
#define KinematicData_H
#include "GuardedCallExample.h"
#include "Attitude.h"
#include "OSSemaphore.h"
#include "Position.h"
typedef struct KinematicData KinematicData;
struct KinematicData 
{
 struct Attitude attitude;
 struct Position position;
 OSSemaphore* sema; /*## mutex semaphore */
};
/* Constructors and destructors:*/
void KinematicData_Init(KinematicData* const me);
void KinematicData_Cleanup(KinematicData* const me);
/* Operations */
Attitude KinematicData_getAttitude(KinematicData* const me);
struct Position KinematicData_getPosition(KinematicData* const me);
void KinematicData_setAttitude(KinematicData* const me, Attitude a);
void KinematicData_setPosition(KinematicData* const me, Position p);
KinematicData * KinematicData_Create(void);
void KinematicData_Destroy(KinematicData* const me);
#endif

Lista 4. Implementação da classe KinematicData

#include "KinematicData.h"
void KinematicData_Init(KinematicData* const me) 
{
  Attitude_Init(&(me->attitude));
  Position_Init(&(me->position));
  me->sema = OS_create_semaphore();
}
void KinematicData_Cleanup(KinematicData* const me) 
{
  OS_destroy_semaphore(me->sema);
}
struct Position KinematicData_getPosition(KinematicData* const me) 
{
  Position p;
  /* engage the lock */
  OS_lock_semaphore(me->sema);
  p = me->position;
  /* release the lock */
  OS_release_semaphore(me->sema);
  return p;
}
void KinematicData_setAttitude(KinematicData* const me, Attitude a) 
{
/* engage the lock */
  OS_lock_semaphore(me->sema);
  me->attitude = a;
  /* release the lock */
  OS_release_semaphore(me->sema);
}
void KinematicData_setPosition(KinematicData* const me, Position p) 
{
  /* engage the lock */
  OS_lock_semaphore(me->sema);
  me->position = p;
  /* release the lock */
  OS_release_semaphore(me->sema);
}
KinematicData * KinematicData_Create(void) 
{
  KinematicData* me = (KinematicData *)
  malloc(sizeof(KinematicData));
  if(me!=NULL) 
  {
   KinematicData_Init(me);
  }
  return me;
}
void KinematicData_Destroy(KinematicData* const me) 
{
  if(me!=NULL) 
  {
   KinematicData_Cleanup(me);
  }
  free(me);
}
Attitude KinematicData_getAttitude(KinematicData* const me) 
{
  Attitude a;
  /* engage the lock */
  OS_lock_semaphore(me->sema);
  a = me->attitude;
  /* release the lock */
  OS_release_semaphore(me->sema);
  return a;
}

Fim da primeira parte

Referências:
[1] Design Patterns for Embedded Systems in C (Douglass Powell, 2009)
[2] Embedded Systems: Real-Time Operating Systems for Arm Cortex-M MCUs (Jonathan Valvanno, 2012)
[3] Modern Operating Systems (Andrew Taneunbaum, Herbert Boss, 2014)
[4] Fundamentals of Operating Systems (A. M. Lister, 1984)

SOA para diminuição da hardware-dependência em C

aa480021.aj1soa01(en-us,msdn.10)
(MS Software Architecture Journal, 2004)

1. Impacto do software hardware-dependente (HdS)

É dito na literatura que o custo do software embarcado tem dominado o projeto de sistemas eletrônicos [1]. Sistemas embarcados, tradicionalmente limitados em memória e processamento, conseguem hoje rodar aplicações mais complexas fruto do avanço no projeto e fabricação de circuitos integrados. Ora, a introdução de hardware mais complexo permite a utilização de recursos de programação também mais complexos. De fato, mais de 90% das inovações na indústria automotiva da última década são decorrência direta do desenvolvimento em software embarcado. A especialização do dispositivo leva à especialização do software e ao conceito de software hardware-dependente:

  • é especialmente desenvolvido para um bloco de hardware específico: o software é inútil sem aquele hardware
  • software e hardware juntos implementam uma funcionalidade: isto é, o hardware é inútil sem aquele software

Muito provavelmente ao ler esta descrição pensaste em um sistema operacional para determinada plataforma e seus controladores (drivers). Abaixo segue um diagrama em camadas de um típico sistema embarcado. Conforme subimos as camadas, menos hardware-dependente será o nosso software, de forma que para escrevermos em linguagem interpretada, digamos, eu não preciso tomar conhecimento do microprocessador, e muito menos das tensões de operação dos meus dispositivos. O HAL (camada de abstração de hardware) é onde encontra-se o software mais hardware-dependente, i.e., mudanças no hardware invariavelmente implicarão em mudanças no software desta camada (Figura 1).

hal

Figura 1. Componentes e camadas de um típico sistema embarcado [ECKER]

2. Orientação a objetos para aumentar a coesão

O paradigma de orientação a objetos parte de um conceito muito intuitivo que é particionar um sistema em objetos classificados consoante à sua natureza. Não é necessário muito para perceber como isto aumenta o reuso e a portabilidade. A utilização do paradigma aumenta a coesão dos componentes de nossa arquitetura na medida da nossa habilidade em pensar de maneira orientada a objetos. Ao contrário do domínio de software aplicativo, em software embarcado sobretudo quando os requisitos são bastante específicos e o hardware limitado, a portabilidade e reuso esbarram na hardware-dependência. Se a OO é um bom paradigma para escrever software coeso, muitas vezes nestes domínio este recurso está indisponível. Podemos utilizar o C para escrever em um (meta-)padrão orientado a objetos, se soubermos fazer bom uso de ponteiros.

3. Exemplo de arquitetura orientada a serviços em C

Como exemplo vou descrever uma arquitetura para desacoplar a aplicação do hardware e que se beneficia dos conceitos de OO, entre eles o polimorfismo. O objetivo é escrever software para comunicação serial coeso o suficiente para quando o hardware mudar (ou for definido), somente o código mais fortemente hardware-dependente precise ser adaptado (ou escrito). O conceito de arquitetura orientada a serviços está presente em sistemas operativos baseados em microkernel (dois exemplos extremos: Windows NT e MicroC/OS). A arquitetura proposta está representada na Figura 2. Todo o software representado daqui em diante refere-se somente à camada de Serviços. A camada Board Support Package desacopla (ou diminui o acoplamento) entre o HAL e os Serviços; é a API do HAL para o programador dos Serviços.

layers

Figura 2. Layers em uma arquitetura orientada a serviços [do autor]

É uma boa ideia permitir que a aplicação utilize dois únicos métodos para transferir e receber um número de dados via serial, aplicados sob diferentes componentes de hardware: enviar(interface, x_bytes) e receber(interface, x_bytes). Estes são métodos que assumem uma forma ou outra a depender do objeto. Assim chegamos aos conceitos de interface (Classe abstrata), herança e polimorfismo. Abaixo o diagrama de classes da proposta. A assinatura completa dos métodos foi omitida.

class
Figura 3. Diagrama de classes da proposta

O padrão de design Proxy/Server permite que o hardware seja configurado de forma genérica abstraindo seus detalhes específicos. As mudanças no BSP são isoladas pela proxy ao programador da aplicação. O servidor por sua vez sustenta-se nos dados de configuração da proxy e na API do HAL para configurar e inicializar os serviços (this_proxy->this_service).

(Errata: na figura 3 os métodos de construção/inicialização e enviar/receber da classe SPI_proxy estão representados como se fossem iguais ao da UART, porém são métodos distintos.)

3.1. Implementação da Classe Abstrata

Uma interface pode ser percebida como um barramento de funções virtuais que aponta para um método ou outro em tempo de execução. Este apontamento segue por um caminho de endereços até chegar ao método para ser executado naquele contexto (etapa do fluxo do programa). Poderíamos também atribuir através de setters os métodos de cada objeto, i.e., ainda em tempo de compilação.

Começaremos por implementar a estrutura de dados que compreende a classe. Esta estrutura implementa 2 métodos que recebem e enviam frames de bytes. Uma classe Serial_Comm, portanto dá cria a um objeto que contém uma tabela de funções genéricas de enviar e receber. Os métodos públicos da interface são somente construtores e desconstrutores. Os métodos de enviar e receber ficam privados, haja vista que o objeto a ser utilizado pelo programador da aplicação é que vai defini-los. A estrutura com as funções virtuais Serial_Table é declarada mas não definida inicialmente. Mais adiante declaramos que a estrutura é somente leitura (definida em tempo de compilação) contém dois ponteiros para funções, e finalmente as definimos de forma limitada ao escopo. Isto é necessário para que ocorra o alinhamento do endereço desta tabela ao endereço da tabela do objeto que a utiliza em tempo de execução.

Abaixo o cabeçalho do Serial_Comm.

serial_comm_h-e1569800116804.png
Figura 4. Cabeçalho da classe Serial_Comm

No programa .c da interface, uma estrutura SerialTable é inicializada com endereço de funções dummy. A definição destes métodos com o assert(0) é uma forma de acusar um erro de programação em tempo de execução, se estas funções forem chamadas sem a devida sobrescrita.

serial_comm_c
Figura 5. Programa da Classe Virtual

3.2. Implementação do serviço UART

As classes de comunicação serial seguirão este padrão de design. O construtor inicialmente define uma estrutura SerialTable. Perceba que esta estrutura só pode ser definida uma vez, mas os elementos de vtbl podem assumir qualquer valor; i.e., se construímos um objeto que herda esta classe podemos estender os parâmetros e definir o endereço dos métodos, que ficarão ligados a uma e somente uma interface de funções virtuais.

Na estrutura de dados de uma classe herdeira a sua superclasse precisa ser declarada primeiramente. De outro modo não poderemos estender os atributos desta.

Na construção da proxy, uma tabela de funções definidas localmente é o endereço destino que contém a definição dos métodos virtuais da interface.

uart_proxy_hhh.png
Figura 6. Cabeçalho da classe Uart_proxy
uart_proxy_c-e1569704959728.png
uart_proxy_c_2
Figura 7. Programa uart_proxy.c

Um ponto chave é o downcast (linhas 51 e 57) feito nos métodos privados Uart_Send_ e Uart_Get_. Um ponteiro para Uart_proxy é inicializado com o endereço de uma interface Serial_Comm. O alinhamento da memória permite que acessemos os métodos desta proxy a partir desta interface. Além disso como servidor e proxy estão agregados, os metodos do BSP podem ser chamados na proxy. As funções que começam com “_” (_uart_init, _uart_get …) fazem parte deste BSP, cujo cabeçalho uart_driver_api.h está incluído no programa. No BSP podem-se utilizar as mesmas técnicas, para permitir por exemplo, que a definição do endereço do dispositivo a ser construído se dê também por uma interface abstrata que não muda com as características do dispositivo (mapeado em porta ou memória, plataforma alvo, etc.)

uart_server_hh
Figura 8. Cabeçalho da classe Uart_Server

Logicamente, a implementação do serviço para SPI segue o mesmo padrão de design.

4. Utilização dos serviços

Para a utilização dos serviços pela camada de aplicação, basta construir uma proxy com parâmetros de inicialização do dispositivo, neste exemplo UART ou SPI, e utilizar os métodos SendFrame e GetFrame que acessam a interface de cada objeto proxy.

main2.png
Figura 9. Um programa utilizando os Serviços e seus métodos polimórficos
run
Figura 10. Programa em execução

5. Conclusões

Conceitos do paradigma de programação orientado a objetos podem ser implementados, virtualmente, em qualquer linguagem se partirmos da ideia de que classes são estruturas de dados agregadas a um conjunto de funções que fornecem uma interface externa comum. Tanto estes métodos quanto estes dados podem ser privados ou não. No primeiro caso está o conceito de encapsulamento. A alocação destas estruturas com seus valores e funções, é a instância de um objeto. A instanciação de um objeto de uma classe dentro de outra classe implementa a herança. Uma interface que não implementa métodos pode ser utilizada para conectar-se à interface de uma outra classe, o que chamamos de funções virtuais. As funções virtuais podem então assumir uma forma ou outra a depender do fluxo do programa, o que caracteriza o polimorfismo.

Uma arquitetura orientada à serviço eleva a coesão dos componentes e a consequente reutilização e portabilidade, mitigando os problemas gerados pela natural hardware-dependência do software para sistemas embarcados. A orientação a objetos por sua vez é o paradigma natural para a construção de sistemas orientado a serviços. Este artigo demonstrou uma forma de aplicar estes conceitos em sistemas embarcados quando linguagens OO (comumente neste domínio C++ ou Ada) não estão disponíveis.


O texto desta postagem bem como as figuras não referenciadas são do autor.
As seguintes referências foram consultadas:
[1] Hardware-Dependent Software: Principles and Practices. Ecker, Muller, Dommer. Springer, 2009.
[2] Design Patterns for Embedded Systems in C. Bruce Douglass. Elsevier, 2001.
[3] Object-Oriented Programming in C: Application Note. Quantum Leaps. April, 2019.

Escalonamento cooperativo em software embarcado (2/2)

sch

Escalonador cooperativo para soft real-time

Os sistemas com requisitos de tempo-real são classificados em soft, firm e hard, apesar de estes critérios não serem bem estabelecidos. Em sistemas ‘hard’, os requisitos de tempo precisam ser estritamente atendidos sob pena da falha total. No soft/firm, o não cumprimento das deadlines é tolerado em alguma medida, ocasionando degradação da qualidade do sistema sem levar à falha total.

Na última publicação descrevi algumas arquiteturas de escalonadores (schedulers) que na sua melhor forma executava toda tarefa agendada no mesmo intervalo de tempo, e também poderia reagendar ou descartar a tarefa.

Vou estender esta última arquitetura um pouco mais, agora ao invés de informar ao escalonador somente o endereço da função, também vou informar uma frequência de execução que deve ser cumprida.

Como agora precisamos contar os ticks do relógio para atender aos requisitos temporais, precisaremos de uma referência de tempo. Para isso podemos usar um temporizador que gere uma interrupção a cada Q segundos. O serviço que atende esta interrupção informa ao escalonador que houve um tick de relógio. O menor intervalo de tempo entre um tick e outro é por vezes chamado de quantum e é uma escolha importante de projeto.

O escalonador será composto basicamente por um buffer circular que aponta para os processos, e um disparador que fica responsável por arbitrar qual processo está pronto para ser disparado.

A figura abaixo ilustra a arquitetura proposta:

sch

Cada estrutura de processo é declarada com um período (em ticks do sistema). Quando o processo é adicionado ao buffer circular, um inteiro é inicializado, em tempo de execução, com o período informado na chamada de sistema. A cada interrupção gerada pelo tick do relógio, este número é decrementado e pode ser visto como uma deadline. A cada ciclo de máquina, o árbitro varre pelo processo com o menor prazo de execução, para dispará-lo em seguida (colocado na posição inicial do buffer). A função evocada retorna REPEAT ou ONESHOT, caso queira ou não ser reagendada, ou FAIL como código de erro. O código abaixo mostra o cabeçalho do programa (desisti de escrever os códigos no texto da publicação, o editor do WordPress é muito ruim!):

header

Na estrutura process a variável deadline é com sinal para poder registrar o atraso, quando ocorrer. Além disso, se a tarefa for reagendada, o contador do novo processo apontado no buffer vai iniciar subtraindo este atraso para ajustar o atraso total do sistema.

buffer

Quando o disparador varre o buffer para selecionar o processo com a menor deadline, ele também organiza a fila em ordem decrescente de deadlines. Se o processo anterior retornou FAIL, o escalonador analisa se o deadline do próximo processo a ser executado é menor que o período do atual. Caso verdadeiro ele dispara o processo mais uma vez. Por isso foi necessário organizar o buffer sempre em ordem crescente de atraso, para garantir que o processo atual seja comparado com o mais crítico da fila.

Quando a menor deadline da fila for maior que 0,  será necessário esperar até o contador chegar a zero, e uma boa prática é utilizar este tempo para colocar o processador em um modo de baixo consumo (verificando no manual do processador se neste modo ele ainda é sensível à interrupção que gera o tick!).

escalonador

escalonador2

A configuração do temporizador que realiza a interrupção para gerar o tick do relógio depende da arquitetura. O código abaixo escrevi para um ATMega328p rodando a 16MHz. Ele está gerando o tick a cada 4ms.

isr

Abaixo as rotinas para habilitar e sair do modo IDLE:

powersch-2.jpg

A função schInit() inicializa o scheduler, zerando os índices do buffer e inicializando o temporizador para geração do tick do sistema.

O programa principal de um sistema utilizando este scheduler teria a seguinte cara:

mainsch

Aviso: o código acima tem propósitos didáticos e não é um artefato validado. Não há nenhuma garantia de funcionamento livre de erros, e o autor não se responsabiliza pelo uso.

O texto desta postagem é original. Os seguintes livros foram consultados para sua elaboração:
[1] Programação de sistemas embarcados, Rodrigo Almeida e outros.
[2] Real-Time Systems Development, Rob Williams 
[3] Patterns for Time-Triggered Embedded Systems,  Michael J. Pont