A definição da interface de comunicação da linguagem TDevC é composta pela especificação dos registradores do dispositivo, os formatos destes registradores e padrões de dados através das construções register, format e pattern, respectivamente. A Figura 48 mostra um exemplo dessas construções. d e v i c e ( d m 9 0 0 0 a ) { 2 p a t t e r n R X N O E R R O R = mask ( x x x x 0 0 0 0 ) ; 4 f o r m a t p h y s i c a l A d d r f m t { RW PAB [ 7 : 0 ] ; 6 } 8 e x t e r n a l r e g i s t e r i n d e x R e g (0 x00 ) ali as I N D E X R E G { RW IND EX [ 1 5 : 0 ] ; 10 } 12 i n t e r n a l I n t R e g s P r o t r e g i s t e r n e t w o r k S t a t u s R e g (0 x00 ) ali as NSR { READ S PEE D [7]; 14 READ L I N K S T [6]; RW W A K E S T [5]; 16 r e s e r v e d [4]; RW T X 2 E N D [3]; 18 RW T X 1 E N D [2]; READ RXOV [1]; 20 r e s e r v e d [0]; } 22 i n t e r n a l I n t R e g s P r o t r e g i s t e r p h y A d d r R e g 5 (0 x15 ) ali as PAR5 = p h y s i c a l A d d r f m t ; 24 ...
Capítulo 6. A Linguagem TDevC 116
Primeiramente, toda especificação TDevC começa com a palavra reservada device seguida pelo nome do dispositivo cujo modelo está sendo especificado, como mostrado na linha um da Figura 48.
A linha 2 da Figura 48 mostra um exemplo de uma declaração de um padrão, através da palavra reservada pattern. O uso de padrões permite especificar formatos numéricos de máscaras. Eles tornam a descrição dos comportamentos mais claras e menos propensa a erros. Este tipo de especificação lembra bastante a declaração de variáveis constantes de linguagens de programação, mas além de valores fixos, pode-se especificar também formatos fixos de dados. o padrão RXNOERROR especificado na Figura 48-linha 2 define o formado do dado que deve ser lido, independente da origem deste dado, quando houver um erro na transmissão de um pacote de dados via dispositivo Ethernet DM9000A. Neste exemplo a palavra reservada mask define a máscara que um dado lido ou escrito deve respeitar ao ser comparado com este padrão. A máscara é definida com a composição de valores do tipo don’t care (x), tipo zero (0) ou tipo um (1). Valores do tipo don’t care indicam que o bit naquela determinada posição pode ser valorado com zero (0) ou um (1). Para o tipo zero, é obrigatório que o bit em questão tenha o valor zero (0), e para o valor um (1), que o bit em questão tenha o valor um (1). Neste caso, o dado deve conter obrigatoriamente os últimos quatro bits iguais ao valor zero (0);
A palavra reservada register, como o nome mesmo diz, representa a declaração de um registrador real de um dispositivo. Os registradores podem ser declarados explicitamente com seus nomes, suas visibilidades, seus apelidos ou nomes fantasias (alias), seus campos e permissões de acesso e seus endereços físicos, como mostrado na Figura 48-linhas 8 a 20 ou podem ser declarados utilizando formatos de registradores previamente declarados através da palavra reservada format, como mostram as linhas 4, 5 e 6 da Figura 48.
A declaração dos formatos de registradores é muito parecida com a declaração dos próprios registradores, diferenciando apenas no fato de que os formatos não são vinculados a nenhuma visibilidade, nenhum endereçamento e nome fantasia, uma vez que esses atributos somente fazem sentido quando atrelados a registradores reais.
Como pode ser visto na Figura 48-linhas 8 e 12, existem dois tipos de visibilidade de registradores: externos, representados através da palavra reservada external, e internos, representados através da palavra reservada internal. Os registradores externos são todos aqueles que são mapeados na faixa de endereçamento da plataforma, ou seja, os regis- tradores que são diretamente acessados pelos componentes mestres do sistema durante a comunicação. Usando como exemplo a DM9000A, este registradores seriam o INDEX e o
DATA.
Já os registradores internos, são aqueles que não são endereçados diretamente na faixa de endereços do sistema. Estes são acessados através de um protocolo de acesso aos registradores externos, comumente implementado nas camadas de software dependente de hardware. Na Figura 48-linhas 12 e 22 tem-se exemplos de dois registradores internos que
Capítulo 6. A Linguagem TDevC 117
utilizam um protocolo de acesso chamado IntRegsProt. A declaração e especificação dos protocolos serão detalhadas na Seção 6.2, a seguir.
É importante destacar que os endereços atribuídos aos registradores são endereços absolutos dentro da faixa predefinida para os dispositivos, porém, para os registradores externos, eles são relativos no escopo da plataforma. Tomando como exemplo o registrador externo indexReg, pode-se perceber que ele é o registrador de endereço 0x00 no dispositivo. Entretanto, caso o periférico em questão se encontre na faixa de endereço 0x00A-0x00E do sistema, seu endereço relativo na faixa de endereçamento do sistema referente a este dispositivo é dado por 0x00 e traduzido, durante a síntese pela TDevCGen, para o endereço absoluto 0x00A na plataforma.
Ainda em relação ao endereçamento dos registradores, registradores externos estão em um escopo de endereçamento diferente dos registradores internos, uma vez que os externos têm seus endereços vinculados e traduzidos diretamente na plataforma alvo e os internos são relativos ao protocolo de acesso. Assim, com esta relação dos registradores internos com os seus protocolos, fica mais evidente que cada protocolo definido carrega consigo um escopo diferenciado de endereçamentos, permitindo que registradores internos com diferentes protocolos e registradores externos compartilhem na especificação o mesmo valor numérico de endereços. Um exemplo disto pode ser visto na Figura 48-linhas 8 e 12.
O atributo alias define um nome fantasia ou apelido para o registrador, podendo ser usados na especificação do protocolo na linguagem. Como mencionado, o alias não é obrigatório; o objetivo deste mecanismo é apenas permitir a referência simplificada do registrador na especificação, ao mesmo tempo mantendo a sua descrição completa e clara. Normalmente os datasheets (documentações oficiais de dispositivos) fazem referência ao nome completo do registrador em sua apresentação e referência de um nome fantasia, comumente suas iniciais, na sua aplicação no uso do dispositivo.
Os campos dos registradores, Figura 48-linhas 5, 9 e 13 a 20, são subdivisões lógicas descritas nos datasheets dos dispositivos. Normalmente cada subdivisão tem uma função específica. Um valor atribuído a um campo pode acarretar em um comportamento no dispositivo. Logo, para tornar mais clara a descrição em TDevC e reduzir a possibilidade de erros na comparação de valor de registradores, a linguagem permite especificar campos aninhados. Registradores contêm campos, seus campos por sua vez podem também conter subcampos e assim por diante, sem limite de níveis de aninhamento.
Se o datasheet informa que o campo é reservado, ou seja, de uso interno, não estável ou ainda não foi definido pelo fabricante, usa-se a declaração de campo reservado, como mostram as linhas 16 e 20 da Figura 48. Percebe-se que na declaração de um campo reservado não se especifica nem permissão de acesso, uma vez que a única permissão de acesso aceitável (mas não recomendada) é somente leitura, e nem subcampos, uma vez que subcampos de um campo reservado também serão reservados.
Capítulo 6. A Linguagem TDevC 118
Mostrada nas linha 5, 9, 13, 14, 15, 17, 18 e 19 da Figura 48, este tipo de declaração requer três atributos obrigatórios e permite dois atributos opcionais. Começando pelos obrigatórios, o primeiro atributo é a permissão de acesso. Os campos podem ter acessos somente para escrita (WRITE ), somente para leitura (READ) ou para escrita e leitura (RW ).
A seguinte atributo obrigatório é o nome do campo. Todo campo deve conter um nome, mesmo que este tenha subcampos. Estes nomes são usados para se ter uma referência destes campos na definição do protocolo da linguagem TDevC. Os campos de um registrador são referenciados através do nome ou alias do registrador seguido de um "." acompanhado do nome do campo. O mesmo padrão serve para subcampos de campos e assim por diante. Um exemplo pode ser visto na sintaxe a seguir que declara um campo INDEX do registrador
indexReg.
i n d e x R e g . IND EX
Se, por exemplo, o campo INDEX do registrador indexReg tivesse um subcampo chamado
INDEXHI, sua referência seria feita da seguinte maneira: i n d e x R e g . IND EX . I N D E X H I
e assim por diante.