Depuracao Blocos - V102

COTUCA - UNICAMP

ANDERSON PIRES ROCHA

DEPARTAMENTO DE MECÂNICA

GUIA DE DEPURAÇÃO BLOCOS V 1.0.2a

CAMPINAS 2014

INTRODUÇÃO O ambiente Blocos foi desenvolvido de forma a ser amigável e simples, visando a acessibilidade dos usuários, tanto em sua instalação, quanto na sua utilização, no entanto, problemas poderão ocorrer no momento em que nosso programa for gravado na placa de desenvolvimento. Estes problemas poderão ter diversas origens, assim, este guia auxiliará na solução de alguns destes, principalmente daqueles que acontecem de maneira mais corriqueira com usuários iniciantes.

1. JANELA DE DEPURAÇÃO Junto à janela principal do Blocos, será aberta um Janela de Depuração (figura 1), a qual se ocupará com diversas informações, principalmente com aquelas relacionadas às operações executadas pela placa. A maioria destas informações poderá ser ignorada, no entanto, em alguns casos, para a solução de problemas, algumas mensagens serão exibidas apenas nesta janela.

Figura 1: Janela de Depuração

2. ERRO DE SINTAXE Assim como qualquer linguagem de programação, temos uma sintaxe que deverá ser

utilizada, ou seja, cada bloco terá a forma correta de ligação, além disso, em alguns casos, determinados blocos necessitarão de conexões adjacentes para operarem de maneira adequada. Seguindo as abas apresentadas pela Guia de Blocos, teremos alguns exemplos comuns, que embora simples, quando apresentados isolados, podem implicar em problemas consideráveis em programações mais complexas.

Na figura 2, embora o bloco Início esteja presente, esta é considerada uma programação incompleta ou vazia, que ao será compilada (gravada na placa) apresentará erro.

Figura 2: Programação Vazia

Abaixo, da figura 3 à figura 29, temos exemplos de situações em que os blocos utilizados estão incompletos, devido à falta de blocos adjacentes que determinam como será o comportamento do bloco principal.

Figura 3: Bloco Ligue_por sem parâmetro (bloco Número)

Figura 4: Bloco Potência sem parâmetro (bloco Número)

Figura 5: Bloco Posição sem parâmetro (bloco Número)

Figura 6: Bloco Se incompleto (sem condição)

Figura 7: Bloco Condição incompleto (sem valores)

Figura 8: Bloco Condição incompleto

Figura 9: Blocos Se incompleto

Figura 10: Blocos Senão incompleto (sem condição)

Figura 11: Bloco Condição incompleto (sem valores)

Figura 12: Bloco Condição incompleto

Figura 13: Bloco Senão incompleto

Figura 14: Bloco Senão incompleto

Figura 15: Bloco Laço incompleto

Figura 16: Bloco Repetir incompleto (bloco Número)

Figura 17: Bloco Repetir incompleto

Figura 18: Bloco Espere incompleto

Figura 19: Bloco Condição incompleto

Figura 20: Bloco Condição incompleto

Figura 21: Bloco Condição incompleto

Figura 22: Bloco Condicional incompleto

Figura 23: Bloco Condicional incompleto

Figura 24: Bloco Condicional incompleto

Figura 25: Bloco Variável incompleto

Figura 26: Bloco Variável incompleto

Figura 27: Bloco Lógica incompleto

Figura 28: Bloco Espere incompleto (sem Tempo)

Figura 29: Bloco Mostrar incompleto (sem Número, Sensor ou Variável)

Na figura 30, temos um exemplo da mensagem exibida ao tentamos realizar o download de nosso programa na placa. Porém, em algumas situações, conforme a figura 31, teremos que recorrer à janela de depuração para identificarmos um possível problema.

Figura 30: Aviso de problemas visual

Figura 31: Aviso de problemas na janela de depuração

Na figura 32, temos o uso incorreto do bloco Variável, devido à inserção de um bloco Sensor em seu lugar. Pela figura 33, verificamos a mensagem que poderá ser retornada na tentativa de gravarmos o programa na placa.

Figura 32: Uso incorreto da variável

Figura 33: Mensagem visual exibida

Além da utilização incorreta do Blocos variável, temos o uso também incorreto do bloco Sensor, de forma que este foi projetado apenas para receber os valores proveniente dos sensores e repassar estes valores à outros blocos. Nas figuras 34 a 36, temos a utilização do bloco sensor conectados a blocos de controles de motores, repetição e tempo. Embora isto não esteja errado e seja reconhecido pela placa, na prática, esta poderá assumir comportamentos diferentes daqueles que desejamos, causando um mau funcionamento em nosso programa.

Figura 34: Uso incorreto dos blocos Motor e Sensor

Figura 35: Uso incorreto dos blocos Repetir e Sensor

Figura 36: Uso incorreto dos blocos Tempo e Sensor

Através da figura 37, verificamos que em alguns casos, blocos poderão ficar soltos ou sem conexão, quer seja de maneira intencional, ou de maneira acidental. Isso poderá confundir nossa programação ou causar problemas de mau funcionamento.

Figura 37: Bloco sem conexão

Na figura 38, notamos que o bloco Procedimento (proc0) se encontra incompleto, desta forma, nosso programa não será gravado na placa.

Figura 38: Procedimento aberto ou não finalizado

Assim como qualquer outra linguagem de programação, antes de utilizarmos variáveis em nosso programa (figura 39, figura 40), deveremos declará-la no início da programação.

Figura 39: Variável não declarada

Figura 40: Variável não declarada

Desta forma (figura 41), evitamos que estas variáveis assumam valores diferentes daqueles que planejarmos ou interfiram de forma negativa em nossa programação.

Figura 41: Variável declarada corretamente

Outro problema muito comum ocorre devido à presença de caracteres especiais ou mesmo acentuação em blocos como Variável (figura 41, 43) e Procedimento (figura 45, 47).

Figura 41: Variável com acentuação

Novamente, para estes casos, nosso programa não será gravado na placa e somente através da janela de depuração (figura 42, 44, 46 e 48) a mensagem de erro será apresentada.

Figura 42: Erro devido à acentuação

Figura 43: Variável com acentuação

Figura 44: Erro devido à acentuação

Figura 45: Procedimento com acentuação

Figura 46: Erro devido à acentuação

Figura 47: Procedimento com acentuação

Figura 48: Erro devido à acentuação

Sendo assim, recomendamos a utilização apenas de letras ou caracteres convencionais.

3. USO DE PROCEDIMENTOS O uso de procedimentos, ou ainda sub-rotinas na programação, são muito úteis quando desejamos executar uma mesma tarefa em diversas situações, evitando assim, a escrita repetitiva da

mesma, por conseguinte, uma economia de memoria da placa e por fim, a facilidade de realizar manutenção em nosso programa. No entanto, conforme a figura 49, em algumas versões do ambiente de programação não poderemos utilizar um bloco Procedimento logo no início de nosso programa e principalmente antes do bloco Laço, evitando assim que a placa apresente mau funcionamento.

Figura 49: Procedimento antes do Laço

Na figura 50 e o manual do Blocos, temos um limite de quantidade de procedimentos que poderão ser utilizados. Dependendo da programação desenvolvida, este número estará entre 6 e 8, de forma que, quantidades superiores poderão causar o travamento da placa.

Figura 50: Número máximo de procedimentos

Em situações em que nosso programa (figura 51) esteja escrito corretamente, ele será compilado e gravado com sucesso na placa (figura 52), podendo assim ser executado.

Figura 51: Programa simples

Figura 52: Aviso de programação correta

4. ESPAÇO PARA GRAVAÇÃO DE PROGRAMAS Um último fator a ser levado em consideração trata do espaço utilizado ou consumido por nosso programa na memória interna da placa. Oficialmente, esse assunto não é abordado pelos fabricantes, já o objetivo principal da plataforma é o uso por crianças e projetos muito simples. Mesmo assim, quando se trata de uma programação voltada para a área de mecatrônica, esse limite poderá ser facilmente atingido e nosso programa poderá não ser totalmente gravado na placa. Pensando nisso, através da janela de depuração (figura 53), poderemos acompanhar quanto utilizaremos de espaço em nossa programação.

Figura 53: Memória utilizada na placa

Por diversas razões que não serão aqui abordadas, verificamos que para o correto funcionamento de nosso programa, este valor deverá ficar abaixo de 256 Bytes (figura 54).

Figura 54: Memória utilizada

Em programas mais extensos (figura 55, figura 56), notamos que se este valor for

ultrapassado (figura 57), problemas na execução, ou gravação poderão ocorrer, inclusive, em alguns casos com o travamento da placa. Nas versões de software anteriores a 2011, a informação de memória exigida por nosso programa poderá não ser exibida, no entanto, mesmo de forma imperceptível para alguns usuários, a placa emitira um sinal sonoro de bip diferente do habitual, durante o processo de download do programa ou durante a tentativa da placa em executá-lo. Por fim, dependendo das versões utilizadas do Blocos, firmware, sistema operacional do computador, se o programa for muito extenso, o processo de gravação do mesmo na placa poderá exceder o tempo limite do processo, assim, além de nosso programa não ser gravado por completo ou corretamente, o sistema da placa, conhecido como bootloader poderá ser apagado, deixando a placa totalmente inoperante. Neste caso, o microcontrolador utilizado na placa deverá ser reprogramado através de outros sistemas com este fim.

Figura 55: Exemplo de programa extenso

Figura 56: Exemplo de programa extenso

Figura 57: Limite de memória excedido

Outra forma de analisar possíveis problemas será pela verificação do tamanho do nosso programa. Através do Windows Explorer, ou mesmo em outros gerenciadores de arquivos, mesmo antes de abrirmos o Blocos, poderemos identificar se ele poderá ser gravado na placa. Em resumo, precisamos ficar atentos ao tamanho (figura 58) do arquivo que dará uma indicação do espaço necessário, ou ainda se ele será aberto pelo Blocos para ser trabalhado.

Figura 58: Tamanho no explorer

Notamos que se o tamanho do arquivo exceder 30 ou 50 kbytes, o Blocos poderá apresentar travamentos e lentidão. A partir de 100 kbytes, o arquivo não poderá nem mesmo ser aberto pelo software. Podemos ultrapassar um pouco o limite inicial de 256 Bytes, para isso, uma das formas encontradas se dá pela utilização de um bloco Procedimento (figura 53).

Figura 53: Solução temporária

Desta forma, segundo nossos testes (figura 54), poderemos utilizar cerca de 1Kbyte de memória, sem maiores problemas, porém, ultrapassando o tamanho do arquivo, deixando-o com cerca de 130Kbytes, feito apenas para este teste. Este mesmo arquivo não pôde mais ser salvo e reaberto, devido aos limites já apresentados anteriomente.

Figura 54: Novo limite de memória

A plataforma poderá ser programada não somente, através da linguagem Blocos, como também, através da linguagem Logo. Desta forma, teremos um limite ainda maior para programação, porém, não ultrapassando os 3Kbytes (figura 55).

Figura 55: Limite Logo testado

Estas duas alternativas poderão ser utilizadas apenas em alguns casos em que a programação ultrapassar os limites não oficiais de 256Bytes, sendo suficiente para a maioria dos projetos na área de mecatrônica.

5. PROBLEMAS DE CONEXÃO Existem situações, que por algum motivo a placa se encontra travada ou desconectada, sendo assim, ao realizarmos o download de nosso programa, poderemos obter as mensagens de erro apresentadas pelas figuras 56, 57 e 58.

Figura 56: Erro ao realizar download

Figura 57: Placa desconectada

Figura 58: Placa desconectada

Para todas estas situações, recomendamos que o software seja fechado e reaberto, uma vez que a placa esteja corretamente ligada ao computador.

REFERÊNCIAS Alternativas de Baixo Custo para o uso da Robótica Educacional: Construção e Avaliação do Framework GoGo Board. Disponível em: . Acessado em: Abril de 2014. Larson, Jim. Babuino Command Reference. 2010. Rocha, Anderson Pires. Manual do Ambiente de Programação Blocos. 2011. D'Abreu, João Vilhete V.; Mirisola, Luiz G. B.; Ramos, Josué J. G.. Ambiente de Robótica Pedagógica com Br_GOGO e Computadores de Baixo Custo: Uma Contribuição para o Ensino Médio. Disponível em: . Acessado em: Abril de 2014. Ramos, Josué J G; d´Abreu, João Villhete Veigas; Oliveira, Alberto Arruda de; Alves, Lucas T.; Oliveira, Victot M.. Robótica Pedagógica de Baixo Custo - RPBC. Disponível em: . Acessado em: Abril de 2014.