dois registos que apontam para o início e o fim. Sempre que o processador lê do registo de leitura da fila, o registo que aponta para o início, avança uma posição. Sempre que existe uma detecção o registo que aponta para o fim da fila é que avança uma posição. Foi necessária a implementação desta fila para que o processador não perca recepções.
Memória de Amostras
O sistema tem a capacidade de armazenar 8192 amostras doA/D, filtros passa-banda ou dos detectores de envolvente. Esta funcionalidade é controlada através de registos partilhados e uma Random Access Memory (RAM) partilhada. Com este sistema pode-se medir a potência do ruído existente nos filtros ou em banda base. Existe também a opção de parar a amostragem quando é recebida uma detecção, para que se veja a subida do sinal até atingir o nível de detecção. Estas técnicas foram muito úteis no desenvolvimento do projecto.
Emissão
Não representado na figura, o módulo de emissão serve para pedir um envio ao sistema de geração de sinais noMARES. Este foi feito em hardware para que se possa medir o tempo de envio sem latência, como é feito com as recepções. O módulo é muito simples e apenas liga o valor do canal que tem num registo partilhado aos pinos de saída daFPGAe activa um bit quando quer enviar um sinal. Como o sistema de emissão doMARES funciona a uma frequência mais baixa do que o sistema a ser desenvolvido, realizou-se um contador para que o bit esteja activo tempo suficiente.
O processador aqui implementado também vai servir para substituir o sistema acústico das bóias que é igual ao do submarino. Para isso, é preciso que certas frequências sejam respondidas automaticamente com o mínimo de latência possível. Foi criado para isso um módulo, que pode ser configurado, onde são registadas os pares de frequências a ser respondidos e envia um sinal caso seja detectada um sinal no canal correspondente. Para isto apenas foi necessário umaBRAM
e alguma lógica.
Também existe uma fila, no caso da emissão, que regista o valor do contador falado em3.4.2
e o número do canal quando existe um envio criado automaticamente ou pelo processador.
3.5
Software
Foram implementados dois programas para que o sistema funcione. Ambos usam capacidades do sistema operativo para guardar configurações na flash servindo-se de um sistema de ficheiros em memória e de um programa, já pertencente à distribuição, que sincroniza os ficheiros em memória com os da flash. Um dos programas estará sempre a correr enquanto o sistema está a funcionar. A sua função é monitorizar as filasFIFOde envio e recepção enquanto implementa o
36 Processador integrado para navegação deAUVs
A Suzaku não permitia, com as configurações originais, o uso exclusivo da porta série. To- das as mensagens do bootloader, kernel e consola eram enviadas automaticamente para lá, por isso para a reservar para uso exclusivo do programa, foram necessárias alterações tanto aos bootloaders como ao kernel. Os bootloaders tiveram de ser mudados para que, mediante um jumper, arrancas- sem o kernel com a consola desviada para "/dev/null", e não imprimissem nada por porta série. Infelizmente isto não resolveu o problema porque o kernel não reconhecia a linha de comandos. Investigou-se e descobriu-se que a zona de memória onde a linha de comandos era guardada era preenchida com zeros durante a execução do kernel e antes da leitura dos comandos, esta área de memória é chamada normalmente de Block Started by Symbol (BSS). Para resolver este BUG, foi mudado o ficheiro "arch/platform/suzaku/machine.c", para que, antes de inicializar a zona de memóriaBSS, a linha de comandos seja guardada temporariamente na stack e copiada de volta.
O protocolo implementado pelo programa de que se falava, funciona sobre RS-232, é simples, implementado ao byte e codificado para que tenha pouca latência. Existe um byte de sincronismo seguido por um byte de comando e argumentos variáveis. Nem todos os comandos do protocolo foram implementados porque não fazem sentido para o sistema, os que foram são os seguintes: Actualizar o vector de respostas Este comando é enviado para o sistema para actualizar o par de
frequências de resposta automática e guarda os dados na flash.
Actualizar resposta a um canal Realiza exactamente o mesmo que o anterior mas apenas para um par de frequências.
Ler vector de respostas Os dados das respostas automáticas são enviados para o processador central doMARES.
Ler resposta a um canal Mesmo do que o anterior mas apenas para um par de frequências. Ordenar envio O sistema, como resposta a este comando, envia um sinal no canal pedido. Este
comando é usado normalmente durante a navegação.
Alterar um nível de detecção Como o nome indica, o comando pede ao sistema para alterar o nível de detecção. Este comando é usado antes da missão quando é medido o nível de ruído e calibrados os níveis de detecção. Os níveis não são guardados em flash, apenas são mudados os parâmetros no hardware dedicado. O comando de leitura de um nível de detecção também está implementado.
Gravar nível de detecção Quando os níveis estão calibrados, este comando é usado para gravar um nível em flash.
Reset Este comando é enviado pelo sistema ao processador doMARES no arranque, logo que fique operacional.
3.5 Software 37
Envio ou recepção Quando o software detecta algum envio ou detecção nas filas correspondentes envia um comando destes com o tempo exacto e o canal do evento.
Os comandos ligados com a medição do estado da bateria, envio de dados doGPS, e controlo do rádio não foram implementados.
O segundo programa foi feito para servir como plataforma de configuração do sistema. Permite configurar os parâmetros do filtro em função da frequência central e largura de banda, o número de filtros a serem processados, níveis de decisão e respostas automáticas. Este é chamado no arranque
Capítulo 4
Implementação e Validação
Experimental
Neste capítulo são apresentados alguns resultados da implementação do sistema, assim como a sua validação. Para isso, foram realizados vários testes, que não seriam possíveis sem a ajuda do sistema operativo embebido. É feita aqui uma descrição de cada um deles assim como os resultados obtidos.
4.1
Implementação
A utilização daFPGAna plataforma de desenvolvimento está descrita na tabela4.1. De notar que a tabela inclui hardware que não seria usado na implementação final do projecto. A frequência de relógio usada tanto para o Microblaze como para o hardware dedicado é de 51MHz e, ao todo, a plataforma consome cerca de 1.6W.
Utilização lógica Usado Disponível Utilização
Número de Slices 5589 8672 64%
Número deBRAMs 28 28 100%
Número de Multiplicadores 11 28 39%
Tabela 4.1: Sumario da utilização da Spartan3E-1200.
O design, sem contar com o Microblaze e todos os periféricos de controlo de hardware não necessário para o projecto, foi sintetizado para uma FPGA Spartan3E-500 (tabela 4.2), que é usada em plataformas baseadas emFPGA, mais baratas e menos consumidoras do que a de desen- volvimento.
Da análise da tabela4.2conclui-se que o projecto pode ser implementado numa FPGAbem mais pequena sem nenhum esforço. Devido à ainda pouca utilização daFPGA, o Microblaze poderá ser acrescentado ao design final para realizar o protocolo de comunicação e calcular os parâmetros dos filtros em tempo real usando aritmética de virgula flutuante, caso seja necessário.
40 Implementação e Validação Experimental
Utilização lógica Usado Disponível Utilização
Número de Slices 826 4656 17%
Número deBRAMs 6 20 30%
Número de Multiplicadores 8 20 40%
Tabela 4.2: Sumario da utilização da Spartan3E-500.