Microcontrolador tolerante a radiação espacial é lançado pela Atmel

Você já teve vontade de lançar seu projeto para o espaço? Bem, não é qualquer mortal que pode fazer isto devido aos custos, mas o apelo comercial de um microcontrolador que é capaz de suportar até mesmo radiações cósmicas é muito grande.
E provavelmente por isto a Atmel resolveu lançar uma linha de microcontroladores com estas características: o ATmegaS128. A Atmel é uma das empresas qualificadas pela ESCC, e isto garante um ponto positivo para esta nova linha de microcontroladores.
A Atmel garante que seu microcontrolador é capaz de suportar uma dose de ionização de 30 Krad (equivalente a 300 Gy no sistema internacional, ou seja, 300 Joules por quilo). Fora isto, o microcontrolador é compatível pino a pino com outros microcontroladores da Atmel, podendo ser programado através das ferramentas já disponibilizadas pela empresa. Com isto, a Atmel espera baratear projetos aero-espaciais.

Von Neumann X Harvard

Harvard Mark-I, primeiro computador a usar a arquitetura Harvard.

Há um bom tempo desejava falar um pouco sobre as diferentes arquiteturas de computadores, em especial a arquitetura Von Neumann e a Harvard. Às vezes ouvimos falar sobre estas arquiteturas, mas pouco sabemos sobre elas, ou quais os seus impactos em nossos projetos. Afinal de contas, o que são estas arquiteturas?
A primeira arquitetura que devemos falar é sobre a arquitetura Von Neumann¹, que recebeu este nome de seu criador, o matemático e pioneiro cientista da computação, John von Neumann. Ele teria feito um artigo intitulado First Draft of a Report on the EDVAC², onde ele descrevia uma máquina que, entre outras coisas, descrevia uma memória onde tanto dados quanto instruções eram armazenados. Esta se tornou a característica principal da arquitetura Von Neumann. Ou seja, nesta arquitetura, dados e instruções (código) são armazenados na mesma memória, pois há um compartilhamento do mesmo barramento. Isto permitia que alguns programas se atualizassem, por exemplo. No entanto, por compartilhar o mesmo barramento, uma instrução não poderia ser buscada na memória ao mesmo tempo que um dado, o que reduz o throughput (velocidade de transferência de dados) entre CPU e memória. Isto limita seriamente a velocidade de processamento quando a CPU precisa realizar um processamento baixo em grande quantidade de dados. Este problema acabou sendo conhecido como o gargalo de Von Neumann (Von Neumann bottleneck).
Em contrapartida, a arquitetura Harvard³ possui dois barramentos, um para dados e outro para instruções. Há várias vantagens nesta arquitetura e por isto ela é preferida em nossos dias. Em primeiro lugar, por separar dados de instruções, o problema do gargalo de Von Neumann é evitado. Não só isto, mas as memórias de dados e instruções podem ser de tipos diferentes (Flash, RAM), ter tamanhos diferentes (8, 16, 32 bits)... Uma limitação, no entanto, é que esta arquitetura não permite que o programa se atualize, ou que um programa seja executado a partir da memória de dados.
Embora tenhamos estas duas definições, na prática, o que temos hoje é uma variação de cada uma destas arquiteturas para contornar os problemas apresentados. Por exemplo, hoje se usa mais a arquitetura Harvard Modificada, que permite o acesso à memória de instruções como se fosse memória de dados. Aqui ela ainda se diferencia da arquitetura Von Neumann por fornecer caminhos distintos no acesso a estas memórias.
Vamos então agora dar uma olhada nos diagramas em bloco de alguns microcontroladores de cada arquitetura. O primeiro é o microcontrolador PIC18F4550⁴, que apresenta uma arquitetura Harvard. Observe que há um barramento de dados e outro de instruções:

Não são todos os blocos que acessam o barramento de instruções, e não é todos os blocos que acessam o barramento de dados. Agora compare com o microcontrolador MSP430F169⁵ da Texas, definido como seguindo a arquitetura Von Neumann⁶:

Observe que apesar de possuir dois barramentos, um de dados (MDB, memory data bus) e outro de endereços (MAB, memory address bus), todos os blocos possuem acesso a estes dois barramentos. Vemos portanto uma diferença na construção dos dois microcontroladores.
Na prática, a questão envolve velocidade de processamento. O programador provavelmente não verá diferenças entre as duas arquiteturas, mas há um caso onde esta diferença pode ser percebida: no acesso à memória de instruções. O programador que pretenda fazer atualização de seu firmware à distância, por exemplo, terá que buscar um microcontrolador cuja arquitetura seja ou Von Neumann ou Harvard Modificada. No caso de uma arquitetura Harvard Modificada, ele ainda terá que checar quais as formas apresentadas pelo microcontrolador para o acesso à memória de instruções.

Referências

1. Arquitetura Von Neumann na Wikipedia: http://en.wikipedia.org/wiki/Von_Neumann_architecture
2. Artigo original pode ser lido em http://qss.stanford.edu/~godfrey/vonNeumann/vnedvac.pdf.
3. Arquitetura Harvard: http://en.wikipedia.org/wiki/Harvard_architecture
4. Datasheet PIC18F4550: http://ww1.microchip.com/downloads/en/devicedoc/39632e.pdf 5. Datasheet MSP430F169: http://www.ti.com/lit/ds/symlink/msp430f169.pdf
6. Wiki Texas: http://en.wikibooks.org/wiki/Embedded_Systems/Texas_Instruments_MSP430_microcontrollers

MiWi: Criando redes MiWi com PIC18F4550

Depois de nossa série sobre o protocolo MiWi, chega a hora de colocar tudo em prática. Assim, vamos criar aqui um projeto de redes MiWi com o PIC. Vou selecionar o PIC18F4550, pois depois poderemos atualizar o projeto, adicionando o controle através da porta USB.
Se vocês perderam algum dos posts anteriores, podem acessá-los pela lista abaixo:
1- MiWi: Dispositivos e topologias de rede;
2- MiWi: Endereçamento;
3- MiWi: Relatórios de protocolo;
4- MiWi: Mensagens de Stack e Serviços
5- MiWi: Segurança
Como a biblioteca da Microchip para o MiWi foi desenvolvida recentemente, há ainda alguns bugs e também muitas atualizações. Ela é fornecida com o Microchip Application Libraries, e a última versão disponível agora, enquanto escrevo este artigo, é a versão de junho de 2011 (Stack MiWi 4.2). Quem estiver com sua versão desatualizada, é bom atualizar.

Hardware do projeto

Desenhamos o circuito do projeto no KiCad, que pode ser visto abaixo:

Criamos o componente MRF24J40MA, já que o KiCad não o possui. Você poderá obter todos os datasheets relacionados a este módulo no site da Microchip.
O módulo MRF24J40MA é o módulo que fará todo o trabalho de transmissão e recepção de pacotes. Você o controla via barramento SPI. Ele na verdade é um transceiver feito pela Microchip para os protocolos ZigBee ou MiWi... Mas como um transceiver, você poderá criar qualquer protocolo de comunicação com ele. O Stack MiWi não está no módulo, mas é implementado pelas bibliotecas da Microchip.
Para você ter uma visão geral dos registradores disponíveis deste módulo, procure pelo datasheet do circuito integrado principal dele, o MRF24J40. Há ainda uma versão deste módulo de maior alcance, chamado de MRF24J40MB.
A alimentação do módulo é de 3.3V. Para simplificar o desenho acima, não incluímos a fonte. Portanto, quando você for implementar este projeto, lembre-se de incluí-la.

Incluindo os arquivos do projeto

Vamos agora ao PCAD, e vamos criar um novo projeto com PICF4550. Os arquivos que devemos incluir são os arquivos abaixo:

Arquivo	Pasta
Console.c	\Microchip Solutions\Microchip\WirelessProtocols\
MSPI.c	\Microchip Solutions\Microchip\WirelessProtocols\
SymbolTime.c	\Microchip Solutions\Microchip\WirelessProtocols\
MiWi.c	\Microchip Solutions\Microchip\WirelessProtocols\MiWi\
MRF24J40.c	\Microchip Solutions\Microchip\Transceivers\MRF24J40\
MiWi.c	\Microchip Solutions\Microchip\WirelessProtocols\MiWi\

Os cabeçalhos relacionados com estes arquivos podem ser adicionados para facilitar a visualização. Por fim, devemos copiar três arquivos que serão necessários para o projeto: ConfigApp.h, HardwareProfile.h, SystemProfile.h. Para o projeto de um dispositivo End Device, nós vamos copiar estes arquivos do diretório Microchip Solutions\MiWi DE Demos\Node 2. Para Coordinators, devemos copiar estes arquivos do diretório Microchip Solutions\MiWi DE Demos\Node 1. São eles que conterão as configurações de rede do projeto, bem como o esquema de ligação deste projeto.
Assim que copiar estes arquivos para a pasta do projeto, inclua-os. Fazendo isto, vamos editar o arquivo HardwareProfile.h, para que ele reflita o nosso esquemático:

#ifndef _HARDWARE_PROFILE_H
    #define _HARDWARE_PROFILE_H
    
    #include "GenericTypeDefs.h"
    #include "ConfigApp.h"
    #include <p18cxxx.h>
    
    #define CLOCK_FREQ          48000000
    
    #define RFIF                INTCON3bits.INT2IF
    #define RFIE                INTCON3bits.INT2IE
    
    #define PHY_CS              LATCbits.LATC2
    #define PHY_CS_TRIS         TRISCbits.TRISC2
    #define RF_INT_PIN          PORTBbits.RB2
    #define RF_INT_TRIS         TRISBbits.TRISB2
    
    #define SPI_SDI             PORTBbits.RB0               
    #define SDI_TRIS            TRISBbits.TRISB0
    #define SPI_SDO             LATCbits.LATC7
    #define SDO_TRIS            TRISCbits.TRISC7
    #define SPI_SCK             LATBbits.LATB1
    #define SCK_TRIS            TRICBbits.TRISB1

    #define PHY_RESETn          LATCbits.LATC0
    #define PHY_RESETn_TRIS     TRISCbits.TRISC0
    #define PHY_WAKE            LATCbits.LATC1
    #define PHY_WAKE_TRIS       TRISCbits.TRISC1
    
    #define LED_1               PORTEbits.RE0
    #define LED_1_TRIS          TRISEbits.TRISE0
    #define LED_2               PORTEbits.RE1
    #define LED_2_TRIS          TRISEbits.TRISE1
    #define LED_3               PORTEbits.RE2
    #define LED_3_TRIS          TRISEbits.TRISE2

    #define TMRL                TMR0L
    
    #define TOOGLE(c)           c = ~c

#endif

Aqui nós definimos todas as ligações feitas com o módulo MRF24J40MA. Se alguma destas definições faltar, o compilador gerará erros. O clock e o registrador do timer usado também devem ser definidos aqui, para que o Stack MiWi possa fazer as temporizações corretamente. Portanto, você não poderá usar este timer.

Configurando o projeto

A configuração do projeto é feita no arquivo ConfigApp.h. Veja quais opções você poderá selecionar neste arquivo:

Configuração	Descrição
ENABLE_CONSOLE	Habilita a impressão de mensagens pela serial do microcontrolador. Comente esta definição, para desabilitá-la.
SIMPLE_EXAMPLE	Desabilita todas as funções mais avançadas do Stack. Insira esta definição no projeto, para habilitá-la.
ENABLE_NETWORK_FREEZER	Grava todos os dados mais importantes de uma conexão em memória não volátil, para rápido restabelecimento da rede. É necessário ter esta memória no projeto.
HARDWARE_SPI	Utiliza o módulo SPI nativo do microcontrolador para comunicação. Comentando-se esta definição, o Stack tentará emular uma SPI. Recomendável usar o SPI nativo.
PROTOCOL_P2P	Habilita a rede P2P. Não pode ser definido juntamente com PROTOCOL_MIWI
PROTOCOL_MIWI	Habilita a rede MiWi Mesh. Não pode ser definido juntamente com PROTOCOL_P2P
NWK_ROLE_COORDINATOR	Define o dispositivo como Coordinator. Não pode ser definido juntamente com NWK_ROLE_END_DEVICE.
NWK_ROLE_END_DEVICE	Define o dispositivo como End Device. Não pode ser definido juntamente com NWK_ROLE_COORDINATOR.
MRF24J40	Define que o módulo MRF24J40MA de 2.4GHz será usado. Não pode ser definido junto com outros transceivers.
MRF49XA	Define que o módulo subGHz MRF49XA da Microchip será usado. Não pode ser definido junto com outros transceivers.
MRF89XA	Define que o módulo subGHz MRF89XA da Microchip será usado. Não pode ser definido junto com outros transceivers.
MY_ADDRESS_LENGTH	Define o tamanho do endereço permanente do nó, em bytes.
EUI_0 - EUI_7	Esta é a definição do endereço EUI do módulo. Cada dígito é um byte do endereço.
TX_BUFFER_SIZE	Define o tamanho do buffer de transmissão.
RX_BUFFER_SIZE	Define o tamanho do buffer de recepção.
MY_PAN_ID	Define o PANID do dispositivo.
ADDITIONAL_NODE_ID_SIZE	Define o tamanho dos dados adicionais que serão anexados à requisição P2P. Estas são informações que os dispositivos querem compartilhar com outros pontos na conexão. Estes dados serão definidos pela aplicação.
CONNECTION_SIZE	Define o máximo de conexões P2P que este dispositivo permite ao mesmo tempo.
TARGET_SMALL	Remove algumas funcionalidades para diminuir o código gerado.
ENABLE_PA_LNA	Habilita o amplificador de potência em transceivers que o possuem.
ENABLE_HAND_SHAKE	Habilita o hand-shake antes da comunicação. Sem isto, os transceivers RF só poderão fazer broadcast, ou possuir o endereço de destino programado no firmware para comunicação com um dispositivo.
ENABLE_SLEEP	Permite que o dispositivo vá para o modo sleep e volte dele.
ENABLE_ED_SCAN	Habilita a detecção de energia, para descobrir qual o canal que possui menos ruído.
ENABLE_ACTIVE_SCAN	Habilita o Active Scan, para detectar as conexões atualmente existentes.
ENABLE_SECURITY	Habilita a encriptação de dados na transmissão.
ENABLE_INDIRECT_MESSAGE	Fará com que o dispositivo guarde mensagens para dispositivos que estão em modo sleep, até que eles retornem ao funcionamento normal.
ENABLE_BROADCAST	Fará com que o dispositivo envie broadcasts aos dispositivos em modo sleep, até que eles retornem ao funcionamento normal.
RFD_WAKEUP_INTERVAL	Define o intervalo de wakeup para dispositivos RFD em segundos. Esta definição no entanto não é utilizada pelos dispositivos RFD, mas pelos dispositivos FFD, para calcular seus vários timeouts.
ENABLE_FREQUENCY_AGILITY	Faz com que o dispositivo possa mudar de canal, quando houver uma súbita mudança no ruído.

Alterando o valor destas definições, você poderá configurar seu projeto de acordo com suas necessidades. É sempre bom dar uma olhada nestas configurações depois de copiar os arquivos.

Arquivo principal do projeto

No arquivo principal, você precisará definir algumas coisas também. Vamos ao esqueleto básico deste arquivo:

#include <stdio.h>
#include "GenericTypeDefs.h"
#include "Compiler.h"
#include "WirelessProtocols/MSPI.h"
#include "WirelessProtocols/MCHP_API.h"

#include "HardwareProfile.h"

#if ADDITIONAL_NODE_ID_SIZE > 0
 BYTE AdditionalNodeID[ADDITIONAL_NODE_ID_SIZE] = {0x01};
#endif

BYTE myChannel = 11;

#pragma config FOSC=HSPLL_HS
#pragma config CPUDIV=OSC1_PLL2
#pragma config PLLDIV=5
#pragma config USBDIV=2
#pragma config CCP2MX=ON
#pragma config WDT=OFF
#pragma config WDTPS=32768
#pragma config MCLRE=ON
#pragma config LVP=OFF
#pragma config VREGEN=ON
#pragma config IESO=OFF
#pragma config PWRT=ON
#pragma config BOR=OFF
#pragma config CP0=OFF
#pragma config CP1=OFF
#pragma config CP2=OFF
#pragma config CP3=OFF
#pragma config CPB=OFF
#pragma config CPD=OFF
#pragma config WRT0=OFF
#pragma config WRT1=OFF
#pragma config WRT2=OFF
#pragma config WRT3=OFF
#pragma config WRTB=OFF
#pragma config WRTC=OFF
#pragma config WRTD=OFF
#pragma config EBTR0=OFF
#pragma config EBTR1=OFF
#pragma config EBTR2=OFF
#pragma config EBTR3=OFF
#pragma config EBTRB=OFF
#pragma config DEBUG=ON
#pragma config XINST=ON

void UserInterruptHandler(void)
{
}              

void main(void)
{
 BYTE i=0xFF;
 
 RCON = 0x80;           // Habilita prioridades para interrupções
 ADCON0 = 0x00;
 ADCON1 = 0x0F;       // PORTA só como entradas e saídas digitais.
 CMCON = 0x07;        // Comparadores desligados.
 TRISA = 0xFF;
 TRISB = 0x05;
 TRISC = 0x00;
 PORTC = 0x06;
 TRISD = 0x00;
 PORTD = 0x00;
 TRISE = 0x07;
 PORTE = 0xFF;
 INTCON = 0x00;
 INTCON2 = 0x00;
 INTCON3 = 0x00;
 // Configura o módulo SPI
 SSPSTAT = 0xC0;
 SSPCON1 = 0x20;
 
 INTCONbits.GIEH = 1;
 RFIF = 0;               // Limpa o interrupt flag do chip.
 RFIE = 1;
 INTCON2bits.INTEDG2 = 0;

 MiApp_ProtocolInit(FALSE);
 if(MiApp_SetChannel(myChannel) == FALSE)
 {
  return;
 }
 MiApp_ConnectionMode(ENABLE_ALL_CONN);
 while((i = MiApp_EstablishConnection(0xFF, CONN_MODE_DIRECT)) == 0xFF);
 #ifdef ENABLE_DUMP
        DumpConnection(0xFF);
 #endif
 LED_2 = 1;
 for(;;)
 {
  if(MiApp_MessageAvailable())
  {
   // Aqui tratamos a mensagem recebida.
   MiApp_DiscardMessage();
  }
 }
}

O código acima é de um arquivo prinpipal para o projeto de dispositivo End Device. A diferença entre o End Device e o Coordinator é apenas a função main. Duas definições devem ser feitas no arquivo principal. A primeira é a definição da variável AdditionalNodeID, conforme pode ser visto acima. Os arquivos do Stack MiWi usam esta variável, portanto é necessário pelo menos definí-la. A segunda definição é a da função UserInterruptHandler. Esta função é chamada depois que a interrupção do MiWi for executada, e precisa também ser declarada, mesmo que nada seja feito ali.
Além destas declarações, você deverá ainda configurar o módulo SPI e habilitar a interrupção que você definiu para o módulo MRF24J40MA (o Stack não faz isto como acontece em outras bibliotecas Microchip). Feito isto, seu projeto está pronto para funcionar.
As diferenças existentes neste arquivo acima, para o projeto do Coordinator são poucas. Compare com o código abaixo (do Coordinator):

MiApp_ProtocolInit(FALSE);
 if(MiApp_SetChannel(myChannel) == FALSE)
 {
  return;
 }
 MiApp_ConnectionMode(ENABLE_ALL_CONN);
 MiApp_StartConnection(START_CONN_DIRECT, 10, 0);
 #ifdef ENABLE_DUMP
        DumpConnection(0xFF);
 #endif
 LED_2 = 1;
 for(;;)
 {
  if(MiApp_MessageAvailable())
  {
   MiApp_DiscardMessage();
  }
 }

Pode-se observar que o End Device usa a função MiApp_EstablishConnection, enquanto o Coordinator usa a função MiApp_StartConnection. Esta função inicializa a rede MiWi, e somente com uma rede estabelecida, é que os dispositivos End Device podem estabelecer conexões.

Conclusão

Terminamos aqui com a criação de um projeto MiWi. No nosso próximo post, iremos desvendar um pouco mais as rotinas usadas pelo Stack, para implementar a comunicação via protocolo MiWi, comparando com o que já foi escrito sobre o protocolo, aqui.

Microchip adota NetBeans como IDE

Nova IDE do MPLAB

A Texas Instruments já tinha adotado a plataforma Eclipse para a nova IDE de seu CodeWarrior, bem como outras fabricantes. Agora foi a vez da Microchip adotar uma IDE de código aberto. Recentemente ela lançou seu novo MPLAB X, que usa a ferramenta NetBeans. Eu ainda não tinha comentado sobre isto por que eu mesmo ainda não o instalei, mas como já encontrei pessoas comentando sobre a nova IDE, resolvi postar os pontos fortes do MPLAB X.
Ainda é uma versão modificada do NetBeans, tentando se aproximar da interface antiga do MPLAB. O Editor suporta um editor de código avançado, com a ferramenta de auto-completar e menus de contexto. A grande mudança está em um gerenciamento de projetos mais robusto, com suporte a múltiplos compiladores. Há algumas ferramentas que já fazem valer a pena atualizar a versão do MPLAB, como suporte à colaboração de times no desenvolvimento de código-fonte e ferramenta de rastreio de bugs.
O que foi mais bem integrado à nova IDE é a parte de depuração, o nosso debugger. A Microchip incluiu ampla documentação, tutoriais e projetos de exemplos para os chips de toda a linha.
A nova IDE pode ser instalada em vários sistemas operacionais, entre eles Windows, Linux e MacOS. Vários programadores também funcionam nesta IDE, como o MPLAB ICD 3, PICkit 3 e MPLAB REAL ICE.
O vídeo abaixo é fornecido pela Microchip, e apresenta a nova IDE:

Parece que as empresas de eletrônica estão procurando focar mais na produção de hardware, deixando software para quem já trabalha com isto. Esperamos que com a crescente adoção de ferramentas gratuitas, nossos fabricantes procurem também desenvolver ferramentas deste tipo. Afinal, o custo de um compilador é muito alto ainda.
No site da Microchip, há uma página dedicada à nova IDE, com vídeos e tutoriais: http://www.microchip.com/en_US/family/mplabx/index.html
Ali você poderá também fazer o download gratuito do software.

Páginas dinâmicas e AJAX no PIC.

Como eu havia dito em outro post, vou continuar nossa matéria sobre servidores Web no PIC. Nesta última parte, estarei descrevendo como você poderá inserir variáveis dinâmicas em suas páginas, bem como usar AJAX para atualizá-las.
Uma coisa que critico muito na plataforma da Microchip é a falta de documentação sobre este assunto. No entanto, se formos observar, há uma falta de documentação em toda nossa área. Espero assim preencher uma lacuna existente em nossa área.
Bem, se vocês acompanharam nossa última postagem, estarão com um servidor Web pronto para usar. Devemos agora criar nossas variáveis dinâmicas.

Criando variáveis dinâmicas na página Web

A Microchip definiu uma forma para a criação de variáveis dinâmicas em páginas Web. O padrão adotado é colocar o nome da variável entre dois '~'. Assim, poderíamos criar uma página web com o seguinte código HTML:

<html>
<head>
<title>Contagem de itens</title>
</head>
<body>
<p>Até o momento foram produzidos ~varItens~ itens.</p>
</body>
</html>

Criamos então aqui, uma página que irá mostrar o valor de uma variável chamada varItens. Esta página faz parte de um projeto que irá contar a quantidade de certos itens produzidos em uma indústria. Você deverá salvar esta página em seu diretório de páginas HTML, e então através do programa MPFS.exe (localizado na pasta [Raiz]\Microchip Solutions\Microchip\TCPIP Stack\Utilities), você irá gerar o código para ser incluído em seu programa. Se tudo ocorrer bem, o programa gerará o arquivo HTTPPrint.h com um novo protótipo de função:

void HTTPPrint_varItens(void);

Esta é a função que você deverá implementar para que sua variável dinâmica seja corretamente impressa no browser.
 
Implementando a função de impressão de variáveis dinâmicas
 
Vamos então criar uma função que imprime o valor de uma variável inteira chamada de quantItens. O nome da variável que escolhemos no código HTML não nos obriga a adotá-lo em parte alguma do código,pois escolhemos ali o nome da nossa função de impressão.
Assim, nossa função se chamará HTTPPrint_varItens. Eis o código-fonte desta função:

void HTTPPrint_varItens(void) 
{
   char tmpBuff[6];
   sprintf(tmpBuff, "%d", quantItens);
   TCPPutString(sktHTTP, (BYTE*)tmpBuff);
}

O que fiz foi basicamente converter o valor inteiro contido na variável quantItens para uma string, e usando a função TCPPutString, enviamos os dados para o browser que estiver visualizando a página. Tudo que for enviado através da função TCPPutString será exibido na posição que definimos no código HTML pela variável ~varItens~. Assim, não imprimimos apenas valores inteiros, mas também strings com mensagens para nossos usuários, códigos HTML para formatação de mensagens, etc...
 
Usando AJAX
 
Como implementar o AJAX em um servidor com PIC? A tarefa não é tão complexa assim. Imaginemos então que nosso projeto tenha que monitorar em tempo real a quantidade de itens na linha de produção, e que o browser deverá atualizar esta leitura sempre. Como implementar isto?
O primeiro passo será criar um arquivo que a página Web que criamos deverá buscar sempre com novas leituras. Este arquivo deverá ser um arquivo XML, e seu código pode ser visto abaixo:

<leitura> 
<contagem>~varItens~</contagem>
</leitura>

Observem que o elemento raiz é chamado de leitura, e os itens estão dentro de uma tag que chamamos de contagem.
Aqui neste arquivo, que vamos chamar de leitura.xml, nós colocamos novamente a impressão da variável varItens, que irá chamar a função que definimos acima. Novamente usamos o arquivo MPSF.exe para converter estes arquivos para um formato que possa ser utilizado pelo compilador.
Precisamos agora de algum mecanismo para buscar este arquivo no servidor e atualizar nossa página. Quem trabalha com Web poderia muito bem criar algumas funções em Javascript para usar o AJAX. No entanto, a Microchip já disponibiliza um arquivo Javascript que implementa o AJAX, e já faz o trabalho de atualizar periodicamente uma área de sua página Web.
O grande detalhe aqui é que a Microchip não divulgou muito isto. Não é um arquivo que está separado em uma pasta, somente esperando para ser usado. Este arquivo na verdade faz parte de um de seus exemplos, e pode ser encontrado na pasta [Raiz]\Microchip Solutions\TCPIP Demo App\WebPages2. O nome deste arquivo é mchp.js. Você deverá copiar este arquivo para sua pasta de páginas Web, e fazer algumas modificações no arquivo HTML que apresentamos acima:

<html>
<head>
<title>Contagem de itens</title>
<script type="text/javascript" src="mchp.js"></script>
<script type="text/javascript">
/* <![CDATA[ */
function displayItens(r)
{
  document.getElementById('leitura').innerHTML = getXMLValue(r, 'contagem');
}
function init()
{
  newAJAXCommand('leitura.xml', displayItens, true);
}
/* ]]> */
</script>
</head>
<body onload="init();">
<p>Até o momento foram produzidos <span id="leitura">~varItens~</span> itens.</p>
</body>
</html>

Em primeiro lugar, usamos um elemento SPAN para conter o valor a ser atualizado. Desta forma, limitamos a área onde será atualizada. É importante definir um ID para este SPAN, pois através deste localizaremos este elemento.
Definimos também a propriedade onload do elemento BODY. Quando a página carregar, ela irá invocar a função nesta propriedade. Vemos também que o código agora inclui dois scripts javascript: um é nosso arquivo mhcp.js, o outro é o nosso código.
Este nosso código simplesmente invoca a função newAJAXCommand, que faz todo o trabalho. O primeiro parâmetro desta função é o nome do arquivo que ela irá buscar no servidor. No nosso caso, é o arquivo leitura.xml que criamos anteriormente. O segundo parâmetro é o nome da função que será chamada, quando o arquivo for recebido. Criamos a função displayItens para este propósito, e por isto fornecemos este nome para a função. O terceiro parâmetro indica se você deseja repetir este chamado periodicamente, ou se este será um chamado apenas. No nosso caso, como desejamos uma leitura em tempo real, deixamos o valor como true. Esta função permite ainda um quarto parâmetro, que não vamos usar. Este parâmetro te permite enviar outras variáveis via POST para seu servidor.
Enviando o comando, o seu servidor responderá, enviando o arquivo leitura.xml. Quando recebermos o arquivo, ele será processado pela função que você passou como parâmetro para a função newAJAXCommand. Ela deve ter um parâmetro, que é o objeto XML que recebemos. Assim, para obtermos um item deste objeto, usamos a função getXMLValue. Ela recebe dois parâmetros. O primeiro, é o objeto XML que desejamos processar. Passe o objeto que recebemos como resposta. O segundo parâmetro é a tag no arquivo XML, que desejamos obter do arquivo. Como vocês podem se lembrar, colocamos a leitura dentro de uma tag contagem. Assim, passamos isto como parâmetro. Atribuímos então este valor à propriedade innerHTML do nosso SPAN, e pronto! Nosso valor estará sendo atualizado o tempo inteiro.
 
Conclusão
 
Temos então nosso servidor Web no PIC, utilizando variáveis dinâmicas e AJAX. A partir deste exemplo muitas outras adaptações poderão ser feitas, para atender aos requerimentos de cada projeto.

Criando um servidor Web no PIC

Olá, pessoal. Muito tempo sem postar por aqui...
Bem, estive ocupado em meu serviço tentando descobrir como criar um servidor Web usando os microcontroladores da família PIC. O grande lance destes microcontroladores é que a Microchip já fornece gratuitamente as bibliotecas necessárias para fazer isto. A questão é que não é muito simples de se configurar, sem muita documentação sobre isto. Por isto resolvi fazer uma descrição sobre este tema aqui.

Preparando terreno

Para que todos possam entender como se configura este projeto a partir do zero, resolvi detalhar todo o processo a partir do download dos arquivos necessários, no site da Microchip.
Assim, o primeiro passo é fazer o download, para quem ainda não fez, do MPLAB, que é a IDE para desenvolvimento de projetos no PIC. Para mim, este é um passo fundamental, já que através do MPLAB, você configura e depura projetos com o PIC muito facilmente. O link para o download do MPLAB (última versão), está aqui:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002

Mas este não será o único download no site da Microchip. É importante também fazer o download de algum compilador C deste fabricante. Como este compilador dependerá do microcontrolador que você irá usar, então haverá escolhas diferentes aqui. Como exemplo, irei usar o compilador C18. A página abaixo possui um link para os vários compiladores disponíveis:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en534868&page=wwwCompilers

Pode-se fazer o download da versão lite destes compiladores, que são versões que não usam todas as otimizações do compilador versão full. Para mim está de bom tamanho para fazer este tipo de desenvolvimento, já que estes compiladores costumam ser muito caros para hobistas.
Tendo feito o download do compilador, resta agora fazer o download das bibliotecas da Microchip para TCP/IP e outros. Isto pode ser feito no link abaixo:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784

Muito bem, terminamos com as etapas de downloads... Agora vamos para a parte de instalação, que não é muito complicada. Só para garantir que tudo dará certo, vamos instalar o MPLAB primeiro, o C18 depois e por fim as bibliotecas da Microchip. Não tenho nenhuma observação a fazer aqui, embora eu recomende que deixe que as instalações sejam feitas na raiz da unidade C, para diminuir o caminho a ser incluido nos projetos. Agora estamos prontos para iniciar nosso projeto.

Iniciando o projeto

Quando procurei saber como iniciar um projeto de servidor HTTP no PIC, encontrei várias sugestões me indicando o projeto TCPIP Demo App, que é instalado junto com as bibliotecas da Microchip. Pessoalmente não gostei muito disto, pois o projeto por se tratar de uma demonstração, foi feito para incluir vários tipos de demonstração. Acho que não é necessário copiar todos os arquivos desta pasta. Os arquivos que são necessários para o projeto são os arquivos TCPIPConfig.h e HardwareProfile.h. Através destes arquivos, você poderá configurar seu projeto. Você precisará mudar manualmente o arquivo HardwareProfile.h.
Eu por exemplo tenho aqui uma placa Explorer16BR, da Mosaico. Todo mundo poderia achar que pelo fato de haver uma definição EXPLORER_16 neste arquivo, bastaria habilitá-la para que tudo funcione perfeitamente, certo? Bem, a verdade é que a Mosaico andou alterando alguns pinos nesta placa, e entre eles está justamente o pino de habilitação do Driver Ethernet. Portanto, se alguém estiver usando esta placa, procure pela definição

#else // SPI1 for all other processors
 #define ENC_CS_TRIS (TRISDbits.TRISD14)
 #define ENC_CS_IO (LATDbits.LATD14)

E altere para:

#else // SPI1 for all other processors
 #define ENC_CS_TRIS (TRISCbits.TRISC4)
 #define ENC_CS_IO (LATCbits.LATC4)

Há também a opção de se criar o arquivo do zero. Neste caso, a pessoa deve criar algumas definições obrigatórias neste arquivo, como está abaixo:

#ifndef __HARDWARE_PROFILE_H
#define __HARDWARE_PROFILE_H

#include "GenericTypeDefs.h"
#include "Compiler.h"

// Define os fusíveis de configuração (apenas uma vez)
#if defined(THIS_IS_STACK_APPLICATION)
 #if defined(__18CXX)
  #if defined(__EXTENDED18__)
   #pragma config XINST=ON
  #elif !defined(HI_TECH_C)
   #pragma config XINST=OFF
  #endif
  
  #pragma config WDT=OFF, FOSC2=ON, FOSC=HSPLL, ETHLED=ON

 #endif
#endif // Previne a definição de mais de uma vez dos mesmos fusíveis

// Valor da frequência de clock.
// Este valor é usado para calcular o valor de Tick Counter
#define GetSystemClock()      (41666667ul)      // Hz
#define GetInstructionClock() (GetSystemClock()/4)
#define GetPeripheralClock()  GetInstructionClock()

No caso, as definições que devem ser feitas são as definições de clock do sistema. Você precisa verificar qual as configurações de frequência você está usando, para criar estas definições.
Feito isto, podemos agora configurar a parte de TCP/IP. Para isto, a Microchip desenvolveu um executável que faz toda a configuração para nós. Este executável se encontra na pasta:
[Diretório instalado]\Microchip Solutions\Microchip\TCPIP Stack\Utilities

E o executável se chama TCPIPConfig.exe. Execute ele e forneça o caminho para seu projeto. Não se esqueça de marcar a opção Show Advanced Settings, para podermos configurar nosso projeto nos mínimos detalhes. Na próxima tela teremos várias opções de projeto:

Selecionaremos apenas Web Server. Selecionando Next, teremos várias opções de códigos de exemplo. Não iremos selecionar nenhuma destas opções aqui. Clicando-se novamente em Next, teremos uma seleção de módulos:

Aqui selecionamos ICMP Client, ICMP Server e o NetBIOS Name Service. Os dois ICMP são necessários para que a aplicação possa fazer PING em computadores e para que ela possa também responder a este comando, muito útil para verificar a conectividade de dispositivos. O NetBIOS Name Service será importante para que você possa acessar seu dispositivo pelo Browser digitando o nome deste dispositivo na barra de endereços.
É na próxima tela que você configurará o endereço IP de seu projeto, nome do dispositivo, máscara de sub-rede, endereço MAC, etc...

Configure de forma que o dispositivo seja reconhecido em sua rede. Assim que isto for feito, clique em Next, e você será perguntado sobre qual biblioteca HTTP você pretende usar em seu projeto.

Vamos usar o HTTP2, pois ele traz inúmeras vantagens, como a possibilidade de usar métodos POST em formulários e o uso de variáveis dinâmicas. Feito isto, na próxima tela temos a seleção de configurações da biblioteca:

Como é um teste simples, vamos habilitar apenas os métodos POST. A página inicial será a página index.htm, e permitiremos apenas duas conecções por vez. Na próxima tela temos a seleção do sistema de arquivos, mas o HTTP2 da Microchip possibilita apenas o uso do sistema de arquivos MPFS2. Depois desta seleção, podemos escolher onde os arquivos serão gravados. No meu projeto, preferi salvar os arquivos dentro da Flash de programa do microcontrolador, que tinha espaço suficiente para todos os arquivos. Outras opções são:

O próximo passo é o mais complicado. Neste passo, você determinará a quantidade de memória usada para cada conecção.

Como não usamos nenhum outro tipo de conecção, determinaremos memória apenas para o HTTP_SERVER. Verifique se os outros tipos de Sockets estão com seu Count diferente de 0. O Count determina quantas conecções daquele tipo existirão. Como só temos duas conecções HTTP, só neste tipo de Socket é que deveremos ter um valor diferente de 0. A próxima tela permite você escolher quantas conecções UDP sua aplicação terá, e finalmente você poderá concluir esta configuração. O programa vai sobreescrever os valores disponíveis no seu arquivo TCPIPConfig.h. Estamos prontos para dar início a nosso projeto.

Arquivo principal do projeto

O arquivo principal do projeto deverá seguir alguns procedimentos básicos. O primeiro é que ele deve trazer a seguinte definição:

#define THIS_IS_STACK_APPLICATION

Isto indicará ao compilador qual é o arquivo principal. O segundo passo é que sua aplicação deverá definir uma instância da estrutura APP_CONFIG chamada de AppConfig. Esta estrutura contém as configurações de TCP/IP do projeto. Adicione a linha:

APP_CONFIG AppConfig;

Esta será uma variável global.
Nós temos também que definir o tratamento de interrupções de tempo, pois o Stack TCP/IP da Microchip usa os timers para o gerador de ticks. O tratamento de interrupção pode ser feito através do seguinte código:

#pragma interruptlow LowISR
void LowISR(void)
{
 TickUpdate();
}
 
#pragma interruptlow HighISR
void HighISR(void)
{
}
 
#pragma code lowVector=0x18
void LowVector(void){_asm goto LowISR _endasm}
#pragma code highVector=0x8
void HighVector(void){_asm goto HighISR _endasm}
#pragma code // Volta para a seção padrão de código

Para um servidor HTTP, as funções de tratamento de mensagens GET e POST (quando habilitadas) serão chamadas. Mas as bibliotecas da Microchip deixam a definição destas funções a cargo da aplicação, para que o programador trate destas mensagens da forma que ele deseja. Como estamos no início do projeto e a intenção é apenas gerar um servidor sem formulários no começo, vamos definir funções que não fazem nenhum tratamento:

HTTP_IO_RESULT HTTPExecuteGet(void)
{
  return HTTP_IO_DONE;
}

HTTP_IO_RESULT HTTPExecutePost(void) 
{
  return HTTP_IO_DONE;
}

Retornando HTTP_IO_DONE em ambas funções, dizemos às bibliotecas TCP/IP da microchip que o tratamento destas funções foi bem-sucedido, o que não deixa de ser verdade.
Como antes criamos uma instância da estrutura APP_CONFIG, precisamos agora preenchê-la com os dados necessários à aplicação. Os detalhes desta função podem ser vistos no programa de demonstração da Microchip, mas para facilitar esta tarefa, estarei colocando a função que criei aqui:

static ROM BYTE SerializedMACAddress[6] = {MY_DEFAULT_MAC_BYTE1, MY_DEFAULT_MAC_BYTE2, MY_DEFAULT_MAC_BYTE3, MY_DEFAULT_MAC_BYTE4, MY_DEFAULT_MAC_BYTE5, MY_DEFAULT_MAC_BYTE6};

static void InitAppConfig(void)
{
 AppConfig.Flags.bIsDHCPEnabled = TRUE;
 AppConfig.Flags.bInConfigMode = TRUE;
 memcpypgm2ram((void*)&AppConfig.MyMACAddr, (ROM void*)SerializedMACAddress, sizeof(AppConfig.MyMACAddr));
 AppConfig.MyIPAddr.Val = MY_DEFAULT_IP_ADDR_BYTE1 |  MY_DEFAULT_IP_ADDR_BYTE2<<8ul | MY_DEFAULT_IP_ADDR_BYTE3<<16ul | MY_DEFAULT_IP_ADDR_BYTE4<<24ul; AppConfig.DefaultIPAddr.Val = AppConfig.MyIPAddr.Val; AppConfig.MyMask.Val = MY_DEFAULT_MASK_BYTE1 | MY_DEFAULT_MASK_BYTE2<<8ul | MY_DEFAULT_MASK_BYTE3<<16ul | MY_DEFAULT_MASK_BYTE4<<24ul; AppConfig.DefaultMask.Val = AppConfig.MyMask.Val; AppConfig.MyGateway.Val = MY_DEFAULT_GATE_BYTE1 | MY_DEFAULT_GATE_BYTE2<<8ul | MY_DEFAULT_GATE_BYTE3<<16ul | MY_DEFAULT_GATE_BYTE4<<24ul; AppConfig.PrimaryDNSServer.Val = MY_DEFAULT_PRIMARY_DNS_BYTE1 | MY_DEFAULT_PRIMARY_DNS_BYTE2<<8ul | MY_DEFAULT_PRIMARY_DNS_BYTE3<<16ul | MY_DEFAULT_PRIMARY_DNS_BYTE4<<24ul; AppConfig.SecondaryDNSServer.Val = MY_DEFAULT_SECONDARY_DNS_BYTE1 | MY_DEFAULT_SECONDARY_DNS_BYTE2<<8ul | MY_DEFAULT_SECONDARY_DNS_BYTE3<<16ul | MY_DEFAULT_SECONDARY_DNS_BYTE4<<24ul; memcpypgm2ram(AppConfig.NetBIOSName, (ROM void*)MY_DEFAULT_HOST_NAME, 16); FormatNetBIOSName(AppConfig.NetBIOSName);
}

Por fim, nossa função main. Aqui há algumas observações a se fazer... As funções de inicialização do protocolo devem seguir uma ordem para serem executadas, pois do contrário o nosso servidor não funcionará. A ordem é a seguinte:

InitAppConfig();
TickInit();
MPFSInit();
StackInit();

O loop principal de seu programa deve executar estas duas funções:

StackTask();
StackApplications();

São estas as funções que devem ser usadas no seu projeto.

Configurando o projeto

Devemos incluir os arquivos para o projeto. Antes disto, devemos configurar o projeto para que inclua os cabeçalhos da Microchip na hora de compilar. Vamos ao menu Project, Build Options... Em Directories, clicando no menu Drop Down, selecionamos a opção Include Search Path. Vamos incluir aqui o diretório do projeto ".", o diretório de includes da Microchip Solutions, e o diretório de includes do C18. Em Library Search Path incluiremos também o diretório de livrarias do C18. Feito isto, estamos prontos para incluir os arquivos do projeto.
Para compilar o projeto, precisamos incluir os seguintes arquivos: ARP.c, Delay.c, DNS.c, ENC28J60.c, Helpers.c, HTTP2.c, ICMP.c, IP.c, MPFS2.c, NBNS.c, StackTsk.c, TCP.c, Tick.c, UDP.c. Agora nos resta criar os arquivos html para o servidor web.

Arquivos do servidor

Na sua pasta de projeto, crie uma pasta para guardar os arquivos html do servidor. É importante criar o arquivo index.htm que nós colocamos antes como o arquivo inicial do servidor. Neste primeiro passo, vamos criar apenas arquivos estáticos.
Assim que os arquivos forem criados, poderemos voltar na pasta Utilities onde encontramos o executável de configuração de TCP/IP. Agora vamos executar o programa MPFS2.exe.

Este programa irá converter os arquivos da pasta que você indicar para o sistema de arquivos MPFS. Como desejamos gravar na memória de programa do PIC, iremos converter nossos arquivos em um arquivo .c, que deverá ser incluído também no projeto. Assim que você clicar Generate, dois arquivos serão criados na pasta de projeto que você especificou. Depois disto, inclua o arquivo HTTPPrint.h que o programa gerar.
Pronto! Nosso projeto está completo e poderá ser compilado.

Voltaremos a falar sobre este tema posteriormente, explicando como usar formulários e variáveis dinâmicas. Por fim, ensinaremos a usar AJAX com nosso servidor web.

Microcontroladores AVR

Bem, depois de algum tempo sem postagens, resolvi dar continuidade à área de eletrônica, falando um pouco sobre microcontroladores. Hoje vou me dedicar a descrever um pouco dos microcontroladores AVR da Atmel, já que estou fazendo uma análise destes.
A arquitetura destes microcontroladores foi desenvolvida na Noruega, por dois estudantes: Alf-Egil Bogen e Vegard Wollan. Até onde as informações oficiais vão, o nome AVR não parece significar nada.
Os AVR são microcontroladores RISC, e por sinal são bastante rápidos: algumas instruções são executadas com um ciclo de máquina. Em processadores funcionando a 1MHz, teríamos então até 1 MIPS. Por falar em clock, estes microcontroladores aceitam cristais até 20MHz, em alguns modelos até 32MHz.
Para quem está acostumado com os microcontroladores PIC, acredito que poderia fazer um paralelo meio grosseiro, mesmo porque meu conhecimento sobre os microcontroladores da Atmel ainda é pequeno. Mas A correspondência entre as famílias seria mais ou menos assim: microcontroladores pequenos da Microchip, como o PIC12F e similares, corresponderia aos tinyAVR, enquanto que microcontroladores maiores como o PIC16F ou PIC18F seriam equivalentes aos megaAVR. Os ATxmega são mais avançados, e dependendo do modelo podem ser microcontroladores de 16 ou 8 bits.
Talvez o que chama a atenção de muitas pessoas, e certamente me chamou a atenção, é que as ferramentas de desenvolvimento para este microcontrolador são gratuítas. O AVR pelo visto foi desenvolvido desde o princípio para ser programado em C (diferente das primeiras versões do PIC). Você por exemplo pode fazer o download do AVR Studio, que é o ambiente de desenvolvimento para AVR disponibilizado pela Atmel, e depois fazer o download do WinAVR, que é o compilador C para AVR gratuíto. Desta forma, você não precisa se preocupar com licenças de software ou até mesmo de procurar uma versão crackeada do compilador por aí.
Até mesmo para fazer a simulação de seu projeto, você possui mais vantagens. Levando-se em conta que você pretende desenvolver dentro da legalidade, e resolva comprar softwares de simulação como o Proteus da Labcenter, você irá desembolsar menos em comparação com o desenvolvedor de PIC. Isto por que a Labcenter disponibiliza seu software para todos os PICs (Proteus VSM for PIC Bundle 8/16bit) por 1599 dólares na data deste post, enquanto que para todos os AVRs (Proteus VSM for AVR), 479 dólares já é o suficiente. É claro que para o desenvolvedor para microcontroladores PIC, há sempre a opção de escolher o software limitado a uma família, como o Proteus que simula apenas PIC18. É claro que isto não é algo vantajoso para um desenvolvedor, pois suas opções de projeto se tornam limitadas também.
Por fim, como as ferramentas de desenvolvimento são gratuítas, esta linha de microcontroladores tem atraído a atenção de muitos desenvolvedores de software livre. Isto quer dizer que você poderá encontrar muitas ferramentas gratuítas para estes microcontroladores.

Referências:

Site da Atmel sobre o AVR: http://atmel.com/products/avr/default.asp?family_id=607
Ferramentas de desenvolvimento da Atmel: http://atmel.com/dyn/products/tools.asp?family_id=607
Download do WinAVR: http://winavr.sourceforge.net/
Lista de preços do Proteus: http://www.labcenter.com/ordering/cprices.cfm
Comunidade de desenvolvimento do AVR: http://www.avrfreaks.net/

Processadores, microcontroladores, FPGA’s, ASIC’s, DSP’s e DSC’s: o que são?

É incrível como a informática e a eletrônica avançaram nos últimos anos. Cada vez mais temos capacidades maiores de processamento e integração, possibilitando as empresas a criarem a mais diversa gama de componentes eletrônicos. Talvez por este motivo, cada vez mais nossa vida depende destes “novos” componentes eletrônicos. No-breaks, máquinas de lavar, calculadoras, televisores, câmeras e vários outros dispositivos eletrônicos contém algum tipo de processamento realizado tanto por microcontroladores, DSP’s ou FPGA’s. Foi-se o tempo que poderíamos agrupar todos estes sob o simples nome de processador.

Como vamos discutir bastante sobre estes componentes e como muitos ainda não sabem diferenciar um de outro, achei interessante abordar esta questão antes de aprofundarmos mais em cada um destes itens. Farei então um rápido comentário sobre estes tipos de tecnologias, para que nossos leitores possam entender um pouco de cada uma delas. Posteriormente, aprofundaremos mais sobre cada uma delas.

Iniciamos então com os microprocessadores, que foram os primeiros hardwares dedicados ao processamento e execução de instruções. Estes foram criados no início dos anos 70 e eram usados basicamente em calculadoras. Mais tarde foram sendo usados em outras áreas, como terminais, impressoras, etc. Geralmente considerado como o primeiro processador desenvolvido, o Intel 4004, processador de 4 bits, teve sua primeira propaganda em novembro de 1971, e executava instruções com um clock de 740kHz. Hoje em dia temos clocks próximos de 4 GHz, processadores de 64 bits, e trabalhando com vários núcleos!! Os microprocessadores são desenvolvidos em geral para serem empregados em computadores pessoais, muitos deles são encontrados também nos nossos video-games.

Ao contrário destes, os microcontroladores são empregados principalmente em sistemas “embarcados”. Sistemas embarcados são sistemas onde o processamento é totalmente dedicado à aplicação, tendo uma série de comandos pré-definidos. É aqui que entram sistemas como o controle de microondas, sistemas de segurança, monitoramento de processos, etc.

O microcontrolador é na verdade uma espécie de computador de menor capacidade de processamento, dentro de um único circuito integrado. Além do núcleo de processamento, o microcontrolador possui memória RAM interna, memória FLASH de programa, alguns podem até possuir memória EEPROM interna. Também possui portas de entrada e saída que podem em alguns casos até fornecer corrente necessária para ligar um LED, sendo que algumas destas portas podem possuir conversores analógico-digital, para a leitura de valores analógicos. Os microcontroladores também costumam incluir temporizadores internos, além de vários dispositivos de comunicação serial, como a UART padrão, que conectada a um conversor RS-232 ou RS-485, podem possibilitar ao microcontrolador se comunicar com redes destes tipos. Os mais novos possuem também interface SPI, interface CAN, outros possuem ainda porta USB, alguns mais avançados possuem até interface ETHERNET, possibilitando ao desenvolvedor criar pequenos servidores. Há outros microcontroladores que possuem até decodificadores MP3 e controladoras IDE, perfeitos para o desenvolvimento de tocadores de MP3. Como eu já tinha mencionado, a capacidade de processamento destes microcontroladores é menor do que a de processadores, sendo que os microcontroladores mais novos operam com clocks geralmente na faixa de dezenas de Megaherz.

A grande tendência dos dias de hoje, no entanto, é o uso de FPGA’s (Field-programmable gate array). Estes circuitos integrados permitem ao desenvolvedor “programar” qual o tipo de hardware que eles possuem, usando uma linguagem HDL (hardware description language). A grande vantagem de tais circuitos integrados é que nos dias de hoje, vários microcontroladores já são implementados em linguagem HDL. Assim, se você pretente trabalhar com um microcontrolador PIC, basta fazer o download do código para implementá-lo e gravar em seu FPGA. Mas se você desejar mudar o microcontrolador, basta fazer o download de outro código, sem precisar adquirir o outro componente. As linguagens HDL mais comuns são o VHDL e o Verilog e os maiores fabricantes de FPGA’s são a Altera e a Xilinx.

Já o ASIC (Application-specific integrated circuit) se assemelha bastante ao FPGA. Só que o ASIC não é reprogramável. O ASIC é um circuito integrado feito sob encomenda para empresas do ramo, para implementar aplicações específicas. Eles possuem a vantagem de ser mais rápidos e consumir menos energia do que os FPGA’s.

Uma categoria de processadores que vem ganhando muito destaque ultimamente são os DSP’s (Digital signal processor). Estes processadores são desenvolvidos para ler e processar sinais analógicos, executando operações com estes. As aplicações mais comuns são filtros digitais. Para esta operação, os DSP’s são otimizados na execução de instruções de multiplicação-soma, que é um pré-requisito básico para a operação conhecida como convolução, que é a operação que é usada na implementação de tais filtros. Por isto, é comum que a capacidade destes processadores não seja avaliada em quantos MIPS (Millions of Instructions per Second) eles possuem, mas sim em quantos MMACS (Millions of Multiply-Accumulates per Second). Assim, em aplicações de tratamento de áudio ou vídeo, estes processadores são os preferidos. Atualmente a Texas Instruments é a empresa que mais se destaca na área, oferecendo DSP’s com até 6 núcleos de processamento.

Como os DSP’s ganham cada vez mais espaço, surge também o termo DSC (Digital Signal Controller), primeiramente introduzido pela Microchip para se referir à sua linha de produtos na área de processamento digital de sinais. Os DSC’s são na verdade híbridos entre microcontroladores e DSP’s. Da parte dos DSP’s, eles possuem a otimização de instruções de multiplicação e acúmulo, shift registers que podem rotacionar uma palavra quantas vezes necessário em apenas uma instrução de clock, e acumuladores grandes. Como os microcontroladores, estes possuem uma resposta rápida à interrupções, além de possuírem vários periféricos como controle de PWM, etc. Nem todo fabricante adota o termo DSC. Os três maiores vendedores de DSC’s são a Microchip, a Texas Instruments e a Freescale.

Bem, esta foi uma descrição básica de todas as hardwares de processamento de dados disponíveis hoje (pelo menos as mais utilizadas). Espero ter dado uma idéia básica sobre cada uma, para que todos possam entendê-las quando forem citadas durante outras discussões.