Abordagens para projeto low power (2/3)

17zhswf3uasrj.jpg

(Um PDA da Nokia com acesso à internet, 1995. Fonte: gizmodo.com)

5 Abordagens low power no nível arquitetural

Penso que desenhar a arquitetura de um projeto é, para todos os efeitos, definir como cada módulo do sistema se comunica com os outros módulos para trabalharem em conjunto, e através de análises, seja pela experiência do projetista ou por resultados de modelos, elaborar a melhor forma de construí-los. Abaixo seguem algumas abordagens utilizadas na indústria para elaborar arquiteturas eficientes em consumo.

5.1 Redução dinâmica da tensão de alimentação e frequência (DVFS)

Apesar dos avanços, o problema entre o poder computacional disponível e o tempo de bateria ainda são os principais desafios da indústria. O seu smartphone aguenta 1 único de dia de uso pesado com navegação, músicas, redes sociais e sinal intermitente? O meu não.

Mas como disse, uso pesado. Quer dizer, o seu smartphone sabe quando mais e quando menos energia serão necessárias para aplicação, reduzindo ou aumentado a tensão e/ou a frequência fornecidas dinamicamente para os periféricos do microprocessador.

Os próprios microprocessadores em geral são especificados de forma que a frequência de operação máxima depende da tensão fornecida. Assim quando a performance não estiver crítica a tensão (e a frequência) podem ser reduzidas. Infelizmente isto não vale para sistemas de tempo real cujo principal requisito é atender aos deadline. Existem soluções que incorporam DVFS entre o escalonador e o disparador do RTOS.

5.2 Múltiplas tensões

Projetar um chip utilizando uma única tensão de alimentação é comum e também tem a penalidade de que os piores caminhos de tempo a serem cumpridos terão a mesma força de drive dos demais. Ou seja, haverá slack times bastante altos para poder compensar os caminhos críticos. Claro que um bom projeto e uma boa ferramenta tentam encontrar um compromisso.

O ponto chave é que se todos os caminhos forem críticos, o consumo global vai ser o menor possível. A forma mais simples é: operar todos os caminhos que não são críticos em tensão mais baixa, e os críticos em tensão mais alta. A penalidade se dará principalmente em área pela adição de layers para comunicar blocos em diferentes tensões.

Formas mais eficientes adicionam inteligência nas ferramentas de projeto para escolher as tensões de cada caminhos. Falando de forma muito simplificada, um algoritmo calcula o slack de uma célula, e decide se ela pode ou não ser substituída por uma célula low voltage. Caso os demais caminhos continuem positivos esta célula é então substituída. Se não, será preciso sacrificar o consumo em detrimento da performance naquela célula.

Ainda, alguns autores sugerem que o caminho crítico de um circuito não é o caminho mais longo, mas sim o caminho mais longo e mais demandado na operação – uma variável a mais. Esta técnica demonstrou alguns ganhos em relação a anterior, e é chamada de PVCS (path-oriented clustered voltage scaling).

É preciso dizer que os layers adicionados para comunicar módulos em diferentes tensões também consumirão energia tanto estática quanto dinâmica. Existem pesquisas com as mais diversas soluções para a utilização de múltiplas tensões, inclusive com técnicas livres de conversores de nível de tensão.

5.3 Clock-gating

Em primeiro lugar é importante dizer que a árvore de clock consome aproximadamente 50% da energia em um circuito integrado digital. Depois, cada vez que um gate é chaveado, energia dinâmica será consumida. Se o dado a ser disponibilizado após o chaveamento é o mesmo que lá está, por que então consumir esta energia? Condições para habilitar ou não o clock são as técnicas chamadas de clock gating.

Está apresentada aqui em nível arquitetural pois, assim como as outras técnicas neste nível, é implementada no projeto através das diretivas de síntese que o projetista lança e das células disponíveis no PDK (Process Design Kit). Entretanto o código em que o hardware é descrito também tem forte influência no que a ferramenta vai conseguir fazer, pois é a partir desta descrição que as melhores ‘condições’ para habilitar ou não o clock serão inferidas.

A forma mais comum de clock-gating, simplesmente compara se a entrada D de um banco de registradores é igual ou não à saída Q.

clockcombinacional

Figura 1: Clock gating combinacional (figura retirada de Mohit Arora)

Na figura acima, uma condição de enable permite ou não que aquele registrador seja ‘clockado’, e o dado segue adiante na pipeline. (perceba que o segundo registrador não tem uma lógica de clock gating representada, e muitos menos relacionada com a primeira)Estima-se que 5-10% de energia dinâmica é salva com essa técnica se implementada combinacionalmente.

Pensando num pipeline onde lógicas são encadeadas entre um banco de registro e outros podemos também reduzir o chaveamento redundante na porção do circuito que está conectada à saída banco de registradores que estão sob clock gating, se toda a cadeia subsequente da pipeline for chaveada levando em conta as condições de enable da anterior. Na literatura costumam chamar esta técnica de “clock-gating avançado”.

clocksequencial

Figura 2: Clock gating sequencial (de Morit Ahora)

5.4 Power gating

Desabilitar completamente um módulo quando ele não está em uso, é consideravelmente importante nas atuais tecnologias onde a componente de consumo estático é dominante. Os módulos são habilitados ou desabilitados conforme a necessidade da aplicação. As chaves utilizadas para habilitar ou desabilitar passagem de corrente para o módulo são comumente chamadas de sleep transistors. As chaves conectadas entre Vdd e o módulo são os chamados ‘headers’ e entre o módulo de Vss são os ‘footers’. A inserção destes sleep transistors insere agora dois grandes domínios de tensão no sistema: um permanente, conectado à fonte de alimentação, e um virtual que é o visto pelo módulo de fato. O maior desafio é projetar uma chave que permita que o domínio de tensão real e virtual sejam muito similares em todas as suas características.

header-footer-swithces

Figura 3: Diagrama de blocos de dois circuitos utilizando sleep transitors, (a) header e (b) footer. (de Mohit Arora)

Não é difícil imaginar que o tamanho do sleep transistor seja bastante considerável (no dedão: ~3x a capacitância a ser driveada). Devido ao seu tamanho, ligar ou desligar um módulo através do seu chaveamento leva um tempo. Assim, não parece uma boa política adicionar estas chaves a módulos que ficarão pouco tempo em idle na operação típica do sistema. Assim, ou fazemos um sistema de power gating de baixa granularidade ou alta granularidade.

No modo fine-grain (alta granularidade) cada módulo tem um sleep transistors que são construídos como parte do PDK e adicionados durante a síntese, o que traz imensas vantagens na facilidade de projeto. A economia de corrente de leakage pode chegar a 10X.

No sistema de baixa granularidade, menos sleep-transitors são disponibilizados na forma de ‘grid’ que ligam ou desligam os domínios de módulos conforme a aplicação. Isto implica em menor overhead de área (e por consequência, menor variação de processo). Nesta abordagem os sleep-transistors são de fato parte das linhas de alimentação do circuito, não células adicionadas na síntese lógica, e portanto mais próximos do projetista de back-end.

Por outro lado, nesta abordagem de grid, com menos sleep-transistors chaveando mais circuitos, teremos mais domínios de power, com maiores variações de IR entre eles, maiores correntes de pico de power-up, que podem, entre outros problemas, ocasionar transições indesejadas em módulos vizinhos, o que vai exigir contra-medidas no back-end. Além de é claro, fritar um circuito cujas linhas foram subdimensionadas.

coarsepower

Figura 4: Representação de um esquema de power-gating de baixa granularidade com sleep transistor do tipo footer (de Mohit Arora)

Na prática não existe uma linha bem definida entre fine-grain e power-grain, e um misto de ambos é utilizado em um projeto real.

5.5 Sub-threshold/near-threshold design

A diminuição da tensão de alimentação (mantendo uma tensão de threshold fixa) resulta na diminuição quadrática do consumo dinâmico, às custas de performance, o que a depender da área de aplicação (sensores biomédicos, para dar um único exemplo) não é um problema.

Indo um pouco além, podemos pensar em utilizar o que seria a corrente de leakage desperdiçada para de fato implementar a lógica do sistema, o que é atingido quando se reduz a tensão de alimentação para um valor menor ou muito próximo de Vth. A corrente de sub-threshold é exponencialmente dependente da tensão no gate. A literatura demonstra algumas reduções de até 20X quando comparados com circuitos operando com (super)-Vth.

O grande problema? A pequeníssima diferença na corrente de um transistor ligado e um desligado, faz com que as variações de processo sejam muito impactantes no circuito construído. As contra medidas partem da arquitetura do sistema e chegam ao nível de transistor.

* * *

A próxima e última publicação vai falar das técnicas em nivel RTL.

Se não concorda, não entendeu, achou muito bom ou muito ruim, comentários são muito bem vindos.

O texto desta publicação é original. As seguintes fontes foram consultadas: The Art of Hardware Architecture, Mohit Ahora Ultra-Low Power Integrated Circuit Design, Niaxiong Nick Tan et al.

Abordagens para projeto low-power (1/3)

iphone-battery

1 Eficiência

Na última publicação sugeri que a Compaq teria percebido a portabilidade como requisito mais que desejável para a computação pessoal. Apesar de os primeiros computadores da companhia terem ~12 kg (!) e serem considerados “portáteis” simplesmente por serem apresentados em uma maleta com alças, ainda precisavam de uma tomada de corrente para funcionar.

Um pouco mais tarde, com a popularização das tecnologias multimídias e dos PDAs (personal digital assistants, ou “palmtops”), a computação portátil começa a precisar de cada vez mais performance, e aí a otimização de consumo passou a ser critério determinante em um projeto. O objetivo é ser eficiente: realizando tanto ou mais trabalho com menos energia, as baterias duram mais. Não sei dizer exatamente quando e nem quem começou as pesquisas no assunto, mas um dos trabalhos acadêmicos mais relevantes na área é datado de 1992 (Low-power CMOS Digital Design, CHANDRAKASAN et. al).

Nesta publicação quero falar um pouco sobre técnicas de baixo consumo e a oportunidade de aplicá-las nas diferentes fases e camadas de abstração de um projeto. Aqui estou assumindo que os circuitos são essencialmente digitais. O projeto low-power para circuitos (integrados) analógicos tem técnicas distintas que podem ser assunto para outra postagem.

2 Consumo estático e dinâmico

Dois componentes gerais de consumo são o consumo estático e o consumo dinâmico. Este refere-se ao consumo ocasionado pelas transições de uma porta lógica e é proporcional à corrente circulante, à frequência de transições e às capacitâncias que são carregadas e descarregadas nessas transições. O consumo estático se refere às correntes que circulam entre Vdd e Gnd mesmo quando os módulos de um dispositivo estão desligados. Com os comprimentos de canais dos transistores cada vez menores, as correntes de leakage passaram a ser uma significativa parcela do consumo total, quando não a componente dominante. Quanto menor o canal de um transistor, menor será a sua tensão de threshold e menor será a diferença entre a corrente de operação e a corrente de leakage. Na verdade, a corrente de leakage aumenta exponencialmente com a diminuição da tensão de threshold.

De maneira geral, para um gate lógico:

Potência total = Potência dinâmica + Potência estática [W]

Potência dinamica = Vdd^2 * Freq * Cl* p [W]

onde p é a probabilidade de uma transição lógica ocorrer.

3 Níveis de abstração de um projeto digital

Fazendo uma analogia com carros, uma Lamborghini Diablo 1991 é um sistema igual a um Renault Clio 2010. Ambos são automóveis, do tipo “carro”, compostos por carroceria, 4 rodas, motor, diferencial, volante, transmissão e etc. Porém arquiteturalmente são projetos radicalmente distintos.

Um sistema é concebido para prover uma solução. No caso dos automóveis o problema a ser resolvido é como deslocar algo de um lugar a outro. Se eu preciso levar uma pessoa de um ponto ao outro, eu posso escolher construir um carro, uma moto ou um patinete (que não é um automóvel!). Enfim, as escolhas em nível de sistema, são aquelas que irão definir o que é o meu projeto e quais são suas características. Estas escolhas terão como ponto de partida os requisitos do produto. Se o propósito é deslocar até 5 pessoas de um ponto ao outro e com economia de energia, o Clio faz muito mais sentido que a Lamborghini, se o requisito for um carro.

De maneira geral, podemos representar a estrutura de um projeto, nos seguintes níveis de abstração:

Nível de Sistema: refere-se a definição do conjunto de módulos de um projeto e suas conexões (microprocessador+RAM+NVM+I/O, etc.)

Nivel Arquitetural: refere-se a forma como são construído os módulos definidos no sistema e como eles interagem: a definição de interfaces, dos protocolos de controle, comunicação, etc. (ex.: microprocessador RISC-V 32-bit, 8KB de RAM, 64KB de memória NAND Flash, transreceptor compatível com NFC, camada MAC comunica-se com a PHY através de uma interface AMBA-PB, etc.)

Nível de Registradores (Register Transfer Level): representação do circuito digital como um conjunto de registros, ULAs, Muxes, contadores, etc. Pode ser chamado de “microarquitetura”.

Nível lógico: mapeamento do RTL como um conjunto de portas lógicas, latches e flip-flops.

Nível de Circuito: a representação elétrica do sistema, através de um esquemático de transistores e outros componentes elétricos.

4 Abordagens low-power no nível de sistema

Quando pensamos em sistemas digitais o consumo geralmente estará relacionado à área e performance. Uma maior performance exige uma operação em alta freqüência e com suficiente força de drive. A área relaciona-secom o tamanho dos dispositivos que por sua vez dita o tamanho das capacitâncias a serem carregadas/descarregadas.

4.1 Faça um SoC

O advento dos SoCs, sistemas inteiramente construídos em um único circuito integrado, possibilitou drástico aumento na eficiência energética. Se falamos de um sistema que está construído na forma de chips e componentes discretos conectados em uma placa, a transformação em SoC pode ser vista como uma técnica para redução de consumo. E das mais eficientes.

4.2 Capriche no co-projeto de hardware+software

O que implementar em hardware e o que implementar em software? Tipicamente as implementações em hardware consumirão menos energia que as suas contrapartes em software.

Podemos simplesmente identificar aquelas rotinas que consomem mais processamento e escolher implementá-las em hardware.

Entretanto em um fluxo de projeto que realmente aproveite a oportunidade de se poder implementar qualquer parte de um sistema em hardware ou software, uma abordagem baseada em modelos deve ser considerada. Existem linguagens como o SystemC ou SystemVerilog que permite a confecção de modelos em alto nível de abstração. Outras ferramentas como SystemVue, Matlab/Simulink são dedicadas a modelar sistemas. Depois de o sistema modelado, as simulações são utilizadas para fazer estimativas da performance e consumo das funcionalidades, e pode-se fazer escolhas direcionadas sobre o que será implementado em hardware ou software. As funcionalidades que consomem mais recursos beneficiarão todo o sistema se forem construídas com arquitetura visando baixo consumo. Ou seja, as análises no nível do sistema guiam nossas escolhas arquiteturais mais adiante.

A validação da arquitetura pode ser feita através de uma abordagem TLM (Transaction-Level Modeling).

lowpower_hwswcodesignflow

4.3 Software eficiente

Idealmente o seu compilador deve conseguir produzir um código objeto otimizado, mas ele não tem nenhuma outra informação a não ser o código que você entrega a ele, puro e duro. Compiladores “system aware” só amanhã.

Quantas instruções tem a task mais executada do sistema? Quantos ciclos de clock cada instrução consome? Se um sistema rodando a 5 MHz acorda o processador a cada segundo para executar 500 instruções, admitindo 1 instrução/ciclo, ao diminuírmos somente uma instrução desta task, estaremos dando uma sobrevida a bateria de ~ 6,5 segundos por ano, num sistema 24/7. Escalone isso para mais MHz de operação e mais instruções economizadas, e veja por si só.

Assim, o nosso código, como regra geral deve evitar primitivas complexas e ser otimizado em desempenho. Considero que conhecer o processador e o compilador, e a utilização de boas práticas de engenharia de software como a refatoração, são as melhores forma de escrever códigos eficientes. Abaixo alguns exemplos:

Código original

Código otimizado

if ((i % 10) == 0 )
{
   // faça algo
}
i++;
If (counter == 10)
{
   // faça algo
   counter=0;
}
else
{ 
   i ++
}
counter++;

A operação ‘módulo’ usualmente toma mais ciclos de instrução. É mais econômico reproduzir o mesmo efeito com operações mais baratas.

Código original

Código otimizado

for(i=0;i<10;i++)
{
   // faça algo 1
}
for(i=0;i<10;i++)
{
   // faça algo 2
}
for(i=0;i<10;i++)
{
   // faça algo 1
   // faça algo 2
}

Uma chamada de loop com inicialização, incremento e comparação é economizada.

Código original

Código otimizado

unsigned int x;
 for (x = 0; x < 100; x++)
 {
     A[x] = B[x];
 }
unsigned int x; 
 for (x = 0; x < 100; x += 5 )
 {
     A[x]   = B[x];
     A[x+1] = B[x+1];
     A[x+2] = B[x+2];
     A[x+3] = B[x+3];
     A[x+4] = B[x+4];
     
 }

No código acima, 100 elementos do vetor A serão copiados para as primeiras 100 posições do vetor B. A segunda implementação faz com que o loop precise ser rodado 20 vezes, ao invés de 100.

(Link externo: este AN da Atmel indica no capítulo 9 algumas formas de otimizar tamanho e tempo de execução para AVRs 8-bit)


 

Na parte 2 vou falar sobre técnicas aplicadas no nível arquitetural (power-gating, clock gating, multi Vdd, multi Vth, DVFS…).

Até mais!

O texto desta publicação é original. As seguintes fontes foram consultadas:
The Art of Hardware Architecture, Mohit Ahora
Ultra-Low Power Integrated Circuit Design, Niaxiong Nick Tan et al.

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

Escalonamento cooperativo de tarefas em software embarcado (1/2)

sch

Arquiteturas para escalonamento cooperativo de tarefas

Na publicação anterior escrevi sobre o uso do chamado super-loop e suas limitações quando falamos em atender requisitos de tempo em uma planta. Além disso, também mostrei que podemos utilizar interrupções disparadas por temporizadores para garantir que tarefas sejam executados em intervalos definidos. Neste caso, para cada tarefa periódica precisamos de um temporizador. Em sistemas um pouco mais complexos, ambas as arquiteturas são muito suscetíveis a erros e de difícil manutenção e reuso/extensão.

Um escalonador é um bloco de código que permite ao programador inserir tarefas que serão chamadas em intervalos regulares sem que seja necessário um serviço de interrupção (ISR) dedicado a cada uma delas (podemos pensá-lo como um ISR compartilhado). Quando comparado ao super-loop, o escalonador permite que o programador não se preocupe em manejar os delays entre uma tarefa e outra para garantir a periodicidade desejada. Quando comparado a utilização com temporizadores, o uso de um escalonador é menos custoso pois não necessitamos de um temporizador para cada tarefa periódica.

Existem dois tipos gerais de escalonadores os cooperativos e os preemptivos. Os escalonadores cooperativos simplesmente executam uma tarefa após a outra, com ou sem deadline no tempo, e são implementados em sistemas monotarefas. Os escalonadores preemptivos indexam prioridades a cada uma das tarefas, e caso um evento que chame uma tarefa de maior prioridade ocorra durante a execução de uma menos prioritária, esta é pausada e retomada após a conclusão daquela. Por isso estes escalanadores são ditos multitarefas. (A tarefa atual não precisa terminar para que outra seja executada. Guardadas as devidas proporções e aplicabilidade, o MS Windows é multitarefas pois o usuário do PC pode alternar entre uma tarefa e outra, e o sistema operacional chaveia o contexto do microprocessador – alterna entre um processo e outro – dando a impressão de que todas as tarefas estão sendo executadas ao mesmo tempo. O antigo MS-DOS é monotarefa. )

Vou explorar aqui algumas implementações para escalonadores cooperativos.

Escalonamento cooperativo utilizando máquinas de estados

Independente da arquitetura do escalonador, se ele for cooperativo suas operações podem ser descritas da seguinte forma:

  • as tarefas são agendadas para ocorrer em um determinado período de tempo

  • quando o agendamento ocorre, a tarefa é armazenada em uma lista de espera

  • quando a tarefa atual termina, a próxima é executada (se houver)

  • após a completude das tarefas, o controle do sistema volta ao escalonador

Se a solução a ser implementada não tiver padrões rígidos de resposta temporal, a utilização de uma máquina de estados garante a facilidade no reuso e manutenção do código.

Supomos um programa que utilize um display, um teclado e uma porta serial. A porta serial responde aos comandos vindos pelo teclado ou pela serial. O display é atualizado periodicamente. A máquina de estados pode ser modelada da seguinte forma (figura retirada de [1]):

fsm001

Uma implementação em C para esta FSM poderia ser:

#include <serial.h>
#include <keypad.h>
#include <display.h>
#define LE_TECLADO 0
#define LE_SERIAL 1
#define ESCREVE_SERIAL 2
// programa principal
void main(void)
{
   kpInit();
   displayInit();
   serialInit();
while (1)
{
 // atualiza display
    displayUpdate();
    switch(state)
    case LE_TECLADO:
    if (kpRead() != 0) // chegou comando
    {
    /* mais processamento */
      state = ESCREVE_SERIAL;
    }
    else
    {
      state = LE_TECLADO;
    }
    break;
    case LE_SERIAL:
    if (serialRead() != 0) // chegou comando
    {
      state = ESCREVE_SERIAL;
    }
    else
    {
      state = LE_SERIAL;
    }
   break;
   case ESCREVE_SERIAL:
   /* processa comando e responde */
   break; 
   default: 
     state=LE_TECLADO;
     break;
}

Perceba que como a função de atualizar o display precisa ser executada intermitentemente entre um estado e outro, ela pode ser acomodada antes do switch-case.

Neste caso, as funções serão executadas até a completude antes de passar a vez. Uma característica desejável de um sistema embarcado é o determinismo. Podemos então configurar um período de tempo fixo para todas as tarefas ocorrerem. Este período obviamente precisa ser maior que o pior caso de tempo de execução.

// programa principal
void main(void)
{
  kpInit();
  displayInit();
  serialInit();
  while (1)
  {
    // atualiza display
     displayUpdate();
     timerInit(300); // liga contador que vira a cada 300 ms 
     switch(state) 
     { 
      case LE_TECLADO: 
        if (kpRead() != 0) // chegou comando 
        { 
        /* algum processamento */ 
          state = ESCREVE_SERIAL; 
        } 
        else 
        { 
          state = LE_TECLADO; 
        } 
        break; 
     case LE_SERIAL: 
        if (serialRead() != 0) // chegou comando 
        { 
          state = ESCREVE_SERIAL; 
        } 
        else 
        { 
          state = LE_SERIAL;
        }
        break; 
     case ESCREVE_SERIAL: 
       /* processa comando e responde */ 
       break; 
     default: 
       state=LE_TECLADO; 
       break; 
  } 
  timerWait(); // espera o contador virar 
}

A desvantagem aqui é o tempo ocioso que o processador espera “somente” para padronizar as tarefas. Porém perceba que passamos de uma arquitetura cujo tempo de execução era difícil de prever para uma com tempo bem definido, e isto é um ganho enorme. O tempo livre aliás poderia ser utilizado para colocar o sistema em baixo consumo de energia, o acordando novamente com a interrupção do temporizador. Esta arquitetura é uma boa escolha para hardwares limitados em memória.

Escalonamento cooperativo com ponteiros para funções

Collins Walls no seu blog descreve o que diz ser um RTOS de uma linha, que basicamente utiliza um ponteiro para funções.

#define NTASKS 3
// pool de funções
void (*tasklist[NTASKS])() = {alpha, beta, gamma};
int taskcount;
void main()
{
  while (1)
  {
  // dispatcher
  for (taskcount=0; taskcount<NTASKS; taskcount++)
  {
   (*tasklist[taskcount])();
  } 
}

Apesar de simples, esta estrutura nos fornece muitos conceitos úteis. O uso de ponteiros para função já nos permite imaginar que as informações das tarefas a serem executada estarão armazenadas em algum espaço da memória, e o escalonador fica responsável por buscá-las e executá-las, sob alguma lógica de controle. Neste caso, é simplesmente a ordem do endereço das funções na matriz de ponteiros tasklist. Mas poderíamos adicionar mais critérios de escolha. Talvez um deadline temporal, informação de prioridade ou delay inicial.

Poderíamos garantir que todas as tarefas fossem executadas em um mesmo intervalo de tempo, com a mesma técnica aplicada na máquina de estados.

Poderíamos também criar uma pequena API:

// para adicionar tarefas

#define N_TASK 4 // numero de tarefas
typedef void(* ptrFunc)();
int pos;
void() addTask(ptrFunc newFunc)
{
  if (pos < N_TASK-1) // verifica se ha espaço no vetor
  {
    tasklist[pos] = newFunc;
  }
    pos++; //incremente posicao
}
// para disparar o escalonador
void sch_loop(void)
{
  int i;
  while(1)
  {
    for(i=0;i<N_TASK-1;i++)
    { 
      (*tasklist[i])();
    }
  }
}
// inicializa sch
void sch_init()
{
 pos=0;
}

E aí nosso código principal seria:

void main();
{
 schInit();
 addTask(alpha);
 addTask(beta);
 addTask(gama);
 schLoop();
}

Esta codificação parece ser desnecessária para executar três funções em fila, sem nenhum critério. O super-loop resolveria. Concordo, porém é o esqueleto de uma arquitetura que pode ser estendida para criar um scheduler mais robusto.

Executando processos uma única vez ou indefinidamente

No código apresentado as tarefas serão executadas na mesma ordem, ad infinitum. É interessante informarmos ao escalonador se a tarefa que acaba de retornar quer ou não ser executada ciclicamente. Para isso podemos criar códigos de retorno para as funções:

#define ONESHOT 0;
#define FAIL 1;
#define REPEAT 2;

Para executar processos uma única vez, precisamos poder removê-los do vetor de processos dinamicamente. Para isso, vamos transformar o vetor tasklist num buffer circular. As funções são inseridas no início do buffer e executadas em ordem. Caso uma função retorne REPEAT ela é inserida ao final do buffer. As tarefas são (re)agendadas dinamicamente.

Assim, precisamos alterar a função addTask para controlar o buffer tasklist de forma circular:

char addTask(ptrFunc newFunc)
{
 if ((last+1)%(N_TASK+1) != first)
 {
   tasklist[last] = newFunc;
   last=(last+1)%(N_TASK+1);
   return 0;
 }
 else 
 {
   return 1; //error
 }
}

A função schLoop agora precisa checar pelo valor de retorno do processo que acabou de executar. Se ele for REPEAT, ele é armazenado ao final do buffer.

void schLoop()
{
 while (1)
 {
   if (first != last) // tem algo
   {
     if ((*tasklist[first])() == REPEAT)
     {
       addTask(tasklist[first]); // reagenda
     }
      first=(fist+1)%N_TASK; // proximo processo
   }
 }
}

No próximo texto irei estender este escalonador para atender requisitos temporais de um sistema soft real-time.

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