PIC falando RS232 (com o PC) e RS485 (demais eqptos)

Software e Hardware para uC PIC

Moderadores: andre_luis, 51, guest2003, Renie

Mensagempor ffkammer » 22 Out 2007 11:48

xultz escreveu:Eu já me meti a fazer conversores 232 <> 485 e todos funcionaram quase bem, eu só fiquei plenamente satisfeito quando comprei um conversor industrial da LRI. Eles não são exatamente baratos, mas funcionam de forma transparente para tua aplicação (o circuito do conversor entende quando você está mandando informações e sozinho domina a rede 485 e quando termina ele libera) e para tua aplicação no PC vai ficar exatamente igual transmitir via RS232 como 485, não vai precisar manipular o RTS nem nada.
Eu recomendo fortemente você pensar em usar uma solução deste tipo.

Bom dia Xultz,

Obrigado pela sua resposta. Mas nos demais equipamentos que estarão pendurados na rede RS485 e que somente receberão comandos eu precisarei utilizar um conversor deste também ou posso continuar fazendo meu conversor com o MAX485?

Abraços

Fabrício
ffkammer
Bit
 
Mensagens: 23
Registrado em: 18 Out 2007 18:24

Mensagempor Bakuri » 22 Out 2007 12:12

ivan escreveu:
...
|-- RS232/485 -----|------------------------------ RS485 ---------------------------------|
PC <=========> PIC ==> Eqpto1 ==> Eqpto 2==> Eqpto3==> ... ===> Eqpto 30


Salve ffkammer!!!

Se a tua aplicação for exatamente isso, acho que podemos resolver... 8)

1) rx do pic direto na 232.

2) tx do pic vai entrar em duas portas and.
2.1) 1ª "and" seleciona RS232
2.2) 2ª "and" seleciona RS485

Voce vai ter 2 pinos do pic para selecionar 232/485.

Se funcionar paga umas brejas que a gente faz só com 1 bit de seleção.
:lol:



Abraços,
Fabio
Bakuri
Bit
 
Mensagens: 24
Registrado em: 20 Mar 2007 21:07

Mensagempor xultz » 22 Out 2007 12:31

Os demais equipamentos são desenvolvidos por você ou recebem/enviam dados por uma porta RS232?
A comunicação precisa ser bidirecional entre quem e quem?
98% das vezes estou certo, e não estou nem aí pros outros 3%.
Avatar do usuário
xultz
Dword
 
Mensagens: 3001
Registrado em: 13 Out 2006 18:41
Localização: Curitiba

Mensagempor ffkammer » 22 Out 2007 12:44

xultz escreveu:Os demais equipamentos são desenvolvidos por você ou recebem/enviam dados por uma porta RS232?
A comunicação precisa ser bidirecional entre quem e quem?


Boa tarde Xultz,

Os demais equipamentos são desenvolvidos por nós e são extremamente simples, apenas recebem comandos via rede RS485 e ativam e desativam algumas contatoras. Cada equipamento deste tem 1 PIC para armazenar o status atual das contatoras e, em caso de parada de energia, voltar com as contatoras no status anterior. Estes equipamentos apenas recebem os comandos do computador via rede RS485, não enviam nada.

Abraços,

Fabrício
ffkammer
Bit
 
Mensagens: 23
Registrado em: 18 Out 2007 18:24

Mensagempor ffkammer » 22 Out 2007 12:48

Bakuri escreveu:
ivan escreveu:
...
|-- RS232/485 -----|------------------------------ RS485 ---------------------------------|
PC <=========> PIC ==> Eqpto1 ==> Eqpto 2==> Eqpto3==> ... ===> Eqpto 30


Salve ffkammer!!!

Se a tua aplicação for exatamente isso, acho que podemos resolver... 8)

1) rx do pic direto na 232.

2) tx do pic vai entrar em duas portas and.
2.1) 1ª "and" seleciona RS232
2.2) 2ª "and" seleciona RS485

Voce vai ter 2 pinos do pic para selecionar 232/485.

Se funcionar paga umas brejas que a gente faz só com 1 bit de seleção.
:lol:



Abraços,
Fabio


Humm... idéia interessante a sua Bakuri...

Desta forma eu ligaria o PIC em paralelo com o computador e com o MAX485 e usaria 1 dos pinos dele para selecionar através de qual rede eu estaria transmitindo... isto realmente poderia me ajudar, pois como falei, a principal função deste PIC central é substituir o computador em caso deste estar com problemas. Ele terá alguns controles que só deverão operar caso o computador não esteja no ar e manter registros de quando estes comando foram acionados.

Vou pensar seriamente nesta possibilidade. De qualquer forma fico aguardando mais idéias do pessoal... principalmente sobre a possibilidade de montar um conversor RS232/RS485 full duplex.

Muito obrigado Bakuri

Abraços,

Fabrício
ffkammer
Bit
 
Mensagens: 23
Registrado em: 18 Out 2007 18:24

Mensagempor xultz » 22 Out 2007 18:17

Nas placas que apenas receberão os comandos, você coloca o MAX485 com o pino de EN aterrado, dessa forma ele fica somente no modo de recepção. Porém, o que é bacana é que ele comande o pino de EN para transmitir, daí você pode fazer um protocolo um pouco mais robusto, com o dispositivo enviando um comando dizendo que recebeu o comando e executou, assim, se ele não receber por algum motivo o PIC vai saber, o software também, etc. Mas é claro, isso é opcional.
De qualquer maneira, com todo mundo falando em 485, fica um sistema mais homogêneo e interessante, e com mais opções de controles.
98% das vezes estou certo, e não estou nem aí pros outros 3%.
Avatar do usuário
xultz
Dword
 
Mensagens: 3001
Registrado em: 13 Out 2006 18:41
Localização: Curitiba

Mensagempor ffkammer » 22 Out 2007 18:33

xultz escreveu:Nas placas que apenas receberão os comandos, você coloca o MAX485 com o pino de EN aterrado, dessa forma ele fica somente no modo de recepção. Porém, o que é bacana é que ele comande o pino de EN para transmitir, daí você pode fazer um protocolo um pouco mais robusto, com o dispositivo enviando um comando dizendo que recebeu o comando e executou, assim, se ele não receber por algum motivo o PIC vai saber, o software também, etc. Mas é claro, isso é opcional.
De qualquer maneira, com todo mundo falando em 485, fica um sistema mais homogêneo e interessante, e com mais opções de controles.


Obrigado mais uma vez xultz,

Pensei em fazer este controle do pino de transmissão do MAX485 nos equipamentos, mas minha preocupação em fazer isto é ocasionar conflito de informações na rede RS485 e, consequentemente, perda de dados.

Como falei em uma mensagem acima, tenho pouco conhecimento em comunicação serial e em relação à comunicação usando RS485 meus conhecimentos são praticamente zero, este é meu primeiro projeto.

Se você puder me ajudar em como fazer isto ou se tiver algum tutorial onde eu possa ver como montar um protocolo pra comunicação e também o diagrama do ciruito informando como eu poderia fazer o controle de transmissão e evitar conflito de informações na rede ajudaria bastante.

Abraços

Fabrício
ffkammer
Bit
 
Mensagens: 23
Registrado em: 18 Out 2007 18:24

Mensagempor Bakuri » 23 Out 2007 15:24

ffkammer escreveu:
xultz escreveu:Nas placas que apenas receberão os comandos, você coloca o MAX485 com o pino de EN aterrado, dessa forma ele fica somente no modo de recepção. Porém, o que é bacana é que ele comande o pino de EN para transmitir, daí você pode fazer um protocolo um pouco mais robusto, com o dispositivo enviando um comando dizendo que recebeu o comando e executou, assim, se ele não receber por algum motivo o PIC vai saber, o software também, etc. Mas é claro, isso é opcional.
De qualquer maneira, com todo mundo falando em 485, fica um sistema mais homogêneo e interessante, e com mais opções de controles.


Obrigado mais uma vez xultz,

Pensei em fazer este controle do pino de transmissão do MAX485 nos equipamentos, mas minha preocupação em fazer isto é ocasionar conflito de informações na rede RS485 e, consequentemente, perda de dados.

Como falei em uma mensagem acima, tenho pouco conhecimento em comunicação serial e em relação à comunicação usando RS485 meus conhecimentos são praticamente zero, este é meu primeiro projeto.

Se você puder me ajudar em como fazer isto ou se tiver algum tutorial onde eu possa ver como montar um protocolo pra comunicação e também o diagrama do ciruito informando como eu poderia fazer o controle de transmissão e evitar conflito de informações na rede ajudaria bastante.

Abraços

Fabrício


Salve ffkammer!!!!!

Concordo com o xultz, segue essa idéia que você vai ter uma rede mais inteligente e robusta.

Se eu entendi certo a idéia é simples. Tipo...


PIC (485) ---T-----------T--------......------T
_______|eq.1|____| eq.2|___......__|eq.n|



Seqüência de comandos:
1) pic manda um comando pra um eq. (tem q ter endereço)
e espera uma resposta, se em xx ms não receber, então, envia novamente.
Esse procedimento garante o recebimento e analisa se o equipamento esta on line.

2) O eq. correnpondente recebe a instrução e envia uma "resposta de ok".
A resposta de ok pode ser um valor hex qq, desde que, conhecida. Por exemplo "0F AB 10". 8)

3) Os demais eq. vão conseguir distinguir a instrução e a "resposta de ok (0FAB10)".


O legal que dá pra usar as outras duas portas and do 74.

Em resumo... se receber bem o (0FAB10), tá tudo beleza.
Agora ganhei as brejas?????
:D





Abrçs,
Fabio
Bakuri
Bit
 
Mensagens: 24
Registrado em: 20 Mar 2007 21:07

Mensagempor xultz » 23 Out 2007 18:06

É bastante simples. No teu caso, o ideal é usar a boa e velha técnica do mestre e escravos. Funciona assim:
um dos membros do barramento você considera o mestre. No teu caso, o mais óbvio seria deixar o PC como mestre. Todos os demais são escravos.
Somente o mestre começa uma transmissão. Um escravo somente transmite se o mestre mandar, caso contrário ele vai ficar quieto, mesmo que esteja com vontade de ir no banheiro. Somente se o mestre perguntar a ele se ele quer ir no banheiro, ele vai poder responder que sim, caso contrário, ele vai ficar apertado esperando.
A segunda coisa a fazer é determinar um endereço para cada dispositivo, inclusive o mestre. Você, por exemplo, determinar que o PC é 01, o PIC é 02, e os demais dispositivos vão recebendo endereços. Nas placas, por exemplo, você pode setar um valor colocando pinos em nível alto e baixo (se tiver), e a placa quando é ligada lê estes bits e assume como seu endereço. É imprescindível que você não atribua dois dispositivos com o mesmo endereço.
Daí você precisa criar um protocolo. Uma maneira simples seria um protocolo onde cada mensagem (ou frame) é feito de 5 bytes. O primeiro byte é um valor especial que sinaliza início de frame. Escolha qualquer um entre 0x00 e 0xFF. Suponha que você escolheu o valor 0xC5.
O segundo é o destinatário do frame. O terceiro e quarto byte são informações (mais a respeito abaixo), e o último é o checksum. Um jeito simples de fazer o checksum é somar todos os bytes, do primeiro ao quarto.
A rotina dos escravos de recepção é um fluxograma simples:
você tem um flag de start byte, e um de endereço. E duas variáveis de informação.
Começa a rotina com os dois flags zerados.
Se ambos flags estiverem zerados e recebeu um start byte, sobe o flag de start byte.
Se o flag de start estiver alto e recebeu um byte que é igual ao seu endereço, sobe o flag de endereço.
Se ambos flags estão altos e recebeu um byte, é o primeiro byte de informação. O próximo é o segundo byte.
Se recebeu os dois bytes, os dois flags estão altos, o próximo é o checksum. Calcula o checksum somando o start byte, o endereço e os dois bytes recebidos, se conferir, então frame é válido.
Se qualquer uma das situações acima não baterem, zera tudo porque é lixo.
Na resposta, o escravo manda as informações com o mesmo protocolo, mandando para o endereço 01. Desse jeito, ninguém interfere na comunicação de ninguém, e o software fica perguntando e comandando quem ele quiser na hora que quiser. Se ele enviar uma pergunta e não obtiver uma resposta, algo de errado ocorreu e o usuário recebe um aviso, pode ser que um dos dispositivos pifou, pode ser que a rede inteira está fora do ar (você sabe isso se somente um dispositivo não responde, ou se ninguém responde).

Pois bem, assim definimos algumas camadas OSI da tua rede (é bem interessante você ler sobre isso).

Na parte dos dois bytes de informação, você fica livre para implementar o que é mais adequado, mas vou dar umas sugestões.
Por exemplo, suponha que cada placa tem 4 relés. Você pode criar uma tabela em que o primeio byte é um comando e o segundo é um parâmetro. Por exemplo, o comando 01 pode ser o comando de ligar relé, o comando 02 para desligar, e o parãmetro é o relé a ser comandado. Para este comando a placa pode retornar o mesmo valor do comando no primeiro byte e 0x01 para comando executado com sucesso e 02 para não executado (por exemplo, por algum motivo o PC mandou ele comandar um relé que ele não tenha).
Suponha que as placa possuem um sensor de temperatura, de 16 bits. O PC mandando no primeiro byte o comando 0x81 para solicitar o valor do sensor, e no segundo 0x00 (que não serve para nada), e a placa responde no primeiro e segundo byte os valores do sensor de temperatura.
E por fim, você pode criar um comando de Hello, que a placa responde se ela estiver no barramento. Se o PC não receber resposta após um certo tempo (1 segundo, por exemplo), ele sabe que a placa não eá no barramento, ou tem algum problema. Dessa forma, você pode até fazer o software varrer o barramento para ver quem está presente. Na resposta do Hello, no primeiro byte por exemplo a placa pode responder com um byte que representa que tipo de placa ela é.

Conseguiu pescar a idéia? É um protocolo simples, mas funciona legal, eu fiz um semelhante, só que os frames tinham tamanho variável, com até 250 bytes de parâmetro, daí o byte logo em seguida do endereço dizia quantos bytes seriam transmitidos, mas a rotina de tratamento era basicamente o que eu mostrei acima, e está funcionando bem até hoje.

Espero ter ajudado...
98% das vezes estou certo, e não estou nem aí pros outros 3%.
Avatar do usuário
xultz
Dword
 
Mensagens: 3001
Registrado em: 13 Out 2006 18:41
Localização: Curitiba

Mensagempor ffkammer » 23 Out 2007 19:57

Boa noite Fábio e xultz, obrigado pelas respostas.

Xultz, sua idéia é realmente boa, acho que o Fábio tem razão que este é o melhor caminho a ser seguido.

Entendi sua idéia e achei ela muito boa e funcional.

Se você me permite vou vou te incomodar um pouco mais:

Não sei se você poderia me ajudar nesta parte, mas vamos lá: meu software é desenvolvido em Delphi (isto não dá prá trocar hoje) e eu estou usando um componente chamado TComPort para fazer a comunicação serial. A maior dificuldade que eu estou tendo é fazer com que meu software mande um comando e aguarde por X milisegundos uma resposta. Consigo escrever e ler a serial perfeitamente, mas sofro bastante para fazer o sincronismo do software com o equipamento serial. Por exemplo, o comando de hello, o meu software transmitiria ele na rede e teria que aguardar um tempo pré definido (timeout) pela resposta, caso não chegue neste período significa que o equipamento não está no ar, isto não estou conseguindo fazer. Conhece algo de Delphi? Poderia me auxiliar nisto?

Grande abraço
ffkammer
Bit
 
Mensagens: 23
Registrado em: 18 Out 2007 18:24

Mensagempor xultz » 23 Out 2007 20:04

Delphi? O que é isso? :)
Desculpe, eu realmente sou analfabeto de pai e mãe em Delphi, se você estivesse programando em C e em Linux, eu te daria umas rotinas prontas, qualquer coisa diferente, no PC, prá mim é... delphi.
98% das vezes estou certo, e não estou nem aí pros outros 3%.
Avatar do usuário
xultz
Dword
 
Mensagens: 3001
Registrado em: 13 Out 2006 18:41
Localização: Curitiba

Mensagempor ffkammer » 23 Out 2007 20:36

xultz escreveu:Delphi? O que é isso? :)
Desculpe, eu realmente sou analfabeto de pai e mãe em Delphi, se você estivesse programando em C e em Linux, eu te daria umas rotinas prontas, qualquer coisa diferente, no PC, prá mim é... delphi.


xultz,

Obrigado novamente... vai me desculpando pela ignorância, mas estou iniciando no desenvolvimento para comunicação serial. Tenho até que uma experiênciazinha em desenvolvimento com Delphi (desde 97), mas no desenvolvimento para comunicação serial sou novato.

Pelo que andei lendo sobre serial, acredito que devo implementar uma comunicação serial assíncrona para que meu sistema envie um comando e aguarde um retorno, isto? Só me confirme se é isto para que eu procure literatura sobre tal assunto.

Se você puder me dar uma idéia de como vc faz isto em C talvez eu possa implementar em delphi. Meu maior problema está sendo como fazer para enviar, aguardar e receber. Consigo transmitir e consigo receber, porém não consigo implementar o timeout.

Mais uma coisa... eu precisaria que o PIC também iniciasse a conversa na rede pois, como mencionado, este equipamento com o PIC tem o objetivo de substituir o computador em caso de uma pane neste. Desta forma este equipamento irá ter um chave que só poderá ser acionada quando o computador não estiver ligado. Então, se alguém pressionar esta chave o PIC deverá verificar se o computador está no ar, se sim, devolverá um retorno para o computador avisando que a chave foi pressionada, porém nada foi feito. Caso o computador não responda o PIC deverá fazer a comunicação com os equipamentos, enviando os comandos no lugar do computador.

Grato novamente,

Fabrício
ffkammer
Bit
 
Mensagens: 23
Registrado em: 18 Out 2007 18:24

Mensagempor xultz » 24 Out 2007 09:02

Sobre a primeira pergunta, o driver de serial C de saída é bastante simples, manda um byte e ele transmite.
Para receber, ele tem duas opções: a primeira, você manda ler o buffer de entrada, e ele espera um byte chegar e retorna. Se o byte não chegar, ele não retorna nunca, o que pode ser incômodo.
A segunda, você especifica um timeout, se o byte não chegar neste tempo, ele retorna um ponteiro nulo. Bem prático.

Sobre a segunda, existem várias maneiras de se fazer isso, mas uma forma prática é implementar um sistema de heart beat. Por exemplo, você faz o PC enviar a cada meio segundo um frame para o PIC que diz apenas "viu, eu ainda estou vivo, o Windows ainda não me travou" e o PIC responde "puxa, que bom, eu nunca travo". Se o PIC não receber um heartbeat em, digamos, dois segundos, ele assume que ele é o master, liga uma sirene dizendo que o computador deu pau, etc.
Quando o PC voltar à vida, ele fica esperando uma brecha no barramento (ou seja, espera uns 100 ou 200ms de inatividade no barramento) e manda um frame para o PIC dizendo que ele voltou à vida. Para isso, é importante que o PIC como master sempre dê uma brecha entre um comando e outro.

Esta é apenas uma das maneiras...
98% das vezes estou certo, e não estou nem aí pros outros 3%.
Avatar do usuário
xultz
Dword
 
Mensagens: 3001
Registrado em: 13 Out 2006 18:41
Localização: Curitiba

Mensagempor ffkammer » 24 Out 2007 10:06

xultz escreveu:Sobre a primeira pergunta, o driver de serial C de saída é bastante simples, manda um byte e ele transmite.
Para receber, ele tem duas opções: a primeira, você manda ler o buffer de entrada, e ele espera um byte chegar e retorna. Se o byte não chegar, ele não retorna nunca, o que pode ser incômodo.
A segunda, você especifica um timeout, se o byte não chegar neste tempo, ele retorna um ponteiro nulo. Bem prático.

Sobre a segunda, existem várias maneiras de se fazer isso, mas uma forma prática é implementar um sistema de heart beat. Por exemplo, você faz o PC enviar a cada meio segundo um frame para o PIC que diz apenas "viu, eu ainda estou vivo, o Windows ainda não me travou" e o PIC responde "puxa, que bom, eu nunca travo". Se o PIC não receber um heartbeat em, digamos, dois segundos, ele assume que ele é o master, liga uma sirene dizendo que o computador deu pau, etc.
Quando o PC voltar à vida, ele fica esperando uma brecha no barramento (ou seja, espera uns 100 ou 200ms de inatividade no barramento) e manda um frame para o PIC dizendo que ele voltou à vida. Para isso, é importante que o PIC como master sempre dê uma brecha entre um comando e outro.

Esta é apenas uma das maneiras...


Bom dia xultz, obrigado novamente pela ajuda, está me ajudando bastante.

Esta noite estudei um bocado sobre como fazer a implementação da comunicação serial aguardando um retorno. O que eu acho que terei de fazer é retirar a rotina que lê a serial de dentro de uma thread e colocá-la na thread principal de meu sistema, dessa forma eu fico aguardando um retorno na serial... estou estudando a forma de implementar o timeout agora.

Sobre o heart break eu tentarei colocá-lo em prática, só fiquei um pouco preocupado em como fazer para não atrapalhar o PIC nas suas transmissões... terei que fazer algo bem sincronizado, por exemplo, eu sei que o PIC transmite de 500ms em 500ms, então eu aguardo uns 200ms e daí eu envio o aviso de ressureição ao PIC... vou tentar colocar esta idéia em prática ainda hoje...

Grande abraço...

Fabrício

Grande abraço...

Fabrício
ffkammer
Bit
 
Mensagens: 23
Registrado em: 18 Out 2007 18:24

Mensagempor ze » 24 Out 2007 15:10

olá fabrício.
veja como coloquei time out em uma rotina de serial no delphi:

Código: Selecionar todos
function Tcomunica.recebyte(endporta:integer):byte;
begin
tmout:=0;
 while ((inportb(lsr) and $01)=0) and (tmout<2) do Application.ProcessMessages; {aguarda receber o byte}
 recebyte:=inportb(endporta);
txtser:=inttostr(inportb(endporta));
end;


o tmout é incrementado num timer 50mS.

Veja como implementei o acesso ao inpout32.dll (gratuito, baixável, tem até o fonte):

Código: Selecionar todos
procedure outportb(EndPorta: integer; Valor:BYTE); stdcall; external 'inpout32.DLL' name 'Out32';
function inportb(EndPorta: integer):byte; stdcall; external 'inpout32.DLL' name 'Inp32';


e para carregá-lo:

Código: Selecionar todos
procedure Tcomunica.FormCreate(Sender: TObject);
begin
  Inpout32 := LoadLibrary('inpout32.dll');
  if Inpout32=0 then MessageDlg('Sem Dll.', mtInformation,[mbOk], 0);
setbaud(9600);
end;


A rotina para enviar o byte


Código: Selecionar todos
procedure Tcomunica.sendbyte(d:byte);
begin
 outportb(TXB,d);  {coloca o byte no buffer serial}
 while (inportb(LSR) and $20)=0  do; {aguarda tansmitir o byte}
 tmout1:=0;
 while (recebyte(RXB)<>d) and (tmout1<2) do Application.ProcessMessages;

 if tmout1>=2 then shape2.Brush.color:=clred
 else shape2.Brush.color:=cllime;

end;



endereços de portas:

Código: Selecionar todos

const   TXB: integer=$3f8; {BUFFER DE TRANSMISSÃO}
        RXB: integer=$3f8; {BUFFER DE RECEPÇAO}
        DLL: integer=$3f8; {LATCH PARA DIVISOR LSB}
        DLM: integer=$3f9; {LATCH PARA DIVISOR MSB}
        IER: integer=$3f9; {HAB. DE INT.}
        IIR: integer=$3fa; {IDENT. INT.}
        LCR: integer=$3fb; {CONTROL. DE LINHA}
        MCR: integer=$3fC; {CONTROL. DE MODEM}
        LSR: integer=$3fd; {ESTADO DE LINHA}
        MSR: integer=$3fe; {ESTADO DE MODEM}
        SCR: integer=$3ff; {USO GERAL}
        PPORT: integer=$378;


Desta forma o acesso à serial (ou à qualquer porta) ficou igual ao meu querido C. (inportb, outportb). E o legal:funciona no XP! É claro, tem que ter permissão para o acesso às portas (no Vista, não sei). Complica um pouco + para leigo configurar baud rate p. ex. [O programador] tem que ter conhecimento do hw do pc.(se acessar portas erradas pode travar o micro!). Fiz este programa há alguns anos. Era para o PC mostrar a temperatura (e otras cositas) de um forno com pic.
Meu conhecimento de delphi é limitadíssimo (quase infantil). Não me enveredei por ele. Portanto, não faça perguntas.[difíceis]. Mas tudo que sei, está a sua disposição.
Não sei se tem a ver com seu timeout e, como postei só parte do código, não sei se é entendível.

Espero que [não] lhe seja [in]útil.
Abraço
Avatar do usuário
ze
Dword
 
Mensagens: 1655
Registrado em: 05 Jun 2007 14:32

AnteriorPróximo

Voltar para PIC

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

x