Posts com Tag ‘sistemas’

Caro(a) Colega,

confira a edição especial da publicação Industrial Embedded Systems – 2014 Resource Guide.

Industrial Embedded Systems - 2014 Resource Guide

Aproveite! Abraço,

 

Henrique

consulte sempre um engenheiro eletrônico

Caro Colega,

como esse assunto despertou algum interesse, resolvi colar aqui o convite que recebi da Altera. Não é um curso ao vivo, mas é gratuito, com a vantagem de você poder assistir ao curso quando tiver tempo para isso.

Aproveite! Abraço!

Henrique

consulte sempre um engenheiro eletrônico

=====================================

How about finishing the year with online training to increase your FPGA design skills?
Altera offers the following free online technical training courses developed by experienced engineers and system architects for unparalleled insight into the fine points of FPGA design.
Course Title
Description
Learn how to use Altera’s Quartus® II software to optimize resource usage based on your design needs.
Learn about the new features in the latest release of Altera’s Quartus II software.
Learn the basic constructs of the OpenCL™ standard, and the Altera OpenCL design flow. In the hands-on exercises, you will write your own programs to run on both the CPU and the FPGA.
Learn how to implement a PCI Express® (PCIe®) design in Cyclone® V, Arria® V, and Stratix® V devices.
Learn how to build custom high-speed interfaces and protocols using the custom and low-latency PHY IP core in Altera’s Quartus II software.
 
Learn transceiver basics in one hour through this updated online training.
Learn how to build custom high-speed interfaces and protocols using the custom and low-latency PHY IP core in Altera’s Quartus II software.
To ensure that you receive future emails, please add learn@design.altera.com to your address book. Please note that this is a send-only mailbox; please do not send emails to it or reply. For questions or concerns about Altera products, visit the Altera Support Center, or Contact Altera to speak with an Altera representative.To update your email preferences or unsubscribe from Altera email updates and enewsletters, please click here.Copyright© 1995-2012 Altera Corporation, 101 Innovation Drive, San Jose, California 95134, USA
ALTERA, ARRIA, CYCLONE, HARDCOPY, MAX, MEGACORE, NIOS, QUARTUS & STRATIX are registered trademarks of Altera in the United States and other countries.

Caro Colega,

Nos segmentos anteriores da série Boas práticas para o desenvolvimento de software, foram apresentados: uma introdução ao assunto, onde é mostrada a necessidade de boas práticas como uma forma de melhorar a produtividade na geração e manutenção de software e de qualidade desse software gerado e a primeira parteonde é abordada a ideia de se desenvolver o software de forma estruturada, porém utilizando alguns métodos de encapsulamento de dados. 

 Nessa segunda parte vamos abordar mais alguns aspectos envolvendo ideias para organizar e melhorar o seu software. Aí vão mais algumas sugestões:

Cabeçalho de subrotinas:

Quando for escrever uma nova subrotina para o seu programa, é de grande ajuda você escrever um cabeçalho destacado, conforme pode-se ver na Figura 1, listando nos comentários o nome da subrotina, uma pequena descrição das operações que ela realiza, uma lista de variáveis de entrada, com descrição se necessário e uma descrição das variáveis de saída.

Rotina em C para escrita na E2PROM

Figura 1 – Exemplo de Rotina em C para escrita na E2PROM

Essa figura é um extrato da subrotina mostrada na primeira parte dessa série. As vantagens são óbvias. Quando no decorrer do desenvolvimento do programa você necessitar de  uma rotina que realiza determinada função, você pode conferir se entre as que você já escreveu tem alguma, só lendo a descrição do cabeçalho. Depois, esse esquema facilita a depuração durante uma eventual manutenção após um longo período. O destaque realizado em torno do cabeçalho, facilita encontrar as rotinas quando se vasculha o programa.

Escolher nomes significativos para variáveis e rotinas:

Dar nomes às variáveis, subrotinas, constantes, etc. que façam a relação dessas variáveis com sua função, destino, etc. No exemplo que temos na Figura 1:

  • vEscreveE2PROM(unsigned char nEndereço, unsigned char nDado)
  • bFlagDeErro = DESLIGA;
Na Figura 1, pode-se reparar que algumas variáveis estão escritas em letras maiúsculas, por exemplo, LIGA, DESLIGA, SDA e SCL.
No início do programa, foram definidas as constantes com esses nomes, SCL e SDA fazendo referência aos sinais de controle de uma EEPROM serial com comunicação por dois fios. Isso você pode conferir no extrato do programa exibido na Figura 2 abaixo.
Exemplo de como definir mnemonicamente as variáveis

Figura 2 – Exemplo de como definir algumas variáveis utilizando boas práticas para desenvolver software

 

Para auxiliar na compreensão você pode consultar a Figura 3, onde se vê as conexões entre a CPU e a EEPROM correspondentes a esse programa.

Conexões entre CPU e EEPROM

Figura 3 – Esquema Elétrico mostrando as conexões entre CPU e EEPROm

Na Figura 4,   está ilustrada a primeira página do manual de uma dessas EEPROMs.

EEPROM comunicação 2 fios

Figura 4: Exemplo de EEPROM serial com comunicação a 2 fios

Essas constantes também estão associadas a bits específicos de uma Port do microcontrolador. Nomear uma variável de SDA é bem mais inteligível do que P2_5, por exemplo (Port 2, bit 5). As constantes LIGA e DESLIGA foram definidas como ’1′ e ’0′ respectivamente. Isso tudo nos leva ao próximo tópico desse artigo: A polêmica notação húngara.

Notação Húngara

Segundo a definição do Wikipedia:

Notação Húngara, criada por Charles Simonyi, visa a facilitar o reconhecimento do tipo de variável num programa. O nome foi dado a partir de uma brincadeira comum entre os primeiros a conhecer a notação que a achavam estranha, fazendo o seguinte comentário: “É tão estranho que até parece húngaro”. Quando se confronta com a necessidade de dar um novo nome a uma variável num programa, o programador deve tomar alguns cuidados ao tomar essa decisão:

  • Nome mnemônico – é aquele que facilita a lembrança do significado pelo programador;
  • Nome sugestivo – é aquele em que outros podem ler o código;
  • Formato – é sempre visto como uma ideia estética, tendo sempre uma informação eficiente do programa teste;
  • Velocidade de decisão – não se pode perder muito tempo para ponderar um simples nome, pois não haverá tempo para editar e digitar nomes de variáveis longos.

A adoção deste critério de nomeação é bastante prática e intuitiva, sendo a ideia básica nomear todos os tipos de quantidades, visando-se a simplificar o entendimento do programa. Algumas vantagens deste método:

  • Os nomes em mnemônicos são utilizados num senso muito específico. Se alguém se lembrar da quantidade ou como os nomes foram construídos através de outros tipos, o nome poderá ser lido facilmente.
  • Os nomes sugestivos são muito bons. É capaz de se mapear qualquer nome dentro do seu tipo, tendo as informações necessárias para construir sua interface e utilizar de maneira correta sua quantidade.
  • Os nomes devem ser consistentes, porque eles são construídos pelas mesmas regras.
  • A decisão por um nome deve ser mecânica e rápida.
  • As expressões nos programas devem ser sugestivas, facilitando a leitura e acompanhamento do programa.

Com o objetivo de fazer listas intuitivas de se ler, os programas baseados na plataforma Windows utilizam a Notação húngara para gerar estas listas. As regras para se utilizar a Notação húngara são:

  • Os tipos definidos e/ou criados devem aparecer em letras maiúsculas;
  • constantes e “Macros” que vêm definidas em arquivos inclusos aparecem também em letras maiúsculas;
  • Funções e nomes estruturados começam com letras maiúsculas. Nenhuma marca abaixo são utilizadas para nomes, exceto para os casos que se encontrem nas duas regras anteriores;
  • Nomes de objetos começam com uma ou mais letras maiúsculas, indicando o tipo do objeto.

A tabela abaixo indica os tipos de indicadores mais utilizados na Notação húngara:

Nome Descrição
s String
sz Aponta o primeiro caracter da terminação zero da string
st Ponteiro da string, o primeiro byte é contado dos caracteres
h handle (título)
msg Message
fn function (usada com pointer)
c char (8 bits)
by unsigned char (byte or uchar – 8 bits)
n Int
b Boolean (verdadeiro ou falso)
f Flag (boolean, logical). Se qualificado é usado, pode descrever o estado verdadeiro do flag. Exceção às constantes.
u integer
w Word
ch Char, com texto ASCII
l long int (32 bits)
dw unsigned long int (dword – 32 bits)

==============

Essa notação é um pouco confusa e complicada e é alvo de muita polêmica sobre a sua eficiência e necessidade de uso. Na minha opinião e na minha experiência, essa notação, ou outra qualquer mais simplificada que você queira utilizar, facilita muito o reconhecimento das variáveis e funções, não só pelo nome,  como também o tipo, por exemplo bit, byte, inteiro, float, string, long, etc. Pense no assunto, experimente utilizar, eu tenho certeza que em pouco tempo você vai gostar do resultado final.

Por enquanto é só. Dê  a sua opinião, críticas e sugestões. Confira no próximo artigo:

Abraço!

 

Henrique

consulte sempre um engenheiro eletrônico

 

Licença Creative Commons Esta obra, “Boas práticas para o desenvolvimento de software – Algumas ideias de como organizar o seu software – II“, de Henrique Frank W. Puhlmann, foi licenciada sob uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 3.0 Não Adaptada.

ATENÇÃO:     Repassando o aviso do prof.  Alessandro Ferreira da Cunha:

Pessoal, bom dia! Tenho excelentes notícias....

Alessandro Ferreira da Cunha 22 de Junho de 2012 14:23
Pessoal, bom dia! Tenho excelentes notícias. Conseguimos fechar com a Texas e com o ESC Brasil a realização de um
HANDS ON gratuito de Linux Embarcado focado na placa Beagle Bone.O HANDS ON tem apenas 30 vagas disponíveis e terá a duração de 04
horas.Neste evento demonstraremos os primeiros passos para ambientação e uso
da Beaglebone com Linux.Para tanto, faremos os seguintes experimentos:

– Configuração do ambiente no desktop
– Preparação do hardware
– Preparativos para o 1o boot com Linux
– Testes com o Linux embarcado

As inscriçoes serão feitas através do site do ESCBrazil, através do
link abaixo:

http://www.escbrazil.com.br/

Acabei de conversar com os organizadores do evento, sobre o link de
inscrição, onde você deve preencher os seus dados para garantir a sua
vaga gratuita, e eles me informarão que o link está sendo montado e
assim que esta tarefa terminar ele será disponibilizado na página.

Como são apenas 30 vagas, acreditamos que estas irão se esgotar
rapidamente.

Portanto, se você tem interesse e disponibilidade para participar,
fique de olho na página do ESC Brazil e assim que o link for ao ar,
faça a sua inscrição.

Abraços e espero ver vocês por lá.

Alessandro Ferreira da Cunha
TECHtraininG – ENGENHARIA E TREINAMENTOS
alessandro@techtraining.eng.br
MSN –> afcunha01@gmail.com
SKYPE –> alessandroferreiradacunha
twitter –> @prof_afcunha
(11) 9536 – 3828
www.techtraining.eng.br

 ============================
Aproveite! Abraço!
Henrique
consulte sempre um engenheiro eletrônico

Caro(a) Colega,

neste artigo será abordada uma estratégia para ajudar a definir as especificações detalhadas de um projeto. O resultado dessa estratégia é um desenho em blocos, que  sintetiza as especificações iniciais das partes do projeto, explicitando a forma como essas partes se interconectam. Para isso eu vou inicialmente apresentar o detalhamento de um projeto, do qual eu participei, para ilustrar o resultado da aplicação das estratégias detalhadas na série Projetos de Desenvolvimento – Antes de começar. Depois serão apresentados os diagramas mencionados e alguns detalhamentos. O detalhamento do projeto é um pouco longo, mas vale a pena lê-lo, pois aí fica fácil o entendimento dos diagramas.

Abraço,

Henrique

consulte sempre um engenheiro eletrônico

============================

ID-100268634

Introdução

 

Na série de artigos técnicos Projetos de Desenvolvimento: Antes de começar  foi enfatizada  a necessidade e a importância de se realizar uma boa especificação inicial dos requisitos do nosso projeto e um esforço para se aprofundar no conhecimento relativo à matéria específica que envolve esse projeto. Para isso abordamos os seguintes temas:

  • A arte de extrair do cliente o que ele realmente quer e necessita: O que o Cliente quer?
  • A vantagem de se pesquisar os sistemas de patentes para adquirir conhecimento nos assuntos específicos e conhecer as soluções dadas pelos concorrentes:  Pesquise Patentes!
  • Os cuidados que se deve ter, se para o projeto houver a exigência de atender aos requisitos necessários de normas técnicas específicas: Consulte as Normas Técnicas!
  • Outras fontes para se adquirir o conhecimento necessário e extrair as informações que são necessárias:  Estude mais um pouco!

Neste artigo técnico apresentarei uma abordagem que considero muito eficiente para quando se inicia um projeto novo. Na minha opinião é fundamental, especialmente em projetos grandes, que se faça um desenho em blocos do projeto, destacando as principais partes, já definindo como que o projeto se conecta com outros equipamentos e recursos, inclusive indicando as principais partes e interfaces do conjunto. O desenho servirá de guia para a progressão do detalhamento e especificação das partes menores do projeto. Ele também facilita a divisão do trabalho em partes fechadas, que podem ser distribuídas para que outras equipes as façam, e que podem ser integradas com mais facilidade no final. O importante é que esse desenho seja sempre atualizado, se houver mudanças nas especificações, para que todos os membros da equipe trabalhem com a versão mais atualizada.

Antes de mostrar alguns desses diagramas, apresentarei a elaboração das especificações iniciais de um projeto bastante interessante, do qual eu participei. Trata-se da projeto de um protótipo de um “Sistema computacional embarcado para inspeção óptica automática de placas de circuito impresso”. Essas especificações iniciais são fruto da aplicação das ações abordadas na série Projetos de Desenvolvimento: Antes de começar. Nessas especificações também é apresentado um diagrama em blocos geral do sistema (Figura 3). Esse diagrama é uma síntese das especificações na forma de desenho, o que é o assunto deste artigo técnico.

Sistema computacional embarcado para inspeção óptica automática de placas de circuito impresso (2006)

 

Há dois tipos de sistemas de inspeção de circuitos eletrônicos: um para inspeção em linha de produção, capaz de verificar um número expressivo de placas por minuto e outro, que é um equipamento de inspeção manual, onde é inserida uma única placa e essa é inspecionada com auxílio de um operador. Por motivos de facilitar o projeto, escolhemos como objetivo do nosso trabalho o segundo tipo de equipamento.

Um exemplo de equipamento comercial (Figura 1):

Inspeçao_1a

 Figura 1: Sistema de inspeção automática da Testronics

O documento reproduzido a seguir contém as primeiras especificações do sistema. Essas especificações foram consolidadas a partir das seguintes ações realizadas logo no início do projeto:

  • A pesquisa de equipamentos comerciais semelhantes ao que se pretendia  projetar e estudo de suas especificações;
  • Pesquisa de patentes, que poderiam estar depositadas no Brasil e que poderiam nos impor algumas restrições ao projeto;
  • Muito estudo em cima dos elementos principais do sistema, tais como CCD linear, câmeras, lentes, iluminadores, sistemas de movimentação mecânica, transdutores lineares etc;
  • Elaboração das especificações técnicas do projeto de comum acordo com o nosso parceiro e interessado na fabricação do produto resultante do nosso projeto.

As especificações iniciais ficaram assim:

============================================================================================

 

PROPOSTA DE ARQUITETURA E OPERAÇÃO DO SISTEMA EMBARCADO DE CAPTURA DE IMAGENS

 

Objetivo

            Pretende-se descrever com palavras como será o funcionamento do sistema, especificando alguns detalhes da operação. Este documento traduz o que será implementado pela equipe do projeto.

 

Metodologia

            Inicialmente foi  realizado um projeto exploratório, definindo em blocos as funções do sistema e determinando as interfaces entre os diversos subsistemas. Em seguida serão realizadas as etapas abaixo:

  • A elaboração deste documento, para apreciação, críticas e sugestões dos demais membros da equipe do projeto. Este documento servirá para estabelecer claramente como o sistema irá funcionar e servir de guia para os desenvolvimentos posteriores.

Para facilitar  o desenvolvimento do projeto, foi decidido que o sistema terá dois grandes subsistemas, de forma a desacoplar as atividades, permitindo que as diversas equipes trabalhem em paralelo. Os subsistemas são os que seguem abaixo:

  • O “Sistema Embarcado de Captura de Imagens com DSP”, que será responsável pela movimentação das placas a serem inspecionadas, iluminação adequada, captura da imagem gerada pelo sistema e transferência para posterior análise no outro bloco do projeto;
  • Um Microcomputador de “Controle e Inspeção”, que comandará o sistema remotamente e  receberá a imagem capturada pelo “Sistema Embarcado” para tratamento e aplicação dos algoritmos de inspeção.

Este documento pretende descrever as especificações e descrição com alguns detalhes da operação somente do Sistema Embarcado. A descrição detalhada da operação do Microcomputador de controle e inspeção poderá ser acrescentado em momento oportuno pela equipe responsável por seu projeto.

  • O sistema embarcado deverá prever dois modos de operação: Um local, onde o sistema será capaz de realizar a sua função principal através de comandos por botoeiras do painel, de forma que possa ser testado de forma independente; outro remoto, onde o  microcomputador de controle e inspeção comandará e supervisionará o sistema;

Descrição do sistema embarcado

 O sistema embarcado de captura de imagens com DSP é um hardware eletroeletrônico e mecânico que comandará a operação local do sistema e responderá ao comando remoto de um microcomputador responsável pelo controle do sistema e pela execução dos algoritmos de inspeção. O sistema deverá gerar de forma adequada as imagens para posterior tratamento de inspeção. Este sistema é composto por um carro de deslocamento de placas, uma câmera digital do tipo “line-scan” para aquisição de imagem de alta precisão, desenvolvida pela equipe, e o sistema embarcado para pré-processamento da imagem e transferência ao microcomputador de inspeção através de uma interface USB (Universal Serial Bus). Na Figura 2 pode-se observar os principais elementos que deverão compor o projeto.

Sistema Proposto

Figura 2: Disposição dos principais elementos do sistema

Durante a execução de um ciclo completo de aquisição de imagem, o sistema embarcado realiza a seguinte seqüência de operações:

  • Inicia o movimento do carro de transporte da placa;
  • Monitora e contabiliza os pulsos gerados por uma régua de deslocamento linear;
  • Nos instantes pré-programados dispara o iluminador por um curto período de tempo (quando a iluminação for pulsada);
  • Durante o período de iluminação, realiza a captura da imagem;
  • Transfere a imagem capturada para a memória de massa;
  • Repete as operações acima até atingir o final de curso do movimento.

Após terminar a aquisição, o sistema disponibilizará uma imagem para fins de testes e manutenção numa interface SVGA. A imagem completa, eventualmente pré-tratada ficará disponível para o microcomputador de controle e inspeção.

A seguir serão listadas algumas especificações iniciais já determinadas pela equipe:

  • CCD (Charge Coupled Device) linear da Kodak modelo KLI-5001G de 5000 x 1 pixels;
  • A resolução do CCD é de 10 bits (1024 divisões) no máximo;
  • Tamanho máximo da placa que poderá ser inspecionada: 200 x 300 mm;
  • A abrangência do CCD se dá pela dimensão de 200 mm, de forma que esta dimensão seja capturada sem a necessidade de se movimentar o carro no eixo Y. A movimentação se dá apenas numa única direção, no eixo X.
  • A resolução da imagem em relação à placa a ser inspecionada é de 200 mm/ 5000 pixels, o que dá uma resolução de 0,04 mm máxima.
  • Uma interface para monitor SVGA (Super Vídeo Graphics Array) auxiliar onde será apresentada uma imagem para fins de manutenção e testes;
  • Uma interface JTAG por onde se poderá acoplar um microcomputador auxiliar para programar as EPLDs (Enhanced Programable Logic Device) do sistema;
  • A comunicação entre o sistema embarcado e o microcomputador de controle e inspeção se dará por uma interface USB 2.0, full speed, com capacidade de transferir no máximo 1 MBytes por segundo;
  • Cada pixel da imagem transmitida deverá ter 8 bits de resolução;
  • O sistema de DSP (Digital Signal Processor) a ser utilizado é o BF-561 da Analog Devices. Utilizaremos um kit de desenvolvimento como base e uma placa complementar será projetada para realizar as demais funções do sistema;
  • O sistema embarcado disporá de 512 MBytes de memória SDRAM (Synchronous Dinamic Random Access Memory) onde serão guardadas as imagens aquisitadas, tratadas e de referência.

Elementos que serão colocados no painel (console)

Serão montados no painel de operação os seguintes elementos que permitirão o comando local do sistema:

Botões e chaves rotativas

  1. Chave rotativa seccionadora: Para ligar ou desligar o sistema
  2. Chave rotativa de duas posições para seleção de variável de controle de operação:
    • Local / Manutenção
    • Remoto
  3. Botão “INICIAR” para iniciar um ciclo de aquisição de imagem (VERMELHO).
  4. Botão “PARAR” para interromper a operação a qualquer instante (VERDE).
  5. Botão “RESET” para que o sistema se movimente para a posição inicial (VERMELHO).
  6. Botão “AVANÇA” para que se realize o avanço manual do motor (VERMELHO).
  7. Botão “RECUA” para que se realize o recuo manual do motor (VERMELHO).
  8. Botão “EMERGÊNCIA” do tipo cogumelo, que desliga todo o sistema (VERMELHO).

Sinalizadores

  1. Lâmpada “LIGADO”, sinalizando que o sistema está ligado (VERDE).
  2. Lâmpada “EM OPERAÇÃO” para sinalizar que o sistema está em operação, coletando uma nova imagem (AMARELA).
  3. Lâmpada “FALHA”, sinalizando que ocorreu algum erro de operação (VERMELHA).
  4. Lâmpada “LOCAL”, sinalizando que está no modo local de operação (VERDE).
  5. Lâmpada “REMOTO”, sinalizando que está no modo remoto de operação (VERDE).
  6. Lâmpada “EM ESPERA”, sinalizando que o sistema está parado, aguardando comandos para operar. (VERDE).

Os elementos citados acima,  são os de interação com o operador e portanto ficam à vista, expostos no painel. Os elementos listados a seguir são os demais sinais e interfaces que completam o sistema:

Outros Elementos e Interfaces

Sensores de segurança do operador

  1. Sensor de detecção de “Tampa Fechada”, para que não se opere a máquina com a tampa aberta, expondo o operador a riscos desnecessários;
  2. Sensor de “Presença de placa” no suporte de placas a serem inspecionadas.

 

Sensores de segurança do sistema de movimentação

  1. Sensor de “Limite Inicial da Escala X”, que sinaliza eventual descontrole ou falha na parada de movimentação;
  2. Sensor de “Limite Final da Escala X”, que sinaliza eventual descontrole ou falha na parada de movimentação.

Os elementos a seguir são parte das interfaces internas de sinalização e controle do sistema embarcado:

Sinais da escala linear do eixo X

  1. Sinal “R” proveniente da escala, indicando a posição de “zero”, inicial da escala;
  2. Sinal “A” proveniente da escala, compondo com o sinal “B” dois trens de pulso em quadratura para indicar direção e posição;
  3. Sinal “B” proveniente da escala, compondo com o sinal “A” dois trens de pulso em quadratura para indicar direção e posição.

Sinais de controle e sinalização do sistema de movimentação do eixo X

  1. Sinal “Enable”, que habilita a atuação no motor;
  2. Sinal “Step”, que é um trem de pulsos para a movimentação do motor;
  3. Sinal “Direção”, que seleciona a direção do movimento;
  4. Sinal “Falha”, que o sistema de movimentação envia ao sistema embarcado para sinalizar alguma falha.

Sinais de controle do iluminador

  1. Sinal de “Strobe” 1, controle primário de disparo ou acendimento do iluminador;
  2. Sinal de “Strobe” 2, controle de disparo reserva;
  3. Sinal de “Strobe” 3, controle de disparo reserva;
  4. Sinal de “Strobe” 4, controle de disparo reserva.

Interfaces de operação remota e auxiliares para testes e manutenção

  1. Interface USB para comunicação direta com o Microcomputador de Controle e Inspeção. Através desta interface que o Sistema embarcado recebe os comandos remotos e transmite as imagens colhidas;
  2. Saída pra monitor de vídeo SVGA, para utilização como ferramenta de depuração e testes;
  3. Interface JTAG para que possam ser programadas as EPLDs do sistema;
  4. Seis LEDs vermelhos na placa para auxílio na depuração (indicação de códigos binários, quando necessário).

Diagrama da Arquitetura Proposta

Observe que no diagrama em blocos apresentado na Figura 3, são mostrados todos os sinais detalhados acima e como que eles estão interligados.

Scanner_Gerala

Figura 3: Diagrama geral do sistema de inspeção

Descrição da operação do sistema

O sistema proposto terá dois modos de operação, o LOCAL e o REMOTO, determinados pela posição da chave comutadora (2.). Descreveremos a seguir, com detalhes, as sequências de operações do sistema.

Inicialmente devemos ligar o sistema, comutando a chave seccionadora (1.) para “ON”. Se o sistema estiver em condições de operação, acenderá a lâmpada “LIGADO” (9.). Nesta situação são ligados o sistema embarcado em si e os sistemas acessórios, como o “driver” do motor e a fonte do iluminador, etc. Após ligar o sistema, ele funciona da seguinte forma, conforme a posição do comutador de modo de operação:

  • Se em modo LOCAL, passa para o modo local de operação, acendendo o sinaleiro “LOCAL”(12.) e o “EM ESPERA” (14.).
  • Se em modo REMOTO, passa para o modo remoto de operação, acendendo o sinaleiro “REMOTO” (13.) e o “EM ESPERA” (14.).

Nessa situação, se a tampa estiver abaixada, é permitido ao operador acionar o botão de “RESET” para que o sistema se posicione automaticamente na condição inicial de repouso, se acaso ainda não estiver nesta posição. Esta posição inicial é requisito para se iniciar qualquer ciclo completo de aquisição de imagem.

Em seguida vamos detalhar os modos de operação citados:

MODO LOCAL

Entra-se neste modo de operação quando se comuta a chave de seleção de modo de operação (2.) para “LOCAL”.

Condições seguras para comutação do modo de operação

  • A comutação só é aceita se a chave for comutada antes de se ligar o sistema, ou se o sistema estiver em estado de espera (sinaleiro “EM ESPERA” (14.) aceso).

 

Quando o sistema está no modo local de operação, acende-se o sinaleiro “LOCAL” (12.) do painel. Este modo de operação permite ao usuário manusear a placa a ser inspecionada, posicionando a guia de forma a facilitar a operação. Neste modo de operação o sistema permite o funcionamento dos seguintes botões e suas funções associadas:

  • Botão “RESET” (5.) para que o sistema se posicione automaticamente na condição inicial de repouso. Condições: A tampa do equipamento deve estar fechada para garantir a segurança do operador e o sistema está em estado de espera (sinaleiro “EM ESPERA” (14.) aceso);
  • Botão “AVANÇA” (6.) para que se avance manualmente o carro do sistema, de forma a testar o movimento e facilitar a colocação da placa a ser inspecionada. O movimento acontece enquanto se aciona o botão, parando quando o botão é liberado. O sinaleiro “EM ESPERA” desliga-se quando o carro estiver em movimento. Condição: o sistema está em estado de espera (sinaleiro “EM ESPERA” (14.) aceso);
  • Botão “RECUA” (7.) para que se recue o carro do sistema, de forma a testar o movimento e facilitar a colocação da placa a ser inspecionada. O movimento acontece enquanto se aciona o botão, parando quando o botão é liberado. O sinaleiro “EM ESPERA” desliga-se quando o carro estiver em movimento. Condição: o sistema está em estado de espera (sinaleiro “EM ESPERA” (14.) aceso);
  • Botão “INICIAR” (3.) para que o sistema inicie um ciclo completo de aquisição de imagem da placa a ser inspecionada no modo “LOCAL” apenas, apresentando a imagem na saída para monitor SVGA, porém sem enviá-lapara o microcomputador de controle e inspeção. A imagem fica à disposição do microcomputador. Durante a execução do ciclo completo, apaga-se o sinaleiro “EM ESPERA”(14.) e acende-se o sinaleiro “EM OPERAÇÂO” (10.).

 

 A transferência da imagem acontece só mediante solicitação remota. Condições:

  • A tampa do equipamento deve estar fechada para garantir a segurança do operador;
  • A placa a ser inspecionada estar corretamente posicionada;
  • O sistema se encontra na posição de repouso;
  •  O sistema está em estado de espera (sinaleiro “EM ESPERA” (14.) aceso);
  • Botão “PARAR” (4.) interrompe o movimento do sistema imediatamente. Após apertar este botão, o sistema para, desliga o sinaleiro “EM OPERAÇÃO” (10.) e liga o sinaleiro “EM ESPERA” (14.). Condição: o sistema está em execução do ciclo completo.
  • Botão de “EMERGÊNCIA” (8.) – desliga a energia de todos os sistemas do sistema embarcado.

MODO REMOTO

Entra-se neste modo de operação quando se comuta a chave de seleção de modo de operação (2.) para “REMOTO”.

Condições seguras para comutação do modo de operação

  • A comutação só é aceita se a chave for comutada antes de se ligar o sistema, ou se o sistema estiver em estado de espera (sinaleiro “EM ESPERA” (14.) aceso);
  • O sistema deve se encontrar na posição de repouso;
  • A tampa do sistema deve estar fechada;
  • Deve ter uma placa posicionada no carro para inspeção.

 

Quando o sistema está no modo remoto de operação, acende-se o sinaleiro “REMOTO” (13.) do painel. Neste modo de operação, o sistema embarcado recebe comandos do microcomputador de controle e inspeção. Neste modo de operação apenas o botão de “EMERGÊNCIA” funciona, os demais ficam desativados.

A comunicação entre o sistema embarcado e o microcomputador se dará por meio de um canal USB. Através dele, o microcomputador comandará a aquisição de imagens, selecionará eventuais algoritmos de pré-processamento para elas e coletará a imagem final para processamento dos algoritmos de inspeção. Futuramente, poderá ser estudada a possibilidade do sistema embarcado receber uma imagem padrão e realizar o “registro” da imagem coletada. (Colocar na mesma escala e posição.)

Nesta situação, quando estiver executando o ciclo completo, apaga-se o sinaleiro “EM ESPERA” (14.)  e acende-se o sinaleiro “EM OPERAÇÃO” (10.). Após terminar o ciclo, apaga-se o sinaleiro “EM OPERAÇÃO” e liga-se o sinaleiro “EM ESPERA”, o sistema disponibiliza a imagem na interface para monitor SVGA e fica aguardando o comando do microcomputador para enviar a imagem para a análise.

=============================================================================================

Detalhamento do diagrama geral do sistema

 

No especificação acima pode-se observar na Figura 3 o diagrama em blocos geral do sistema. Nesse diagrama são mostrados todos os sinais detalhados na especificação e como que esses sinais estão interligados. Ao longo do projeto do sistema de inspeção automática, com a definição dos componentes eletroeletrônicos e soluções viáveis, foi elaborado um novo diagrama de blocos, dessa vez detalhando bastante o bloco do “Sistema embarcado de captura de imagens com DSP“, como mostrado na Figura 4. Ainda é um desenho em blocos. Nesse ponto do projeto, esse desenho detalhado já é fruto do trabalho de projeto dos circuitos eletrônicos que implementam cada um desses blocos.

Scanner_detalhado

Figura 4: Detalhamento do Projeto

Para complementar, podemos conferir na Figura 5 o desenho de uma parte da solução elaborada para o projeto, detalhando as conexões elétricas do projeto final, destacando os equipamentos, botões, chaves, fontes, etc, e como o conjunto seria montado no gabinete escolhido para o projeto.

 

Scanner_detalhado_aindamais

Figura 5: Diagrama detalhado do sistema a nível das conexões elétricas

Concluindo… O esforço que se faz para desenhar o projeto como um todo, dividindo-o em blocos com funções e interfaces definidas é um passo importante para que o projeto possa progredir com mais tranquilidade. Esse desenho se transforma numa referência à qual se pode recorrer sempre que surgirem dúvidas. Esse desenho constitui um panorama, uma visão global do projeto. Porém, ele não deve ser imutável, podendo ser alterado, conforme o detalhamento do projeto assim o exigir. No final do projeto, esse desenho é parte importante da documentação, pois auxilia na compreensão do conjunto e facilita a eventual investigação de falhas e manutenção do sistema.

Licença Creative Commons
Esta obra, “Projetos de desenvolvimento: Primeiros passos“, de Henrique Frank W. Puhlmann, foi licenciada sob uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 3.0 Não Adaptada.