Especificação da Interface do Driver com o Sistema Operacional

Com os modelos anteriores foi possível validar o endereçamento do dispositivo, mecanismos de sincronização, transferência de dados e o uso de buffers. Até o momento não foi considerado o uso de um sistema operacional. É cada vez mais comum a inclusão de um sistema operacional em projetos de software embarcado. Nesse contexto, os

drivers para os dispositivos devem ser adaptados ao modelo de drivers do sistema operacional. Os detalhes de implementação envolvidos no porte de um driver para o SO são considerados uma fonte de erro recorrente no interfaceamento de hardware e software. A linguagem DevC possibilita a especificação da interface do SO e a sua ligação com os serviços do driver validados anteriormente. A Figura 5.20 apresenta a parte da especificação do driver incluindo a interface com o sistema operacional uclinux.

Modelo No. de Wait states Tempo de Aplicação (s)

Sem Buffer 24596 16.76

Tese de Doutorado – Exemplo de Desenvolvimento Usando a Linguagem DevC 136

Figura 5.20: Descrição da interface com o sistema operacional

As informações relativas ao sistema operacional estão destacadas nas linhas 12 a 17. O sistema operacional alvo é declarado na linha 12. Em seguida, as funções da API do kernel são declaradas e definidas as ligações com os serviços do driver. A partir dessa descrição, a ferramenta dcsim gera a estrutura mínima para ser embutida no sistema operacional. Essa estrutura pode ser decomposta, basicamente, em três partes: estruturas de dados relevantes para o kernel; as funções que implementam a interface com o kernel e realizam a comunicação com o dispositivo; e o registro do driver junto ao kernel. A Figura 5.21 apresenta as partes geradas para o driver interagir com o sistema operacional. A estrutura mais importante para o kernel é aquela que define as operações que o

driver implementa. Esta estrutura é do tipo file_operations e o seu conteúdo é uma coleção de ponteiro para funções que implementam as chamadas de sistemas, tais como,

open, read, write, dentre outras. Essa estrutura é gerada automaticamente a partir de uma especificação em DevC. Em seguida, são geradas as funções que implementam as chamadas de sistemas. É importante notar que os nomes das funções são os mesmos que constam na estrutura lcdpcf8833_os_i_ops. No corpo de cada função é chamado o respectivo serviço especificado no mapeamento dc_os_map em DevC. Assim, por exemplo, no corpo da função lcdpcf8833_open é realizada uma chamada para o serviço

1. DEVC(lcdpcf8833){ 2. ...

3.

4. dc_format ctrl_type = "%data:9:s"; 5. dc_format drv_type = "%data:8:s";

6. dc_service <drv_type, WRITE> drv_send_data; 7. dc_service <ctrl_type, WRITE> ctrl_send_data; 8. dc_service <VOID, WRITE> drv_init;

9. dc_service <drv_type, WRITE> drv_setcontrast; 10. ...

11.

12. dc_os <uclinux> os_uclinux;

13. 14. dc_os_map os_i{ 15. os_uclinux.OPEN = drv_init; 16. os_uclinux.WRITE = drv_send_data; 17. os_uclinux.IOCTL = drv_setcontrast; 18. }; 19. ... 20. };

Tese de Doutorado – Exemplo de Desenvolvimento Usando a Linguagem DevC 137

drv_init. A partir desse código, o projetista pode adicionar novos comportamentos para as funções. Finalmente, o código necessário para iniciar o driver e a sua respectiva finalização também foi gerado. Há dois métodos para carregar e iniciar o driver: durante o procedimento de boot ou manualmente. Em qualquer um dos métodos, a função

lcdpcf8833_init será chamada. É nessa função que são feitas as solicitações de recursos ao kernel, tais como, alocação de memória e interrupção, registro do tratador de interrupção e o registro do driver junto ao kernel.

Estruturas de Dados

typedef struct lcdpcf8833_os_i { char data;

unsigned long size; }lcdpcf8833_os_i;

struct file_operations lcdpcf8833_os_i_ops = { write: lcdpcf8833_write,

open: lcdpcf8833_open, ioctl: lcdpcf8833_ioctl, };

Funções da API do Kernel

int lcdpcf8833_open(struct inode *inode, struct file *filp);

int lcdpcf8833_write(struct inode *inode, struct file *filp, const char *buf, int count);

int lcdpcf8833_ioctl(struct inode *inode, struct file * file, unsigned int cmd, unsigned long arg);

Registro do Driver e Finalização

int lcdpcf8833_init(void); #ifdef MODULE

module_init(lcdpcf8833_init); #endif

Figura 5.21: Código para integração do device driver com o sistema operacional

Vale ressaltar que, em geral, a geração de código para o sistema operacional varia com a versão do kernel e o tipo do driver. Nos exemplos desenvolvidos nesse trabalho, os

drivers gerados foram do tipo caractere.

O driver resultante do processo de síntese foi adicionado à arvore do código fonte e compilado juntamente com o kernel do sistema operacional. A plataforma usada para validar o driver foi apresentada na Figura 5.2, que apresenta os recursos para a execução do sistema operacional. Os modelos do controlador não são alterados e tanto o modelo

Tese de Doutorado – Exemplo de Desenvolvimento Usando a Linguagem DevC 138

com waitstate quanto o modelo baseado em interrupção foram usados com o sistema operacional.

A aplicação que usa o driver para acessar o LCD tem que ser ajustada, pois nas versões anteriores, ela chamava diretamente as funções do driver. Com a inclusão do sistema operacional, a aplicação foi executada no espaço do usuário e passou a fazer o acesso ao LCD através das chamadas de sistemas. A forma como a aplicação foi compilada também é diferente. O formato anterior era o elf [77], pois é o formato que o ArchC usa para carregar e executar as aplicações. A linha de comando a seguir compila a aplicação para o sistema operacional alvo:

make platform=archc bin=bflt prefix=/home/ebl2/svn- novo/uclinux-archc-par/trunk/romfs/bin

A aplicação foi compilada para o formato binário flat, pois esse é o formato que o

uclinux usa para os arquivos binários executáveis. Após a compilação, a aplicação foi copiada para o diretório do sistema de arquivos e estava disponível ao usuário quando a imagem do sistema operacional fosse gerada. A Tabela 5.8 apresenta algumas informações sobre a validação do driver com o SO.

Tabela 5.8: Comparação das versões do device driver com o sistema operacional

A tabela mostra informações relativas aos dois modelos do controlador gerados anteriormente: interrupção e com wait states. O código gerado para o driver com interrupção contém 44 linhas, enquanto a versão para o controlador com wait states fica em torno de 39 linhas. Esse código corresponde a parte necessária para embutir o driver no SO e não compreende o driver total que já foi contabilizado anteriormente. O

Driver (SO) Controlador Emulador Tempo de Simulação (S)

Wait States 39 61 132 285.69

Tese de Doutorado – Exemplo de Desenvolvimento Usando a Linguagem DevC 139

controlador não sofreu alteração e os mesmos modelos foram reutilizados para esses experimentos. O tempo de simulação para ambos foi de 86 s. Comparando esse tempo com o apresentado na Tabela 5.7, percebe-se o overhead causado pelo sistema operacional.

Os modelos gerados a partir da descrição em DevC, o suporte das plataformas virtuais e o porte do sistema operacional se constituem em uma ferramenta importante na exploração de alternativas de projetos tanto em relação ao driver quanto em relação ao controlador, tendo em vista que diversas combinações e variações podem ser validadas. Por exemplo, pode-se analisar qual o tamanho do buffer adequado com interrupção e sem interrupção, com sistema operacional e sem sistema operacional, etc. No próximo Capítulo serão apresentados alguns resultados relativos às várias combinações das alternativas de projeto.

5.3 Conclusão

O fluxo de projeto e os recursos da linguagem DevC foram apresentados passo a passo através do desenvolvimento de um controlador para integrar o módulo LCD gráfico ao ambiente de simulação. Devido à flexibilidade da linguagem, diferentes versões do controlador foram obtidas, levando a um desenvolvimento incremental, onde uma versão pode ser descrita a partir da anterior.

O modelo mais simples especifica os serviços que o controlador e o device driver implementam. Em seguida, os recursos como especificação de registradores, variáveis do

driver, interface com o sistema operacional, mecanismos de sincronização e a definição de buffers foram adicionados ao modelo, resultando em novas versões do controlador e do device driver.

Os modelos gerados foram integrados a um ambiente de desenvolvimento que facilita a geração da plataforma com diferentes recursos a depender da estrutura de software necessária. Dessa forma, é possível gerar uma plataforma com suporte à interrupção e execução do sistema operacional ou uma plataforma simplificada, suficiente para executar aplicações do usuário juntamente com o device driver gerado

Tese de Doutorado – Exemplo de Desenvolvimento Usando a Linguagem DevC 140

para o modelo do controlador em questão. Comparações entre os diferentes modelos foram abordadas.

Os recursos da linguagem DevC como mapeamento de serviços, especificação de diferentes mecanismos de sincronização e declaração de buffers possibilitam a exploração de alternativas de projetos por parte do projetista. No próximo capítulo, essas características serão abordadas mais enfaticamente. Adicionalmente, outros componentes que foram modelados em DevC serão apresentados e a validação em hardware real do

Tese de Doutorado – Modelos em DevC e Resultados Experimentais 141

Capítulo 6

"Fortes razões fazem fortes ações." ( William Shakespeare )

6 Modelos em DevC e Resultados Experimentais

Neste capítulo apresentamos outros exemplos de desenvolvimento de aplicações em hardware e software com o suporte da abordagem proposta e da linguagem DevC. Serão apresentados os controladores específicos desenvolvidos para a plataforma Aquarius – uma solução de hardware e software para prover reconfiguração dinâmica e parcial de dispositivos lógicos programáveis (FPGAs). Resultados obtidos com outros dispositivos como LCD a caractere e UART também serão mostrados. Além disso, o uso da linguagem DevC na exploração de alternativas de projetos é aplicado ao controlador do LCD gráfico discutido no capítulo anterior. A validação em hardware real do driver gerado para o controlador do LCD gráfico foi realizada e uma comparação com o ambiente de simulação é apresentada.

6.1 Um Driver para uma Aplicação em Computação