Modelos de Comunicação

InterfPish utiliza dois modelos de comunicação: comunicação direta e comunicação síncrona por canal [15]. A comunicação direta se dá entre processos seqüenciais por compartilhamento de variáveis. Nela um processo pai se comunica com um processo filho através de um bloco de ativação. Depois que o processo filho tiver terminado sua tarefa, ele avisa o processo pai sobre o término através de um bloco de finalização. Um processo pai pode ativar vários processos filhos e tem que esperar que todos eles o avisem sobre o término de suas tarefas para que possa seguir em frente. A figura 2.2a mostra a ativação de um processo filho e a figura 2.2b mostra um processo filho informando ao processo pai sobre o

Capitulo 2 – O Estado da Arte

Figura 2.2 – Modelo de comunicação direta.

O outro modelo de comunicação implementado por InterfPish é a comunicação síncrona por canal, que acontece entre processos filhos (concorrentes), onde não há a possibilidade de compartilhamento de variáveis. A figura 2.3 mostra o modelo de comunicação por canal entre dois processos concorrentes P0e P1através do canal C0.

Figura 2.3 – Comunicação síncrona por canal.

Neste modelo, os canais de comunicação deixam os detalhes da transferência de dados transparentes para os processos P0 e P1 [15] e são responsáveis pela transferência de um

conjunto fixo de tipos de dados. Os canais sempre transferem exatamente os tipos de dados fixados para eles. Aos processos cabe apenas a tarefa de saber interagir com os canais, através de uma interface fornecida por eles. Existe uma interface com o processo transmissor, interface sender, e uma interface com o processo que vai receber os dados, interface receiver. A figura 2. 4 mostra a estrutura dos canais de comunicação.

Capitulo 2 – O Estado da Arte

Para que a comunicação seja efetuada, tanto o processo transmissor, no caso P0,

quanto o receptor, P1, devem ativar o canal, o que ocorre através do sinal de ativa. Os sinais

de pronto vistos na figura 2.4 servem para indicar que a comunicação terminou, liberando os processos para continuarem a realizar suas tarefas. Os canais podem ser implementados como componentes de hardware ou em software, como funções e estrutura. É interessante observar que estes modelos de comunicação apresentados não fazem nenhuma distinção com relação à natureza dos processos. Tanto faz se os processos estão implementados em hardware,

software ou se um deles está implementado em software e o outro em hardware. A

comunicação se dará sempre pela utilização de blocos de ativação, finalização ou canal de comunicação [15].

Entretanto, quando os processos que estão envolvidos em uma comunicação são de naturezas diferentes, é necessário que a ferramenta InterfPish gere uma interface que compatibilizará a comunicação entre estes processos. O modelo de interface gerado é simétrico, pois possui os mesmos componentes tanto do lado do hardware quanto do lado do

software. Alem disso, é dividido em camadas, o que torna a interface modular. A figura 2. 5

mostra um esquema da interface.

Figure 2.5 – A interface hardware/software.

Observando-se a figura 2.5, podem-se ver as três camadas que compõem a interface: a prcs_unit; a comm_unit e a io_unit. Cada uma destas camadas possui uma função específica. A camada mais externa, prcs_unit, serve de interface com os processos. Desta forma, sua função é implementar as partes dos componentes de comunicação (bloco de ativação, bloco de finalização e canal), como componentes em hardware ou software [15]. A figura 2. 6

Capitulo 2 – O Estado da Arte

mostra um esquema mais detalhado da camada prcs_unit. Nela são mostrados os quatro tipos de elementos que podem ser implementados nesta camada.

Primeiramente tem-se o sender, utilizado para fazer a interface com o processo transmissor quando a comunicação se dá por canal. O segundo elemento é o receiver, que é a interface com o processo receptor também numa comunicação por canal. Em seguida tem-se o bloco de ativação, utilizado como foi dito anteriormente, por processos pais para iniciar a comunicação com processos filhos, e finalmente, o último elemento é o bloco de finalização, utilizado por processos filhos quando estes desejam informar ao seu processo pai que sua tarefa foi terminada.

Figura 2.6 – Elementos da camada prcs_unit.

A camada intermediária do modelo de interface é responsável pela execução de três funções: escalonamento; buferização e acesso à camada io_unit [15]. Pelo fato da interface ser um recurso compartilhado pelos diversos processos concorrentes que compõem o sistema embarcado, o acesso a ela tem que ser controlado, sendo justamente esta a primeira função da camada comm_unit. Sua segunda função é a buferização. A função da buferização é permitir que dados vindos de/para a camada io-unit sejam armazenados em um buffer, com o objetivo de melhorar o desempenho da interface [15]. Por fim, o acesso à camada io_unit é responsável pelo recebimento/envio de dados de/para a camada io_unit.

A última camada a ter sua funcionalidade analisada é a camada io_unit. Trata-se da camada mais interna da interface, sendo responsável pela conexão do componente de software ao componente de hardware. Esta camada é a única das três que depende da arquitetura na qual o sistema será executado. Por este fato, ao contrário das outras duas camadas da

Capitulo 2 – O Estado da Arte

interface, a camada io_unit não é fixa e sua implementação pode variar desde a utilização de componentes diferentes, tais como modelos distintos de processador, até a maneira como processador e componentes de hardware estão conectados [15]. Apesar de não ser fixa, a camada io_unit sempre preserva a mesma interface com a camada comm_unit, o que permite que novas implementações suas sejam adicionadas à interface sem problema.

Além de gerar código para a implementação da comunicação entre processos de sistema, através dos modelos de comunicação que acabaram de ser apresentados, e interface, a ferramenta InterfPish também permite que os sistemas embarcados possam interagir com dispositivos de E/S. Esta interação ocorre segundo o modelo de processo de E/S, que pode ser visto na figura 2.7, onde a figura 2.7a representa um processo de E/S de saída e a figura 2.7b representa um processo de E/S de entrada.

Figura 2.7 – Modelo de processos de entrada e saída.

Cada dispositivo de E/S deve ser controlado de uma maneira específica. Devido a esta característica, os processos de E/S não podem ser fixos, devendo haver um processo de E/S diferente para cada dispositivo que se deseja controlar. Os processos de E/S são armazenados numa biblioteca de processos de E/S. Como é visto na figura 2.7, eles devem servir de interface entre o processo de sistema (P0), que deseja se comunicar com o dispositivo de E/S,

e o próprio dispositivo de E/S. Este modelo tem uma característica interessante: para os processos de sistema, a comunicação com dispositivos de E/S se dá como se ele estivesse se comunicando com qualquer outro processo de sistema, embora na verdade esteja se comunicando com um processo de E/S. Neste modelo, os processos de E/S podem ser encarados como drivers de dispositivos, com cada dispositivo possuindo um driver específico.

Capitulo 2 – O Estado da Arte

O modelo de processos de E/S utilizado por InterfPish é justamente a solução para o problema da interligação entre ele e o ambiente de geração de comunicação proposto por este trabalho. Considere que as primitivas de comunicação de envio e recebimento de dados sejam encaradas como dispositivos de E/S, que de fato são. Uma vez que elas são dispositivos de E/S, basta que sejam criados drivers (processos de E/S) que controlem estes dispositivos e que estes drivers sejam inseridos na biblioteca de processos de E/S da ferramenta InterfPish. Para isto, deverão então ser criados dois processos de E/S para a comunicação pela rede: um para o envio de dados e um para o recebimento de dados.

Os processos de E/S de comunicação pela rede têm a estrutura mostrada pela figura 2. 8. Nela, pode-se ver o bloco de controle do dispositivo e o bloco de controle do canal de E/S. O bloco de controle do dispositivo é responsável pelo acionamento dos sinais de controle do dispositivo e pela entrega dos dados que devem ser passados para ele. Já o bloco de controle de canal, deve controlar o canal de E/S ligado ao processo de E/S.

Figura 2.8 – Estrutura de um processo de entrada e saída.

Os blocos de controle de dispositivo que pertencem a processos de E/S de comunicação pela rede, devem passar para os dispositivos que controlam, sender ou receiver, as informações que formam a interface destes dispositivos. Uma última característica dos processos de E/S é que eles tanto podem ser implementados em software, quanto em

hardware.

2.3 Resumo do Capítulo

Neste capítulo foram apresentados diversos trabalhos relacionados, que representam o estado da arte em geração de comunicação e geração de interfaces para sistemas embarcados, e em seguida foi mostrado em detalhes o ambiente de co-síntese InterPish, que suporta a co-

Capitulo 2 – O Estado da Arte

síntese de sistemas embarcados não distribuídos. Inicialmente foi apresentado o fluxo de projeto de InterfPish e cada uma de suas etapas foi explicada. Em seguida, foram apresentados os modelos de comunicação do sistema, que suporta comunicação direta ou através de canais, foi apresentado o modelo da interface de comunicação, que compatibiliza a comunicação entre processos que estão alocados em componentes de software e processos alocados em componentes de hardware, e foram apresentados os modelos de processos de entrada e saída, que permitem que o sistema digital se comunique com o ambiente externo a ele.

CAPÍTULO 3