Metodologia de desenvolvi-mento de aplicações Organização: O desenvolvimento de aplicações para microprocessadores / microcontroladores Sistemas de desenvolvimento O ambiente de projecto da KEIL O gerador de formas de onda revisitado Co-projecto: Um exemplo na aquisição e visualização de sinais analógicos

O desenvolvimento de aplicações para Ps / Cs As ferramentas de apoio para o desenvolvimento de aplicações baseadas Ps ou em Cs são idênticas, mas é importante distinguir que: As aplicações baseadas em Ps estão normalmente associadas ao processamento de informação e o trabalho do projectista é sobretudo ao nível algorítmico As aplicações baseadas em Cs situam-se a maior parte das vezes ao nível do pormenor (muitas vezes mesmo ao bit), em estreita ligação com o hardware da aplicação

O ciclo de projecto As quatro principais etapas no projecto com Ps / Cs (tal como noutras áreas da electrónica) são as seguintes:

O ciclo de projecto (cont.) Em relação a este modelo de projecto, repare-se que: A mesma base (i.e. o mesmo hardware) pode ser reutilizado de aplicação para aplicação, muitas vezes sem qualquer alteração, o que não sucede com as soluções baseadas em hardware dedicado A maior flexibilidade (para acomodar modificações) é contra-balançada pela menor rapidez, face à alternativa da solução baseada em hardware dedicado Poderão co-existir ambas? (Cs, hardware dedicado)

O ciclo de projecto (cont.) Assumindo o pressuposto da reutilização do hardware, o ciclo de projecto costuma também representar-se da seguinte forma:

Regras básicas de projecto Existem dois factores principais que condicionam o sucesso do trabalho de projecto (e o sucesso não se restringe a colocar o sistema a funcionar...): A definição de uma organização modular que oriente o desenvolvimento das rotinas e que esteja em sintonia com as características da aplicação-alvo A escolha de uma linguagem com o nível de abstracção mais adequado à complexidade e características da aplicação-alvo (assembly? C?)

Regras básicas de projecto (cont.) Satisfeitos os factores principais, a maior parte das dificuldades no projecto ficam a dever-se à não observância de questões triviais, como por exemplo: Garantir a inicialização de uma área de stack Guardar o conteúdo de registos e posições de memória, no início de subrotinas ou atendimento a interrupções Analisar em detalhe a forma como são actuadas as flags Comentar de forma sucinta e concisa o código assembly

Regras básicas de projecto: Modularidade e hierarquia Aspectos principais a referir: Começar por esboçar um modelo organizativo da solução Identificar as relações de hierarquia e inter-dependência entre as várias rotinas que integram o modelo anterior Identificar e caracterizar os parâmetros de entrada e de saída associados a cada uma das rotinas Só então começar com o trabalho de escrita de código

Regras básicas de projecto: Escolha da linguagem A escolha a efectuar resume-se, na maior parte dos casos, às duas alternativas seguintes: Baixo nível de abstracção (assembly), sobretudo para pequenos segmentos de código, onde queremos ter um conhecimento preciso do que se passa ao nível temporal Alto nível de abstracção (C), em todos os restantes casos Em ambos os casos, no entanto, as ferramentas de apoio ao projecto têm um papel fundamental

Sistemas de desenvolvimento Os sistemas de apoio ao desenvolvimento de aplicações baseadas em Ps / Cs integram normalmente duas componentes principais: Aplicações (sobretudo para) Windows para controlar / observar o sistema-alvo: Correr uma rotina passo-a-passo, visualizar o conteúdos dos registos, etc. Uma ponta de emulação, para substituir o P / C no sistema-alvo, de forma a permitir realizar as operações anteriores

Sistemas comerciais de baixo custo: Ceibo

Aplicações do domínio público: ApBuilder 2.21

O ApBuilder 2.21 (cont.) Configuração do porto série num 80C51

O ApBuilder 2.21 (cont.) Porto série: Código ASM produzido pelo ApBuilder

O ApBuilder 2.21 (cont.) Descrição da instrução cjne:

O ambiente de projecto da KEIL Actividades correspondentes às primeiras duas etapas do ciclo de desenvolvimento: Criação dos ficheiros que integram a arquitectura modular Geração do código objecto (via compilador ou assembler) Ligar (link) os vários ficheiros de código objecto num único bloco Simular o funcionamento do código executável (para detectar e corrigir os erros, antes da implementação)

O ambiente de projecto da KEIL (cont.) A KEIL proporciona várias ferramentas para apoio a estas etapas, com destaque as seguintes: Compilador de C para código objecto (C51) Cross-assembler (A51) Linker (BL51) Gestor de bibliotecas de ficheiros (LIB51, library manager) Um ambiente de simulação / depuração (debugging), com a designação de dScope

O ambiente de projecto da KEIL (cont.) O ambiente integrado de desenvolvimento pode representar-se pela interacção entre as quatro primeiras ferramentas (numa aplicação interactiva designada por Vision) e o dScope:

O Vision As principais componentes do Vision são o editor, o gestor de projecto e o gerador do código objecto

O dScope Esta aplicação permite-nos realizar a depuração do código desenvolvido, mesmo sem hardware exterior

O dScope (cont.) Repare-se na percentagem de código que foi já executado (que importância tem esta indicação?) e na visualização mista (ASM+C)

O gerador de formas de onda revisitado Para comparar a complexidade relativa do desenvolvimento em C e em ASM, para um caso de complexidade reduzida (embora não trivial), revisitaremos o gerador de formas de onda O desenvolvimento da solução em C permite-nos avaliar estas duas abordagens quanto à facilidade do processo de projecto, bem como comparar o código objecto produzido nas duas situações

Atribuição de recursos (que modificações foram efectuadas, em relação à atribuição inicial?)

Organização das rotinas Mantendo uma organização semelhante à que foi anteriormente considerada, quando se efectuou o desenvolvimento em assembly, resultam quatro rotinas principais: A rotina principal propriamente dita (main) A geração das formas de onda O atraso que determina a frequência A gestão do sistema

O gerador de formas de onda no Vision

O gerador de formas de onda no dScope

Co-projecto na aquisição e visualização de sinais Encerraremos as metodologias de projecto com a consideração de um caso em que a mesma especificação funcional tanto pode ser implementada com um C como com hardware dedicado: Em hardware dedicado, proporcionando maior rapidez Com um C, ganhando em flexibilidade Ou mesmo com base numa solução mista (co-projecto)

Conceitos básicos de co-projecto O co-projecto procura identificar quais as partes da especificação funcional a implementar em: Hardware dedicado, que através de paralelismo (possibilidade de realizar várias operações em simultâneo) permite satisfazer requisitos de rapidez elevada Código residente em memória, mais lento (só uma instrução é executada de cada vez) mas com vantagens de outros tipos (custo, em última análise)

Conceitos básicos de co-projecto (cont.) O co-projecto está essencialmente associado a metodologias e ferramentas que tem por objectivo automatizar a actividade de projecto, sendo por isso vocacionado sobretudo para complexidade elevada Contudo, mesmo para exemplos relativamente simples é possível ilustrar as alternativas em confronto e as soluções de compromisso procuradas

Especificação do sistema Em termos gerais, o objectivo consiste em desenvolver um sistema para: Capturar (digitalizando e guardando em memória) sinais analógicos de muito baixa frequência Visualizar as formas de onda associadas a estes sinais, usando para o efeito um osciloscópio de baixo custo Porque é que a visualização directa não é possível? Quais são as dificuldades principais a enfrentar?

Especificação do sistema: Captura Principais especificações da captura: Pretende-se um, dois ou quatro sinais de entrada, com selecção por uma só tecla e indicação por três leds Memória total para aquisição: 32 Kbytes Pretende-se 10 alternativas para o tempo total de captura, entre 1 s e 24 h, com selecção por uma só tecla e com indicação através de 10 leds O fim da captura provoca a passagem à visualização

Especificação do sistema: Visualização Principais especificações da visualização: É o modo definido por omissão (o sistema deve passar a este modo após reset ou após completar a aquisição) A especificação do número de canais activos (1, 2 ou 4) vale também para a visualização A visualização de mais do que um sinal de entrada deve ser feita em faixas horizontais distintas do écran do osciloscópio

Representação visual

Representação visual e interface com o utilizador

A importância do co-projecto O que é que torna este exemplo particularmente interessante sob o ponto de vista do co-projecto? Seria possível a implementação da componente da especificação funcional correspondente à captura através de um C da família 80C51 a 12 MHz? E no que respeita à componente da especificação funcional que diz respeito à parte da visualização?

Implementação apenas com um C

Implementação apenas com um C(cont.) Apesar de não nos permitir satisfazer os requisitos de rapidez na visualização, deveríamos equacionar se seria admissível: Aceitar uma visualização menos confortável, o que permitiria aumentar o tempo entre operações consecutivas de escrita no conversor D/A? Reduzir o número de amostras por canal, para que diminuísse o número de operações de escrita no D/A por intervalo de tempo?

Implementação apenas com hardware dedicado

Implementação apenas com hardware dedicado (cont.) Apesar de permitir verificar todos os requisitos apresentados, esta implementação apresenta as desvantagens principais seguintes: Flexibilidade para permitir modificações posteriores, voluntariamente ou em resultado de erros de projecto Maior complexidade (exercício: representar o diagrama de transição de estados do controlador) Custo superior, a não ser em casos especiais (quais?)

Implementação mista

Implementação mista (cont.) Continuamos a poder satisfazer todos os requisitos da especificação, mas: A memória para armazenamento dos valores digitalizados terá agora que dispor de um duplo porto de acesso Se o controlo da visualização não for suficientemente simples para poder ser implementado num dispositivo programável de média complexidade,como é que esta alternativa de implementação se compara com a anterior?

Co-projecto: Conclusão O exemplo considerado continha apenas duas componentes funcionais, com características que tornavam simples a identificação das vantagens e desvantagens associadas à implementação por hardware dedicado ou código residente em memória Nos casos reais em que a metodologia de co-projecto tem aplicabilidade, a complexidade das situações requer o uso de ferramentas de apoio à decisão

Conclusão Objectivo principal do capítulo: Introduzir as metodologias de desenvolvimento de aplicações baseadas em microcontroladores e apresentar alguns exemplos concretos Pistas para a continuação do estudo: Projecto de “sistemas embutidos” (embedded systems) Modelação e síntese automática no co-projecto entre hardware e software