quarta-feira, 12 de novembro de 2008

Levitação e Piso Interativo

Pessoal,

Conforme prometi há alguns dias atrás ... aqui estão os displays de levitação instalados no cliente e de quebra um piso interativo com jogo de futebol...





E aqui está o jogo de futebol com piso interativo...

Utilizamos nossa plataforma de reconhecimento de imagens e juntamos com programação XNA da Microsoft... o resultado foi esse... muita gente se divertindo...



Enjoy!!!

quarta-feira, 29 de outubro de 2008

Calculadora Científica de Pulso, ou : O Grande Símbolo de Status dos Nerds


Foi lançado recentemente um projeto para montagem de um relógio-calculadora científica... não seria nada incomum se não fosse pelo fato de o cérebro do brinquedo ser um PIC... isso mesmo um PIC da série 24F.
Você não pode deixar de ter o seu... eu estou querendo o meu o mais rápido possível!! uhahuahua






Este é o link oficial do projeto: http://calcwatch.com/index.html

Enjoy! Com força mas enjoy bastante...

terça-feira, 21 de outubro de 2008

Sabonete Anti Gravidade

De vez em quando é legal postar algum trabalho diferente que eu mesmo fiz... aí está um sistema de "levitação" por diferencial de campo magnético... com um sensor hal e um LM324 consegui fazer o serviço apresentado. Dentro da caixinha tenho um imã bem forte que é constantemente puxado para cima, o sensor hal detecta sua presença e dispara o solenóide gerando um campo magnetico que repele o imã dentro da caixinha do sabonete...
No lugar do sensor hal também pode ser usado um sistema de led infravermelho, mas não fica tão elegante a montagem... isso aí filmado é só um teste, em breve posto as fotos do aparelho final que vai para o cliente. Enjoy!



EEEEEE.......

Aproveitando a leva de pedidos para colocar novos vídeos de levitação, coloque este da latinha de SKOL ... redondoooo.... vai lá Marcelo ... essa é pra vc !!!

terça-feira, 7 de outubro de 2008

Sensor IR no IO do R8C/25

Fala pessoal,

Vamos desta vez ver um sensor com infra-vermelho no IO do R8C/25.
Foi montado um circuito com um emissor contínuo usando um TIL32 e como receptor um TIL78 com seu sinal amplificado por um transistor BC549 com ganho 1000 (pra saturar mesmo:0))

O circuito do sensor segue adiante:



Tá na mão mesmo, como é tudo no protoboard não faz sentido montar isso no eagle ou outro diagramador...

Bom ... o programa que faz a leitura é o seguinte:


//**********************************************************************************

#include "sfr_r825.h"
#include "main.h"

void main(void) {
for(;;) {
loop();
}
}

void loop(void) {
char teste = 0;
teste=p3_4;
p2_7=~teste;
}

//**********************************************************************************

Coloque também no hwsetup.c, eu coloque na função ConfigurePortPins:

//**********************************************************************************
pd3_4=0;
pd3_5=0;
//**********************************************************************************

Feito isso toda vez que entrar um sinal pelo port p3_4, ele irá inverter e aplicar na saída em p2_7.

Vejam o vídeo desse artigo funcionando:



É isso galera... valeu mais uma vez.. e enjoy !!!

segunda-feira, 22 de setembro de 2008

Testando o I2C Bitbang no R8C/25

Neste vídeo eu mostro o código do artigo de I2C funcionando no R8C/25 e sendo capturado pelo Analizador Lógico...



Enjoy ALL!

domingo, 21 de setembro de 2008

Sensor Multi Touch com LEDs



Muito legal esse sensor que o cara fez com leds... aliás... como ficaria isso funcionando em um ambiente iluminado???tenho curiosidade de saber...

Gostei muito do software que o cara escreveu também... muito interessante o sistema todo...



Uma idéia muito interessante para um pointing device de microcomputador... acredito ser legal para ambientes industriais se bem condicionados...

Este outro que segue parece ser mais simples que o anterior apesar de causar um efeito um pouco maior... também é óbvio... sua finalidade é diferente... e uma matriz respeitável de sensores e leds...





Para maiores detalhes sobre esse projeto veja no link abaixo:

http://www.fischtisch.de/

sexta-feira, 19 de setembro de 2008

PIC com Ethertnet ...

Muitas vezes eu vejo threads e mais threads comentando sobre conexão de dispositivos microcontrolados em rede Ethernet... pois bem, aqui está um exemplo muito interessante postado no MicroPIC.



http://www.micropic.es/index.php?option=com_content&task=view&id=79&Itemid=1

O mais interessante é já tem tudo prontinho para seu "Hello World!" no mundo da Ethernet...

Vale a pena conferir...

domingo, 14 de setembro de 2008

Equilibrista Digital...

Usando uma manta de touch screen esses italianos fizeram uma maquininha capaz de equilibrar uma bolinha e mante-la no centro ... vejam que interessante...



E aqui um outro interessante também... ele mantem via magnetismo um metal qualquer com peso compatível óbviamente, no ar... muito interessante...

quarta-feira, 10 de setembro de 2008

E o mundo não acabou.... ainda...

Há poucas horas foi ligado o LHC do Cern, conforme postado aqui, existem vertentes cienctíficas que defendem a tese de que poderá ser criado um buraco negro, o que ocasionaria a destruição de nosso planeta.

A principio já temos protons viajando e acelerando esperando por colisões que deverão ocorrer dentro de 60 dias, conforme notícias circulando hoje pela internet.

Segue uma materia sobre o lançamento do LHC e uma breve entrevista com um Brasileiro residente no projeto.



Vamos esperar para ver os resultados, se é que vamos sobreviver aos resultados... hehehe

Enjoy!

terça-feira, 9 de setembro de 2008

Aparelho para Comunicação entre surdos/mudos e cegos

Um japonês chamado Noriaki Okada teve a idéia de usar um arduino conectado a um PC para criar duas interfaces para comunicação entre surdos/mudos e cegos.
Até aí técnicamente não é o problema mas o fantástico é a idéia e a forma como ele montou tudo isso dentro de caixas feitas de papelão.
O hardware utilizado foi um Arduino. Na verdade dois... hehehe



O mais interesante é que as mensagens escritas em qualquer um dos dois terminais são enviadas também por SMS para um iPhone (que ele usou no vídeo mas pode ser qualquer celular).
Aparentemente a comunicação precisa de um PC mas isso porque está faltando alguns hardwares... por exemplo... a comuicação entre dois aparelhos pode ser feita via Bluetooth e a comunicação SMS pode ser feita via Modens GSM... aliás colocando um Plus na aplicação: Pessoas normais poderão enviar SMS para qualquer um dos dois aparelhos usando o seu celular (via Bluetooth ou SMS), além de não precisar mais e um PC. Estudando uma bateria isso poderia realmente se tornar móvel... e seria uma bela solução.

Do mais quero comentar que sempre me sensibilizo com este tipo de "novidade" e gostaria de deixar publicamente meus parabéns ao Nori por esta idéia!

Vai lá: http://okada.imrf.or.jp/BnD/index.html não deixem de ver os vídeos para entender melhor como funciona tudo!

quarta-feira, 3 de setembro de 2008

Forum Nokia Code Camp em Outubro

Pessoal,

E aí? Vamos buscar um N96 ??? Em outubro estarei lá! Todos convidados...

Pseudo 3D com iPhone ...

Olha... não é das coisas mais fantásticas que eu já vi... mas é legalzinho ... a idéia do David O'Reily foi boa, tenho que reconhecer...


iHologram - iPhone application from David OReilly on Vimeo.

quarta-feira, 27 de agosto de 2008

Computador de Bordo


Taí pessoal, muita gente me questiona sobre o que a Youlink! faz além de ter um cara que fica escrevendo no 5Vcc... pois bem ... está aí... um computador de bordo para tratores, caminhões e máquinas de campo.
Teclado reforçado, display de 40x2 linhas, Armazenamento de dados em EEPROM (128Kbytes) e comunicação via Bluetooth. Tá certo isso que está na foto é o protótipo, falta muito detalhe para o produto final, principalmente de acabamento, manzzz já dá pra ter uma boa idéia do que fazemos por aqui ...
Claro... o processador usado é um Renesas R8C/25, o bluetooth utilizado é o ESD-100 da SENA.
Se alguém estiver interessado, o contato está em http://www.youlink.com.br.

terça-feira, 26 de agosto de 2008

[Renesas] I2C BitBang para 24XX256

Faz tempo que não consigo parar e escrever um bom POST. Pois bem, chego aqui com algo que havia prometido para muitos. Um código para barramento I2C para o 24C256 que usei num projeto meu.
Após ter alguns problemas em relação a configuração do R8C/25 com I2C via hardware, que já foi sanado, me sobrou este código desenvolvido, que aliás eu gostei mais que o I2C via device. Não pela versatilidade ou velocidade mas pela portabilidade. Acredito que este código que eu vou apresentar funciona com poucas altrações nos PICs e nos AVRs da vida.
Mas antes de falarmos do código vamos falar um pouco mais de I2C.
O I2C é um barramento serial, onde temos um canal de dados bidirecional e um canal de clock, regido pelo device Master, no caso o nosso R8C/25.

A ligação é feita de forma serial, vide esquema abaixo:


Notem que temos dois resitores de Pull-Up que devem ser instalados um para cada linha, SDA e SCL. Na prática com PIC geralmente uso resitores de 10k e com o R8C/25 uso resitores de 15k, ambos em 5V, não sei explicar o porquê mas com os Renesas só consegui estabilidade no Bus usando 50% a mais de carga no resitor de Pull-Up, vale como dica para não perderem tempo, como eu perdi tentando buscar outros motivos de "não funcionamento".

Os dados são transferidos, setando o estado do bit a ser transferido no SDA e chaveando o SCL. O dado é transferido na transição UP->Down. Acompanhe no diagrama abaixo:



Existem alguns poréns entre os estados de comunicação, dentre eles posso citar o Start Condition e o Stop Condition, no qual colocam.
O Start Condition serve para iniciar uma comunicação e o Stop Condition analogamente serve para encerrar a mesma.


De acordo com o diagrama acima, notamos que o Start Condition é gerado partindo dos sinais do SCL e do SDA em nível 1, chaveamos o SDA para nível baixo e no próximo tempo do Clock baixamos o nível do SCL.
Analogamente mais uma vez, o Stop Condition é gerado partindo dos sinals SCL e SDA em nível 0, chaveamos o SCL para nível 1 e em seguida, mais uma vez no tempo do Clock, elevamos o nível do SDA para 1.

Vide o seguinte código abaixo:

void startCondition(void) {
setSCLHigh();
setSDAHigh();
setSDALow();
waitFactor(2);
setSCLLow();
waitFactor(2);
}

Mais uma vez conforme o diagrama, antes elevamos os níveis para 1, em seguida baixamos o nível do SDA para 0, aguardamos 2 tempos do Clock, e em seguida baixamos o nível do SCL para 0. E mais uma vez aguardamos 2 tempos do Clock. Com este código geramos um Start Condition.

E agora o StopCondition:

void stopCondition(void) {
setSDALow();
waitFactor(1);
setSCLLow();
waitFactor(1);
setSCLHigh();
waitFactor(2);
setSDAHigh();
waitFactor(2);
}

Nesta função, note que chaveamos o SDA para nível 0 e aguardamos um tempo do Clock para em seguida descer o nível do Clock para 0. Fazemo isso para evitar que geremos um Erro no bus I2C no caso de um término de transação. Em seguida conforme diagrama do Stop Condition subimos o nível do SCL para nivel 1 e aguardamos dois tempos do Clock, em seguida subimos o nível do SDA para 1 e aguardamos mais uma vez dois tempos do Clock. Assim geramos um Stop Condition.

Um outro status importante na transação I2C é o Acknowlodge ou simplesmente Ack. Ele é a resposta do periférico que está sendo comunicado de que foi aceito o último byte.
O Ack é reconhecido após a escrita, colocando o pino do SDA em modo Input após o envio do oitavo bit. O pino SDA deverá ir para nível 0, forçado pelo dispositivo que se está comunicando. Ao gerar um novo pulso do Clock, é sinalizado ao dispositivo slave que foi lido o Ack, então o controle de SDA volta para o dispositivo Master, no nosso caso o R8C/25, onde o pino do SDA deve novamente ser setado como Output.
Acompanhe o código abaixo:

char getSDAState(void) {
_24C256_sda_d = 0;
asm("NOP");
return(_24C256_sda);
}

char readAck(void) {
char state=0;
setSCLHigh();
waitFactor(1);
state=getSDAState();
setSCLLow();
setSDAHigh();
waitFactor(3);
return(state);
}

Neste trecho setamos o SCL como nível 1 para finalizar o processo do último bit enviado, esperamos um ciclo de Clock, e lemos o estado do SDA. Em seguida setamos o SCL como nível 0 para sinalizar a leitura do Ack e ao mesmo tempo setamos o pino SDA como 1 para podermos iniciar uma nova comunicação ou enviar um Start/Stop Condition.
No caso do recebimento de bytes, nós não setamos o SDA como nível 1, somente baixamos o nível do SCL. Conforme código abaixo:

char readAckRcv(void) {
char state=0;
setSCLHigh();
waitFactor(1);
state=getSDAState();
setSCLLow();
waitFactor(1);
return(state);
}

Agora vamos abordar a comunicação I2C propriamente dita.
Os dois tipos de comunicação que podemos fazer são leitura randomica e escrita randomica. Na verdade há mais dois tipos que são leitura sequencial e escrita sequencial, no entanto não vamos tratar destes dois tipos aqui neste artigo.

Vamos falar inicialmente da gravação de 1 byte num endereço qualquer do 24C256.

O 24C256 é uma memória do tipo EEPROM com 256kBits ou 32kBytes. Potanto temos um endereçamento de 15Bits (2^15 = 32768 bytes).

Um outro aspecto que devemos considerar é que ao nos comunicarmos com periféricos I2C devemos saber seu "endereço" no BUS. No caso das memórias em geral elas iniciam com 0b1010 e em seguida temos os sinais dos pinos A2, A1 e A0 na sequencia, desta forma podemos usar mais de uma memória no Bus. 0b1010000[r/w], o último bit é 0 para escrita e 1 para leitura.

A comunicação na gravação é feita enviando uma sequencia de 4 bytes. Como descritos abaixo:

1.Byte = 7 bits do endereçamento do periférico mais 1 bit sinalizando leitura/gravação, neste caso gravação (0b10100000);
2.Byte = MSB do endereço de gravação na memória EEPROM;
3.Byte = LSB do endereço de gravação na memória EPPROM;
4.Byte = Byte a ser escrito na posição de memória.

Acompanhe o código abaixo para ver os quatro bytes sendo enviados, e a leitura do Ack em cada intervalo.

void Write_24C256(unsigned char deviceAddress, unsigned int menAddress, unsigned char byte) {
unsigned char myAck=0;
unsigned int tmsb,tlsb;
unsigned char msb, lsb;
tlsb = tmsb = menAddress;
tmsb = tmsb >> 8;
tlsb = (tlsb <<>> 8;
msb = (unsigned char) tmsb;
lsb = (unsigned char) tlsb;
startCondition();
if(!(myAck=writeByte(deviceAddress,0))) {
if(!(myAck=writeByte(msb,0))) {
if(!(myAck=writeByte(lsb,0))) {
if(!(myAck=writeByte(byte,0))) {
stopCondition();
waitFactor(100);
}
}
}
}
if(myAck) stopCondition();
}

Primeiro calculamos os MSB e LSB rotacionando os bits necessários, e guardando isso em variáveis de 8Bits para poderem ser usadas posteriormente no processo de gravação.
Em seguida geramos um Start Condition para iniciar transação, e enviamos nosso primeiro Byte, no Caso o conteúdo da variável deviceAddress, em seguida lemos o Ack para podermos continuar o processo, em seguida enviamos o MSB, e lemos o Ack, e enviamos o LSB na sequencia. Após tudo isso perfeitamente e o Ack afirmativo, enviamos o byte a ser gravado.
Se tudo correr bem enviamos um Stop Condition e agurdamos 100 ciclos do processador. É tempo suficiente (algo por volta de 5Ms) para que a EEPROM possa gravar o byte na memória indicada. Por fim, se houver algum problema e o Ack retornar positivo (status negativo ou "não aceito") é enviada um Stop Condition colocando Bus em stand by novamente.
Notem que no processo de gravação, usamos a função writeByte passando como parâmetro o byte a ser escrito e o indicador zero(0) sinalizando que deverá ser utilizada leitura de Ack para escrita e não leitura.

A comunicação na leitura é feita enviando uma sequencia de escrita de 3 bytes, um Start Condition, uma escrita de 1 byte e em seguida realizada a leitura. Como descrito abaixo:

1.Byte = 7 bits do endereçamento do periférico mais 1 bit sinalizando leitura/gravação, neste caso gravação (0b10100000);
2.Byte = MSB do endereço de gravação na memória EEPROM;
3.Byte = LSB do endereço de gravação na memória EPPROM;
4. **** Gerar Start Condition
5.byte = 7 bits do endereçamento do periférico mais 1 bit sinalizando leitura/gravação, neste caso leitura(0b10100001) * compara com passo 1;
Realizar a leitura do Byte (Colocar o SDA em modo Input e o Chavear o clock entre os Bits)

Eis o código:

unsigned char Read_24C256(unsigned char deviceAddress, unsigned int menAddress) {
unsigned char myAck=0;
unsigned int tmsb,tlsb;
unsigned char msb, lsb;
tlsb = tmsb = menAddress;
tmsb = tmsb >> 8;
tlsb = (tlsb <<>> 8;
msb = (unsigned char) tmsb;
lsb = (unsigned char) tlsb;
startCondition();
if(!(myAck=writeByte(deviceAddress,0))) {
if(!(myAck=writeByte(msb,0))) {
if(!(myAck=writeByte(lsb,0))) {
startCondition();
if(!(myAck=writeByte((deviceAddress|0x01),1))) {
myAck=getByte();
}
}
}
}
stopCondition();
return(myAck);
}

Basicamente esta função é identica ao processo de leitura, com exceção que no lugar do quarto byte, temos um Start Condition, e a escrita do deviceAddress com o bit 0 marcado como 1 (leitura). E obviamente após o Ack, a leitura do bit em si.

Eis o código completo dos dois arquivos... 24C256.h e 24C256.c ...

-------------- Inicio 24C256.h --------------
#ifndef _24C256_H
#define _24C256_H

#define _24C256_sda_d pd3_4
#define _24C256_sda p3_4
#define _24C256_scl_d pd3_5
#define _24C256_scl p3_5
#define waitUnit 100

// ---------------------- High Level Functions ---------------

void Init_24C256(void);
void Write_24C256(unsigned char deviceAddress, unsigned int menAddress, unsigned char byte);
unsigned char Read_24C256(unsigned char deviceAddress, unsigned int menAddress);

#endif
-------------- Fim 24C256.h --------------

-------------- Inicio 24C256.c --------------
#include "sfr_r825.h"
#include "24C256.h"

// ---------------------- Low Level Functions ---------------

void waitFactor(unsigned int factor) {
unsigned int fc=0;
factor*=waitUnit;
for(fc=0; fc}

char getSDAState(void) {
_24C256_sda_d = 0;
asm("NOP");
return(_24C256_sda);
}

char getSCLState(void) {
_24C256_scl_d = 0;
asm("NOP");
return(_24C256_scl);
}

void setSDAHigh(void) {
_24C256_sda_d = 1;
_24C256_sda = 1;
}

void setSCLHigh(void) {
_24C256_scl_d = 1;
_24C256_scl = 1;
}

void setSDALow(void) {
_24C256_sda_d = 1;
_24C256_sda = 0;
}

void setSCLLow(void) {
_24C256_scl_d = 1;
_24C256_scl = 0;
}

void startCondition(void) {
setSCLHigh();
setSDAHigh();
setSDALow();
waitFactor(2);
setSCLLow();
waitFactor(2);
}

void sendHighBit(void) {
setSDAHigh();
setSCLHigh();
waitFactor(1);
setSCLLow();
waitFactor(1);
}

void sendLowBit(void) {
setSDALow();
setSCLHigh();
waitFactor(1);
setSCLLow();
waitFactor(1);
}

char readAck(void) {
char state=0;
setSCLHigh();
waitFactor(1);
state=getSDAState();
setSCLLow();
setSDAHigh();
waitFactor(3);
return(state);
}

char readAckRcv(void) {
char state=0;
setSCLHigh();
waitFactor(1);
state=getSDAState();
setSCLLow();
waitFactor(1);
return(state);
}

void stopCondition(void) {
setSDALow();
waitFactor(1);
setSCLLow();
waitFactor(1);
setSCLHigh();
waitFactor(2);
setSDAHigh();
waitFactor(2);
}

unsigned char getByte(void) {
unsigned char byte=0;
unsigned char pos=0;
_24C256_sda_d=0;
while(pos<8) {
byte|=getSDAState();
if(pos<7) byte<<=1;
pos++;
setSCLHigh();
waitFactor(1);
setSCLLow();
waitFactor(1);
}
setSDALow();
waitFactor(1);
setSCLHigh();
waitFactor(1);
setSCLLow();
waitFactor(1);
return(byte);
}

unsigned char writeByte(unsigned char byte,unsigned char forRead) {
unsigned char rotateLeft;
unsigned char tmp;
rotateLeft = 0;
while(rotateLeft<8) {
tmp=byte;
tmp = (tmp <<>> 7;
rotateLeft++;
if(tmp) {
sendHighBit();
} else {
sendLowBit();
}
}
if(forRead) return(readAckRcv());
return(readAck());
}

// ---------------------- High Level Functions ---------------

void Init_24C256(void) {
_24C256_sda=1;
_24C256_scl=1;
_24C256_sda_d = 1;
_24C256_scl_d = 1;
_24C256_sda=1;
_24C256_scl=1;
}

void Write_24C256(unsigned char deviceAddress, unsigned int menAddress, unsigned char byte) {
unsigned char myAck=0;
unsigned int tmsb,tlsb;
unsigned char msb, lsb;
tlsb = tmsb = menAddress;
tmsb = tmsb >> 8;
tlsb = (tlsb <<>> 8;
msb = (unsigned char) tmsb;
lsb = (unsigned char) tlsb;
startCondition();
if(!(myAck=writeByte(deviceAddress,0))) {
if(!(myAck=writeByte(msb,0))) {
if(!(myAck=writeByte(lsb,0))) {
if(!(myAck=writeByte(byte,0))) {
stopCondition();
waitFactor(100);
}
}
}
}
if(myAck) stopCondition();
}

unsigned char Read_24C256(unsigned char deviceAddress, unsigned int menAddress) {
unsigned char myAck=0;
unsigned int tmsb,tlsb;
unsigned char msb, lsb;
tlsb = tmsb = menAddress;
tmsb = tmsb >> 8;
tlsb = (tlsb <<>> 8;
msb = (unsigned char) tmsb;
lsb = (unsigned char) tlsb;
startCondition();
if(!(myAck=writeByte(deviceAddress,0))) {
if(!(myAck=writeByte(msb,0))) {
if(!(myAck=writeByte(lsb,0))) {
startCondition();
if(!(myAck=writeByte((deviceAddress|0x01),1))) {
myAck=getByte();
}
}
}
}
stopCondition();
return(myAck);
}
-------------- Fim 24C256.c --------------

Aqui eis um link para a especificação do Barramento I2C no site da NXP (Philips).
http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf

Enjoy!!!

sexta-feira, 22 de agosto de 2008

Matéria sobre IOs está finalizada!

Pessoal a matéria que eu comecei a escrever falando dos IOs no Renesas e fazendo um paralelo com os PICs está completa.

Decidi terminar a matéria sem entrar muito em detalhes profundos. Vai seguir em breve um exemplo de IOs no Renesas fazendo um BitBang para Bus I2C, mais especificamente para o 24C256 da ATMEL.

Bom é isso, segue o link para quem ainda não viu...

http://5vcc.blogspot.com/2008/07/ios-com-r8c25-e-um-breve-comparativo.html

Boa sorte e estamos por aqui se alguém quiser alguma info!!!

quarta-feira, 13 de agosto de 2008

Analizador Lógico

Pois bem pessoal, aproveitando a deixa, vou mostrar o que me tirou o sono do dia de ontem...
Depois de muito discutir e ver todo mundo falar... mas ninguém fazer, eu resolvi botar a mão na massa e fazer um analizador lógico para resolver um probleminha que ando tendo com I2C aqui.
Como não estava com paciência para fazer placa etc... usei meu kit da Mosico, gravei um 16F877 jogando pela serial o scan do port d e recebendo isso num programa em .NET que eu montei as pressas ...
Tá aí uma telinha do danado depois de uma captura.

Ainda tem alguns probleminhas para resolver, como a velocidade de captura dos samples, 20Mhz no PIC não é muita coisa quando programado em CCS C. E velocidade de transmissão / processamento no PC. Mas como gambia... quer dizer "solução técnica alternativa" funciona direitinho. A captura acima foi feita em cima de uma BUS I2C a 78.1kHz.
Em breve vou postar mais detalhes e abrir o projeto pra comunidade!!!
Enjoy!

Limpando as COMs do seu Windows

Pessoal,

Depois de um hiato de alguns dias, continuo aqui meus POSTs para ajudar a galera da eletrônica. Pois bem. Desta vez vamos falar um pouco sobre Bluetooth e como os Dongles entopem nossa máquina de portas seriais inativas e que não podem ser associadas para outras aplicações.
Isso em determinado momento pode causar alguns problemas, como por exemplo, alguns programas que não conseguem acessar portas seriais além das padrões (COM1, COM2, COM3, COM4) que eram as mais comuns nas versões antigas de muitos sistemas.
Recentemente eu tive um problema parecido e tiver que descobrir como fazer uma limpeza.
Eu precisei instalar um adaptador USB-Serial e mapear o mesmo como COM3 ou COM4, no entanto o meu windows não permitia, alegando que a porta já estava sendo usada por outra aplicação.
Daí descobri que cada vez que colocamos um Dongle BLuetooth novo no nosso Windows, ele associa uma nova porta para ele. E quando você tira ele, essa porta não é liberada, causando assim um acumulo gigantesco de portas inativas e inacessíveis. Para vocês terem uma idéia a porta mais baixa disponível era COM48 no meu computador e como não usava o USB-Serial há fazia um tempinho, as portas COM3 e COM4 que eu geralmente associo para o conversor, foi ocupada por alguma antena, onde o Windows escolheu a porta mais baixa disponível e capturou ela.
Pois bem o procedimento para resolver o problema é:

  1. Chame o regedit através do menu iniciar (clique em menu iniciar e escreva regedit e se for Windows Vista, ou clique em menu iniciar -> executar e escreva regedit se for Windows XP ou anterior)
  2. No regedit vá em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\COM Name Arbiter.
  3. Clique com o botão direito dobre a chave COM Name Arbiter e irá aparecer uma lista de bytes contendo o mapeamento de todas as suas COMs.
  4. Apague o que está nesta lista, e feche a janela de edição.
  5. Feche o regedit.

Até este ponto ok. Ele libera todas os portas para você criar novas associações, no entanto os conversores USB-Serial não funcionavam. Conclusão: Desinstale todos os adaptadores sem mandar apagar os drivers que já estão na máquina. Tire o adaptador fisicamente, espere pelo sinal de retirada de hardware do Windows e recoloque o mesmo. O Windows vai reinstalar os drivers do seu adaptador, em seguida é só associar a porta que você quer e ser feliz!

Boa sorte a todos...

quinta-feira, 7 de agosto de 2008

10 de Setembro - Destruição da Terra?



Após alguns dias sem conseguir postar nada no Blog, eu retorno e para dar uma notícia nada trivial... a destruição da terra... bom... pelo menos para os que creêm que é possível, explico a seguir;

Se você é uma das pessoas que acreditam que o Acelerador de Partículas do CERN o Large Hadron Collider pode destruir o planeta por causa de uma reação em cadeia no ato da criação de partículas de antimatéria, prepare-se, dia 10 de setembro ele irá entrar em funcionamento.

E para aqueles que ainda não entenderam muito bem o que é tudo isso... aí vai um RapZinho para sacar o que os caras do CERN estão fazendo por lá!!! Enjoy!


CERN Rap from Will Barras on Vimeo.

Origem da Notícia: http://www.popsci.com/scitech/article/2008-08/and-we%E2%80%99re

quarta-feira, 30 de julho de 2008

[Iniciantes] Aula sobre resistores

Aula sobre resistores (Português Brasil)

Soldagem de SMDs

Mais uma vez posto aqui alguns vídeos sobre soldagem de SMDs ... só que desta vez com a estação de solda do primo-rico, sopro de ar-quente e pasta de solda... hehehe... vale a pena assistir se você está iniciando na montagem de SMDs.





segunda-feira, 28 de julho de 2008

Setando Direction Bits no Port 0 do R8C/25

Pois bem pessoal, estou eu aqui mais uma vez dividindo minhas horas de labuta em cima do R8C/25 com vocês. Hoje com uma dica importantíssima que economizará algumas horas em testes e consulta no manual do hardware.
Ao fazer o setup dos Direction Bits do Port 0 é necessário antes desproteger o mesmo. Mas porquê isso ocorre?
Existe um registro na SFR que chama-se Protect Register. Ele serve para proteger registros importantes para não ser facilmente sobrescritos quando o programa pode estar fora de controle. Os registros protegidos são:

• PRC0 bit: CM0, CM1, OCD, FRA0, FRA1 and FRA2 registers
• PRC1 bit: PM0 and PM1 registers
• PRC2 bit: PD0 register (olha o nosso vilão aqui!)
• PRC3 bit: VCA2, VW0C, VW1C and VW2C registers

E agora um esquema desta entrada na SFR:

Mas vamos ver um exemplo disto funcionando...

Primeiro um exemplo do que vamos fazer... e como me deparei com o problema.
A tarefa é simples e aparentemente trivial, e o é... simplesmente quero setar um SFR bit a bit e não o byte todo... olhem o exemplo fazendo isso no port 1...

Em seguida o exemplo original como o HEW monta no ambiente, alterando o prc2 para 1 e em seguida alterando o byte todo...


Executando o código acima, vamos abrir o View -> CPU -> IOs para acompanhar o que está sendo feito dos nossos registros (Valeu André por me lembrar desta ferramenta dentro do HEW!)


Notem que ao executar e chegar no break-point pd0 contém o valor 0x0F...

Agora vamos tentar fazer o mesmo só que bit a bit... notem que foi alterado somente o primeiro bit. Isso se deve ao fato que foi desprotegido o registro e após setarmos o primeiro bit, ele retornou ao estado protegino original. Portanto não executando conforme eu pretendia.


Pois bem, se a cada bit nós desligarmos o protect register do pd0, nós conseguiremos setar todos os bits conforme imaginamos.

Bom pessoal, é isso... notem que este aspecto somente ocorre com o pd0 e não com os outros registros deste SFR, conforme nota no quadro do SFR postado neste artigo...

PS: As informações deste post foram retiradas do Datasheet do R8C/24 e 25, página 96, Tópico 11.

Geração de Energia Sustentável


É pessoal... todos falam em preservas reservas naturais e melhorar nossa relação com nosso planeta, no entanto pouco fazemos para mudar realmente nosso impacto no meio ambiente. No entanto em Rock Port, no Missouri, uma cidade com 1300 habitantes resolveu revulcionar sua geração de energia e hoje usam energia 100 gerada pelo vento...
Quatro turbinas geram toda a energia necessária para suprir as necessidades da pequena cidade. Veja mais em http://www.sciencedaily.com/releases/2008/07/080715165441.htm.

5Vcc também é preservação ambiental!

domingo, 27 de julho de 2008

Cilindro de LEDs

Como todos sabem eu adoro brincar com LEDs e também gosto de postar o que aparece de interessante...
Saiu no BricoGeek este novo circuito que esse sujeito fez...

quarta-feira, 23 de julho de 2008

Dissecando o iPhone3G ...

Sim gente... dissecaram o coitadinho do celular...
Saiu no iTrixx desta semana um artigo com vídeo mostrando dois caras muito curiosos abrindo um iPhone 3G e comentando sobre suas descobertas...
O mais interessante é descobrir que a Apple continua desenvolvendo coisas simples e muito funcionais.. apesar de eu ODIAR touchscreen!
Vídeo muito legal ... e valioso também pelo fato de poupar o iPhone de muita gente que eu conheço e que com certeza iria desmontar o danadinho...



domingo, 20 de julho de 2008

Hackearam o SIM CARD do GSM ...

Sim pessoal é isso mesmo ... acabo de ver este link que saiu no Vimeo ... interessantíssimo!!! O pior que eu sempre disse que era possível fazer a quebra exatamente desta forma ... felizmente apareceram dois loucos com tempo sobrando pra isso ...hehehe ;-)


Citizen Engineer from citizen engineer on Vimeo.

Brincando com Bluetooth

Dia desses rolou na PICList uma thread falando sobre antenas Bluetooth ... e como muitos sabem eu estou trabalhando muito com Bluetooth, pelas razões mais malucas que se possa imaginar. Desde entrega de conteúdos para campanhas publicitárias (temos hoje a maior rede do Brasil de emissão de sinal Bluetooth www.yesmobilemedia.com.br) como também Bluetooth para indústria.
O amigo da PICList postou fotos de antenas Bluetooth falsificadas do dongle USB com chipset Blutonium BCM2035... pois bem como eu acabo comprando muito dessas anteninhas para minha aplicação de entrega de conteúdo, resolvi postar um pouco da minha experiência para que desavisados não caiam no golpe do baú na hora de comprar seu Dongle.
Vejam a foto a seguir:



Da esquerda para a direita:

Antenas 1 e 2 - Blutonium Verdadeiras - A antena é real e realmente funciona, não só para transmissão como para recepção também... a diferença de cobertura/sensibilidade é da ordem de 40 metros do ponto central em campo aberto.

Antena 3 - Blutonium Falsa - O Windows não reconhece naturalmente, não deixa de ser um bom Dongle, no entanto, não tem a mesma potência de cobertura que a original e também precisa de software de terceiros para funcionar porcamente (na minha opinião).

Antena 4 - Trendnet 104UB - Uma porrada! De longe a melhor antena que testei até agora... o problema é o preço... perto de 150 reais quando se consegue achar aqui no Brasil.

Dicas para não comprar gato por lebre:

1. Se possível tente sempre comprar pessoalmente para verificar o produto. Caixa mal acabada é sinal de antena falsificada ou produto de má qualidade.
2. Não se faça de "cliente bonzinho". Abra o pacote e plugue a antena numa máquina o mais possível parecida com a sua, no meu caso levo meu notebook e testo sem dó!
3. Antenas que precisam de driver utilizam implementação dos serviços básicos Bluetooth por software. Não que isso vá acabar com o processamento do seu computador, mas só isso já é sinal de que colocaram um chip barato na placa, portanto, não espere potência de uma Trendnet ou Belkin dessa anteninha!
4. Suspeite e risque da sua lista de opções as antenas muito baratas, certeza que é produto inferior. Exisem empresas vendendo antenas que dizem ser blutonium por R$15,00, principalmente no mercado livre... saia fora destes caras... certeza que é golpe. E o pior é que muitas vezes o vendedor nem sabe que está sendo golpista! Existem casos de vendedores que tecem longos discuros a respeito das vantagens de se comprar um Dongle com antena externa e que o mesmo é um produto que vale ouro. E quando você vai abrir a caixinha do Dongle, se depara com uma antena falsa. Geralmente nestes casos é só perguntar se precisa de CD para instalar... se precisar... pule fora... não é a Blutonium original. Para ter uma base de valores... o Dongle Bluetooth com antena externa com chipset da Blutonium custa por volta de R$50,00...
Bom... fora isso... eu andei fazendo uma gambiarras em algumas antenas lá na empresa pra mostrar pro pessoal que para a antena, não é necessário mais que o que vem originalmente no projeto.
Vejam isto:




Pluguei uma antena telescópica dessas de radinho a pilha pra poder testar em vários tamanhos da mesma... e... não surtiu nenhum efeito prático... conforme esperado... na verdade fiz isso pra mostrar pra um cliente que não fazia diferença ... sabe como é... além disso era uma desculpa pra gambiár um Donglezinho e postar pra vocês...

Agora falando de coisa séria... sérissima...
Estou produzindo meus próprios conectores Bluetooth para serem utilizados em Campo com o padrão SPP... e esta semana chegaram as PCIs de protótipo que mandei fazer.


Notem nas fotos seguintes... a gambi para o regulador de tensão (LD33) que eu utilizei...
Ao desenhar o mesmo do Eagle os pólos Vin e GND saíram invertidos... conclusão... Tabajarisse prá mais de metro... na primeira placa fiz uma gambi com fios mesmo...




Na segunda cologuei CI por baixo...acabou ficando mais bonitinho...


Essa daí é a mãozinha do Selo de Qualidade Tabajara (né Xandão?) ...

O módulo que vocês viram instalado é um Sena SD100... funciona muito bem para ambientes críticos. Em geral indústria etc... tem uma qualidade e estabilidade bem diferente dos Dongles USB que estamos acostumados... o que por si só justifica o projeto...

Abraços a todos...

segunda-feira, 14 de julho de 2008

Adaptador LQFP52 para Pinos DIN para ligar o R8C/25 no protoboard Versão 1.0

Pois bem pessoal...

Como os projetos aqui estão apertando e preciso prototipar rapidamente no protoboard... apresento a versão 1.0 do adaptador do Pereira LQFP52 para DIN ... Segue fotos...

A placa transferida com a Eca-Laser transferência...



O Layout no note...



Corroendo a placa...



Placa pronta para inserir o R8C/25 e os PIN-HEAD...



Placa pronta para a brincadeira...

Led POV Globe

Da série: "Coisas que eu adoraria ter tempo para fazer..." ...



Boa semana...

domingo, 13 de julho de 2008

IOs com R8C/25 e um breve comparativo com PIC

Pessoal, depois de mais uma semana daquelas... segue mais um pouco de teoria e um tiquinho de prática com o R8C/25 ...
Desta vez vamos falar um pouco sobre IOs no R8C/25 e comparar com seus "equivalentes" em PIC.
Para alguns pode ser um assunto fácil e até trivial, mas é interessante explicar bem para o pessoal que está iniciando em microcontroladores... afinal isso aqui é um blog para divulgar informações e incentivar o desenvolvimento tecnológico...
O mais interessante é que tudo que for escrito neste post poderá ser aplicado para outros MCUs como o PIC, AVR, etc...

Vamos lá!

Basicamente todo MCU(Microcontrolador) tem um conjunto de Entradas(Inputs) e Saídas(Outputs) ou IOs como são comumente chamados. É através destes IOs que os MCUs se comunicam com componentes externos, como sensores, displays de LCD, teclados, teclas, Leds, e toda sorte de dispositivos que podemos conectar num MCU dentro de um projeto.

A princípio todo pino de um MCU é um pino de IO com algumas excessões como por exemplo os pinos de alimentação (Terra e 5V), pinos do clock (cristal) e alguns pinos que eventualmente em alguns modelos funcionam somente como Entrada ou como Saída. Além é claro de casos onde existem pinos NC ou Not Connected.

A quantidade de IOs que cada chip tem depende basicamente do seu invólucro. Veja alguns exemplos abaixo:

PIC 16F628A - invólucro de 18 pinos sendo 16 IOs dependendo da configuração de clock que se escolhe.
PIC 16F877A - invólucro de 40 pinos sendo 33 IOs
R8C/25 - invólucro de 52 pinos sendo 41 pinos de IO, mais 3 de input only...

Para maiores informações relativos à serie R8C Tiny da Renesas veja gráfico abaixo e visite a página http://america.renesas.com/fmwk.jsp?cnt=r8ctiny_series_landing.jsp&fp=/products/mpumcu/m16c_family/r8c_tiny_series/.



Somente à título comparativo, o link equivalente da Microchip é http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1002&mid=10〈=en&pageId=74 para os MCUs de 8Bits.

Muitos pinos em vários MCUs podem ter funções especializadas de IOs, como por exemplo ADCs, saídas PWM, UART(serial), I2C, etc...

Todo pino de IO deve ser inicializado antes de ser utilizado, e configurado de acordo com a utilização que se deseja dentro do seu design. Essa inicialização serve para sinalizar a direção do bit, se entrada; ou saída; se é analógico, etc... Processo também conhecido como Bit Direction (em inglês).

Em geral, todo MCU tem uma área específica de memória onde contém informações de configuração de todos os pinos, definidos na inicialização e ao decorrer da execução do programa em sua memória. Esta área chama-se SFR, ou Special Function Registers.
SFR é nada mais que uma coleção de bits divididos ao longo de um trecho da memória do microcontrolador onde setamos bits contendo informações sobre comportamente de cada periférico dentro do MCU. Por exemplo se um determinado pino é de entrada ou saída, e se esta entrada por exemplo é analógica ou digital... a ainda mais... se for escolhida como entrada analógica, qual a profundidade de bits da conversão do ADC ou em outras palavras se esta entrada analógica será de 8 ou 10 bits de resolução. Dentre outras utilizações que tratam direta ou indiretamente IOs.

Em linguagem C fica um pouco mais fácil de acessar os SFRs e configurá-los.
Mais especificamente falando em CCSC nós temos funções pré-concebidas para configurar os SFRs, no caso dos PICs. No caso dos R8C Tiny, temos sempre gerado na criação do projeto um arquivo de inicialização contendo vetores para cada registro do SFR ou para conjuntos de Bits específicos.

Usando incialmente como exemplo vamos pegar um PORT do PIC... por exemplo o Port B de um 16F877:

Cada port representa 1 Byte de Dados ou 8 Bits... cada Bit em um port pode ter sua configuração de direção ... em outras palavras ...

1 Byte = 8 Bits = 0b00000000

Podemos colocar somente 4 bits alternadamente como saída e 4 como entrada.

0b01010101

Bits setados como 1 são marcados para input enquanto que os bits marcados como 0 são de output.

em CCSC ficaria algo assim:

set_tris_b(0b01010101);

Por outro lado usando o HEW e o compilador C para o R8C/25 temos a seguinte situação para a mesma configuração só que no Port 2:
No arquivo hwsetup.c, na função ConfigurePortPins() nós acrescentamos a seguinte linha:

pd2 = 0b11110000;

Como dito anteriormente o vetor pd2 aponta para o SFR correspondente no chip e sua definição estará em sfr_r825.h . Se você não o fez, então faça uma leitura deste arquivo e compare o mesmo com o Datasheet do chip. Verás que tudo corresponde.

Do mais... para setar o port inteiro podemos usar:

Em CCSC
#byte port_b=6
no header do programa ...
e port_b = 0xFF;
para setar tudo com nível alto na saída.

Em Renesas:
p2=0xFF;

Agora vamos ler os bits individualmente...

Em geral no CCSC tem os todos os pinos do microcontrolador que usamos declarados no arquivo de header do mesmo, por exemplo o PIC 16F877 temos todos os pinos identificados... vale a pena dar uma olhadinha no arquivo header do microcontrolador que você está utilizando.

PIN_D0 = 1; //para setar o pino D0 do 16F877 como nível alto.
PIN_D0 = 0; //para setar o pino D0 do 16F877 como nível baixo.

ou

if(PIN_D0) { // para testar se o pino D0 está em nível alto.
if(!PIN_D0) { // para testar se o pino D0 está em nível baixo.

Obviamente ao utilizarmos estes procedimentos devemos setar anteriormente o pino como entrada ou como saída, de acordo com o datasheet do mesmo.
Lembren-se que alguns pinos geralmente os pinos do port a são iniciados como entradas ou saídas analógicas nos PICs, portanto no processo de inicialização é necessário setar corretamente a configuração para utilizá-los de forma correta e evitar leituras/escritas incorretas.

Nos Renesas podemos identificar os pinos individualmente através da colocação do underline e do número do pino do port que queremos acessar. Mais uma vez vale a dica de dar uma olhada no arquivo header do dispositivo que você estiver utilizando para conferir os pinos disponíveis e possíveis recursos que podem ser utilizados, assim como literalmente conhecer o datasheet de cabo a rabo, lendo inclusive as observações. A maioria dos problemas que eu geralmente tenho quando quero fazer algo acontecem justamente nestas observações.

Por exemplo:

p2_0 = 1; // seta o pino zero do port 2 como nível alto
p2_0 = 0; // seta o pino zero do port 2 como nível baixo

analogamente podemos usar o mesmo método para ler o pino:

if(p2_0) { // para testar se o pino zero do port 2 está em nível alto.
if(!p2_0) { // para testar se o pino zero do port 2 está em nível baixo.

Bom pessoal é isso, espero ter esclarecido este ponto.

sexta-feira, 11 de julho de 2008

Logic Analyser usando arduino...

Como todos sabem, ATMega não é o meu forte... mas esse projeto eu achei tão legal que eu vou postar aqui...
O cara fez um Analisador Lógico com o Arduíno, usando um Buffer de 1000 Bytes em Barramento I2C... muito legal!



E o link para a página com o projeto não funciona... mas está lá no Youtube... que pena...

Nanotecnologia, Telefones Conceito e oLeds... um pouco sobre tecnologia...

Lendo um post em uma lista de discussão sobre Microcontroladores, sobre oLeds ou Leds Orgânicos resolvi ir um pouco mais além e colocar aqui algumas coisas legais também sobre nanotecnologia e também alguns vídeos da Nokia sobre telefones conceito baseados nestas duas tecnologias...

Seguem os links no YouTube...

Sobre o oLed da Sony...



E um vídeo apresentando os oLed da Universal Display Corporation



E aplicando tudo isso em produtos...

Fone Conceito da Nokia... draft...



Fone Conceito da Nokia modelo 888 ...



E o Nokia Aeon ... esse já existe e usa no lugar do LCD um oLed...

quarta-feira, 9 de julho de 2008

Teclado de bancada com Sucata de TK3000

Pois bem pessoal, eu estava precisando de um teclado de bancada mais parrudo do que os teclados de telefone... na verdade o problema não era o espaço e sim um equipamento que ficasse em cima da bancada, um equipamento maior seria melhor...
Olhando minhas sucatas me deparei com um velho TK3000 (para desespero completo do meu amigo Xandão do Tabajara Labs... a placa mãe vai pra você tá?) que torrou no passado e então eu resolvi desmontar o teclado e reutilizar o que pudesse para criar o meu teclado de bancada. Sigam com a loucura...

A vítima...


A vítima por dentro...


O lindo coração da vítima... um 65C02 do mais alto calibre...


Uma etiqueta da fonte que estava jogada dentro do gabinete... viu? Cuidado alta-tensão... fonte chaveada! PERIGO!!! Não tentem isso em casas crianças ... pelo menos não sem a supervisão de um Nerd!

A parte de baixo retirada...

O teclado... objetivo do massacre...

O teclado retirado...

O coitadinho sem as teclas ... olha que sujeira ... quantos anos de poeira heim?

As teclas retiradas...

Um banho relaxante paras as mesmas com direito a detergente...

O detalhe do teclado... sem as teclas... um pouco mais limpo... uma leve pincelada por cima...

A placa já com tudo dessoldado...


Olha os leds... pisca, pisca, pisca...


As teclas que foram retiradas... para reaproveitamento...


E tudo separadinho em saquinhos de 20 unidades... vai pro arquivo...


Pois bem... agora com todo o material em mãos resta saber o que fazer... foi daí que eu resolvi abrir meu santo e idolatrado Eagle e mandar ver no layout... desenhei o botão já que é praticamente impossível achar isso em qualquer lib... e montei um layout básico...


E roteada a placa...

Olhem o resultado... um lindo e "robusto" teclado de bancada... meu sonho dourado...

E o teclado ligado para um teste...

E agora segue pra variar um videozinho do bichinho funcionando...



Desta vez matamos a cobra, um TK3000 e mostramos o pau... quer dizer... o teclado de bancada... Bratzos a todos...