Processador de Comandos

Com o objetivo de agilizar a comunica¸c˜ao entre o PIC e o m´odulo BLE, foi desenvolvido um processador de comandos integrado no firmware da placa, ou seja, uma fun¸c˜ao que ´e invocada para processar comandos recebidos, tendo como argumentos o conte´udo relevante para identificar o prop´osito de cada um. No in´ıcio deste projeto, este mecanismo j´a existia para simplicar a comunica¸c˜ao entre a Raspberry Pi e o PIC. Como exemplo disso, a Raspbery Pi poderia enviar um comando para abrir um cacifo espec´ıfico se o mesmo lhe fosse solicitado pelo utilizador. Assim, todo o processo de alcan¸car o cacifo e abri-lo tornava-se mais simples com estes comandos pr´e definidos. Mediante as funcionalidades adicionadas relativamente ao projeto inicial, houve necessidade de se aumentar o n´umero de comandos suportados por esta camada de firmware. Uma vez que se usa o modo MLDP nas liga¸c˜oes ao m´odulo por parte dos dispositivos Android, torna-se simples receber e responder a comandos diretamente a partir da UART, tendo que colocar o processador de comandos “`a escuta” na mesma.

Nesta camada de firmware foram definidas a estrutura dos comandos e as respetivas respostas, consoante os argumentos recebidos. Quanto `a estrutura¸c˜ao dos comandos, foi utilizada uma l´ogica de continua¸c˜ao do c´odigo j´a existente. Isto ´e, os comandos que `a priori j´a estavam definidos antes do in´ıcio deste projeto foram mantidos, para que n˜ao se pusesse em causa alguma funcionalidade j´a existente, e os novos foram adicionados como continua¸c˜ao do c´odigo anterior. O facto de se querer dar continuidade a toda a l´ogica do c´odigo anterior justifica a necessidade de cria¸c˜ao de alguns longos comandos que, `a primeira vista, parecem ter campos desnecess´arios.

Todos os comandos utilizados no sistema tˆem por base a seguinte estrutura:

“$” Vers˜ao “,” TOF “,” No de sequˆencia “,” Arg. 1 “,” Arg. 2 “#”

O elemento “$” ´e o iniciador, marca o in´ıcio de uma trama do tipo comando. A “,” ´e o elemento separador, separando assim os argumentos do comando. J´a o “#”, elemento finalizador, assinala o fim da trama e serve para detetar que um comando foi recebido por completo.

Nas figuras 4.8 e 4.9 est˜ao apresentados, sob forma de tabelas, todos os comandos pedido definidos no ˆambito do presente projeto e as respetivas respostas (comandos resposta) que se recebem ao invoc´a-los. A divis˜ao em duas tabelas diferentes relaciona-se com o valor de TOF (“Type of Frame”): na primeira (figura 4.8), com o valor de TOF constante de “12”, as fun¸c˜oes invocadas por detr´as dos comandos para se poder devolver uma resposta est˜ao

Figura 4.8: Campos dos comandos definidos no projeto e respetivas tramas de resposta sob forma de tabela. - Parte 1

Figura 4.9: Campos dos comandos definidos no projeto e respetivas tramas de resposta sob forma de tabela. - Parte 2

localizadas no m´odulo de firmware da EEPROM; enquanto que os comandos com TOF “10”, na figura 4.9, requerem a utiliza¸c˜ao de fun¸c˜oes desenvolvidas no m´odulo de firmware que diz respeito ao controlo das placas auxiliares. Os campos Vers˜ao, TOF, No de Sequˆencia e os respetivos Argumentos s˜ao utilizados para a constru¸c˜ao de um comando com a estrutura apresentada anteriormene consoante o seu prop´osito. No campo “Descri¸c˜ao” pode-se perceber o significado de cada campo do comando e a negrito, na mesma, o prop´osito para o qual o comando ´e utilizado. Do lado esquerdo aparecem os comandos enviados ao PIC, os comandos pedido, para serem processados e, do lado direito, as confirma¸c˜oes/respostas aos mesmos (commandos resposta). Note-se que os comandos resposta seguem a mesma estrutura e l´ogica de constru¸c˜ao dos comandos pedido. Por norma, s˜ao os ´ultimos dois campos, ou s´o mesmo o ´

ultimo, que apresentam o resultado ao pedido, isto ´e, se o comando foi processado e executado corretamente ou se houve algum problema e poder´a devolver um argumento de resposta a algo concretamento solicitado, por exemplo o ID de um utilizador.

Como exemplo de explica¸c˜ao das tabelas anteriores passa-se a descrever alguns dos co- mandos apresentados.

• No caso de se querer verificar a existˆencia de um utilizador e respetiva palavra chave no sistema utiliza-se o comando com TOF “12”(que identifica que se ter´a de recorrer ao m´odulo de firmware da EEPROM) e 1o Argumento “3”, tal como ´e declarado na descri¸c˜ao deste. Para o utilizar basta enviar, neste caso via UART, a seguinte trama:

“ $0,12,0,3,rita,1234# ”

Como resposta ao mesmo poder˜ao receber-se as seguintes op¸c˜oes: 1. “ $0,12,0,3,0,5# ”

2. “ $0,12,0,3,997# ” 3. “ $0,12,0,3,998# ” 4. “ $0,12,0,3,999# ”

O caso 1 acontece quando os valores enviados em 2o e 3o argumento se igualam a um registo j´a armazenado outrora na EEPROM. O ´ultimo dado da trama resposta, “5”, corresponde ao ID do utilizador com nome de utilizador “rita”e palavra chave “1234”. Na situa¸c˜ao 2 ´e recebido o valor “997”que, pela figura 4.8 corresponde ao ERRO 1, ou seja, o nome de utilizador foi identificado (existe na EEPROM) mas a palavra chave enviada como 3o Argumento (PIN) n˜ao est´a correta. Para a terceira situa¸c˜ao, em que ´

e recebido o valor de “998”(ERRO 2), o nome de utilizador enviado n˜ao ´e reconhecido e, por isso, n˜ao existe. No quarto caso acontece o ERRO 3, isto ´e, o valor do 2o _dado

da trama ´e “999”, que significa que o utilizador est´a ocupado de momento numa sess˜ao da aplica¸c˜ao Android e que, por isso, n˜ao poder´a ser usado pelo dispositivo que est´a a tentar verificar a existˆencia deste utilizador.

• Analisando agora um exemplo da segunda tabela, isto ´e, com valor de TOF de “10”, envia-se a seguinte trama:

“ $0,10,2,0,0,0# ”

A trama anterior serve para procurar por uma placa auxiliar livre, isto ´e, um cacifo, que esteja dispon´ıvel. O campo n´umero de sequˆencia, utilizado por norma para numerar as tramas enviadas e se poder controlar se alguma for perdida, foi escolhido para ser um campo normal, para a interpreta¸c˜ao do comando. A resposta ao mesmo pode ser de dois tipos, apresentados a seguir.

1. “ $0,10,2,27# ” 2. “ $0,10,2,229# ”

Na primeira situa¸c˜ao ´e identificado um cacifo livre e enviado o endere¸co da respetiva placa auxiliar, neste caso “27”. Na segunda, nenhum endere¸co ´e devolvido por n˜ao haver nenhum cacifo dispon´ıvel, sendo assim devolvido o valor de erro “229”.