La mise en perspective historique des relations entre hommes et goélands

A TTFD task ´e uma tarefa respons´avel pelo controlo do tempo do payload. Visto ser um componente importante, foi decidido que o mesmo deveria ser implementado num

hardwarededicado, neste caso a FPGA. Como indicado anteriormente a FPGA n˜ao tem

qualquer sistema operativo logo a mesma n˜ao pode ser interrompida assincronamente. Para implementar a TTFD task, um temporizador foi criado que ´e capaz de interagir com o CPU permitindo comunicac¸˜ao nos dois sentidos. Como indicado anteriormente o CPU executa o sistema operativo, o payload e o wormhole bridge. A TTFD task deve receber o tempo limite da pr´oxima promessa e conseguir indicar a qualquer momento o componente que est´a a controlar o robˆo. Para isso o componente wormhole bridge passa a entregar o tempo da promessa directamente a TTFD task na FPGA em vez de a enviar para o micro- controlador. Depois disso a TTFD Task deve aguardar o tempo indicado na promessa e assim que o mesmo terminar mudar o controlo para o wormhole.

Para que a comunicac¸˜ao entre FPGA e CPU seja poss´ıvel existe uma drive j´a im- plementada para Linux e uma configurac¸˜ao para a FPGA que permitem a interacc¸˜ao do CPU com a FPGA atrav´es de o interface paralelo partilhado entre os dois. Este interface paralelo ´e constitu´ıdo por v´arias portas que est˜ao partilhadas entre ambos os hardwares. Ambos os componentes trabalham em conjunto de forma a transferirem informac¸˜ao do CPU para a FPGA e da FPGA para o CPU.

A configurac¸˜ao para a FPGA define um conjunto de portas que s˜ao utilizadas. Essas portas correspondem aos pinos na FPGA que v˜ao ser utilizados na configurac¸˜ao. Cada pino pode transportar um bit de cada vez. Desses pinos existem 35 que s˜ao partilhados entre CPU e FPGA, dos quais 16 que s˜ao para conter enderec¸os de mem´oria que o pro- cessador utiliza para controlar o acesso `a mem´oria de dispositivos externos (neste caso ´e a FPGA), 16 bits para envio de dados e 3 bits para flags. Adicionalmente existem 32 bits que correspondem a contactos do tipo GPIO que podem ser utilizados para receber/enviar informac¸˜ao directamente entre dispositivos.

Esta configurac¸˜ao aguarda pela indicac¸˜ao por parte do CPU de que tipo de operac¸˜ao quer fazer, escrita ou leitura, e pelo enderec¸o onde essa operac¸˜ao ir´a ocorrer. Uma vez obtida esta informac¸˜ao, a FPGA lˆe ou escreve dados via os 16 bits de dados partilhados entre o CPU e a FPGA.

A mem´oria utilizada por esta configurac¸˜ao ´e de 96 bits, divididas em zonas de 16 bits. Os primeiros 32 bits representam a assinatura do dispositivo e vers˜ao de 16 bits cada. Os 32 seguintes representam os bits de controlo para os 32 bits de mem´oria seguintes. Estes bits de controlo indicam se a porta est´a configurada para entrada ou sa´ıda. Os 32 bits

finais s˜ao dados que podem ser a qualquer altura lidos ou escritos por esta configurac¸˜ao. Estes 32 bits de dados est˜ao mapeados directamente para os pinos GPIO indicados ante- riormente.

A implementac¸˜ao faz uso de 32 pinos de GPIO em que cada um tem uma func¸˜ao espec´ıfica:

• porta 1-30 prazo em microssegundos. • porta 31 novo prazo dispon´ıvel para leitura. • Porta 32 controlo.

Os pinos 1 a 30 s˜ao pinos de entrada onde o CPU pode escrever o novo intervalo de tempo a ser observado. Estes 30 bits permitem intervalos de 1073741824 microssegun- dos que cumprem os requisitos actuais. Os requisitos actuais definem que o payload demora no sempre 0,5 segundos a iterar. O pino 31 indica que um novo valor de tempo est´a dispon´ıvel para leitura nos pinos 1 a 30. O pino 32 indica quem tem o controlo do robˆo. A implementac¸˜ao deste m´odulo corre a 60 MHZ embora a unidade de tempo enviada seja microssegundos. Isto quer dizer que a FPGA itera mais r´apido do que ´e re- almente necess´ario sendo que cada iterac¸˜ao est´a completa em 16,66 nanossegundos. Para ser poss´ıvel monitorizar o tempo microssegundos foi necess´ario criar um contador para contar as iterac¸˜oes da FPGA e outro que cont´em o intervalo enviado anteriormente. O primeiro contador ´e incrementado cada vez que a FPGA itera. Com a FPGA itera garan- tidamente em 16,66 nanossegundos a cada 60 iterac¸˜oes podemos considerar que passou um microssegundo e decrementar o segundo contador. O segundo contador cont´em o intervalo a monitorizar e `e decrementado de acordo com a condic¸˜ao indicada em cima. Quando o contador chega a 0, o wormhole ´e informado que agora deve controlar o robˆo.

A informac¸˜ao de controlo ´e enviada pelo pino 32 colocando a porta num estado baixo (0 Volts) caso o wormhole esteja em controlo ou num estado alto (3,3 Volts) caso o pay- load esteja em controlo do robˆo. Se o payload falhar uma entrega o controlo passa para o wormhole sendo necess´ario que o payload consiga cumprir um prazo para voltar a ficar com o controlo do robˆo.

A mensagem do tipo promessa usada entre o wormhole e wormhole bridge foi alterada como consequˆencia deste melhoramento para deixar de levar o pr´oximo prazo. Este prazo agora ´e enviado directamente para a TTFD task na FPGA por isso deixa de ser necess´ario ao microcontrolador ter conhecimento do prazo.

No wormhole foi removido o c´odigo de gest˜ao de tempo embora o wormhole mant´em as funcionalidades que permitem aplicar as penalidades ao payload por incumprimento da promessa. O wormhole agora verifica a cada iterac¸˜ao do ciclo de controlo se existe um timeout. Se existir um atraso aplica a penalidade correspondente, sen˜ao continua.

O wormhole bridge teve que ser adaptado para ao receber a promessa vinda do pay- load, retirar o prazo da promessa e envia-lo para a TTFD task na FPGA e enviar o resto da mensagem para o wormhole no microcontrolador. O prazo da promessa tem que ser agora adaptado para ser enviado para a TTFD task. A TTFD task apenas consegue receber o n´umero em formato bin´ario, logo o mesmo tem que ser convertido bin´ario, e depois o estado de cada uma das portas da FPGA tem que ser individualmente definida. Ao receber este n´umero a FPGA comec¸a a contar para baixo at´e chegar a 0. Quando chegar a 0 indica que existiu o prazo n˜ao foi cumprido.

Exactamente como na ´ultima alterac¸˜ao efectuada ao sistema, esta alterac¸˜ao ´e transpa- rente ao payload, logo o mesmo n˜ao tem que ser alterado para usufruir desta funcionali- dade adicional.

6.3.2

Mapeamento dos Componentes no Hardware

Nesta secc¸˜ao ´e apresentada o mapeamento dos componentes no hardware dispon´ıvel aquando o final da terceira iterac¸˜ao e s˜ao tiradas algumas conclus˜oes sobre o mapea- mento actual. A figura 6.4 apresenta o mapeamento dos componentes no hardware.

Como ´e poss´ıvel observar o payload continua instalado no ARM n˜ao tendo rece- bido qualquer alterac¸˜ao nesta iterac¸˜ao, a TTFD task passou para outro hardware mas o

wormholecontinua a consultar este m´odulo para obter quem tem o controlo do robˆo num

dado momento. Adicionalmente a mensagem promessa que ´e trocada entre wormhole

bridgee wormhole foi alterada para remover o prazo da pr´oxima entrega. A TTFD task

foi adaptada na FPGA de forma a permitir o controlo de um prazo que ´e agora indicado pelo wormhole bridge. O wormhole bridge recebeu algumas alterac¸˜oes de forma a agora n˜ao enviar o novo prazo para o wormhole e envia-lo para o m´odulo TTFD task instalado na FPGA. O payload e wormhole bridge continuam a comunicar atrav´es de sockets. O

wormhole bridge e o wormhole continuam a comunicar atrav´es de s´erie. O wormhole

bridge e o m´odulo TTFD task comunicam agora atrav´es de um bus de mem´oria parti-

lhado. O m´odulo TTFD task comunica com o wormhole atrav´es de pinos. No final desta iterac¸˜ao ´e poss´ıvel verificar o seguinte:

• Se a placa H4090 falhar o robˆo cont´ınua operacional e o controlo ´e assegurado pelo wormhole.

Figura 6.4: Mapeamento dos componentes do middleware no hardware ap´os a terceira iterac¸˜ao

• A carga do Atom pro 28 ´e ligeiramente diminu´ıda com esta alterac¸˜ao n˜ao sendo necess´ario ao microcontrolador controlar os prazos do payload.

• A FPGA permite uma melhor resoluc¸˜ao de tempo do que o microcontrolador, visto que a FPGA trabalha com clocks mais altos e isso permite mais iterac¸˜oes por se- gundo.

• O wormhole pode funcionar correctamente sem o m´odulo ttfd task. O wormhole apenas assume que o componente payload n˜ao respondeu a tempo (ocorre quando a placa H4090+H6042 se desliga por bateria fraca).