Página 1 de 1
Comunicar entre PICs: I2C, can, uart, etc ...

Enviado:
20 Out 2006 08:50
por lmdmendes
Ola a todos
Eu tenho uma duvida, que é qual a melhor forma para comunicar entre PICs?
Eu tenho um PIC que esta a receber informação de um dano numero de sensores, ele trata a informação e termina por a deixar em apenas três registo de 8bits, essa informação actualizada é necessaria noutro PIC central que esta a controlar todo o processo, a minha duvida é qual é melhor forma para comunicar entre eles, para enviar esses valores?
Pela UART, para usar o bootloader no PIC Central, não poderei usar, rede can, tambem penso que para usar o bootloader também não poderei usar, errado?
Quanto ao I2C, nunca usei, não sei como usar, o I2C não é o protocoologo para comunicar com um EEPROM série do tipo 24C04? Como se usa para comunicar entre PICs? Escrevesse numa EEPROM e depois o outro PIC esta a ler de la? ou vai escrever na EEPROM interna do outro PIC, não faço a minima ideia de como o I2C funciona entre PICs, talvez estou a dizer uma grande disparate aqui
Se possível, gostaria que me explicassem com funciona e qual as principais vantagens em usar I2C, qual a melhor solução para o meu caso, pois para facilitar a programação no PIC central o melhor era ter acesso directo a essas 3 variáveis que o outro PIC tem sem grandes complicações, mas não sei como fazer.
Agradeço a vossa atenção
LMDMendes
Re: Comunicar entre PICs: I2C, can, uart, etc ...

Enviado:
20 Out 2006 10:36
por castocco
Bem, os protocolos I2c e Spy sao para niveis de placas, ou seja vc nao pode ligar a uma distrancia longa.
Para comunicacao a nivel de wardware pode-se utilizar o I2c ou Spy cuja o codigo eu postei neste forum.
Para comunicacao a uma distancia maior, necessita-se de outros protocolos, o mais facil de implementar seria a RS232.
Atenciosamente
Carlos

Enviado:
20 Out 2006 10:58
por Fábio Pereira
A resposta para a sua pergunta é bem complicada, tudo vai depender de fatores como velocidade de comunicação, distância, meio de transmissão, etc.
Sobre bootloader, é possível implementá-lo utilizando qualquer protocolo, de SPI a CAN, seja ele com fio ou sem fio. Tudo vai depender da implementação.
Sobre o I2C, é um protocolo síncrono mestre-escravo. Cada dispositivo da rede tem um endereço. O dispositivo mestre envia um pacote com o endereço do escravo que ele deseja conversar e assim por diante. No I2C também é possível ter múltiplos mestres no mesmo barramento.
Até +

Enviado:
20 Out 2006 16:42
por lmdmendes
Eu quero usar um destes protocolos, não para comunicar a uma longa distancia longa, é apenas para comunicar entre placas, para ser mais preciso, é na construção de uma pequeno robô no qual estou a trabalhar, na qual tenho o controlo de todos os sensores feito por um PIC o qual, depois de tratar essa informação da 3 únicas variáveis para o PIC principal, para desta forma ter a programação no PIC central mais bem estruturada, sem desta forma ter que me preocupar no tratamento de todos os sinais de cada sensor.
Quanto a tua informação Fábio:
"Sobre o I2C, é um protocolo síncrono mestre-escravo. Cada dispositivo da rede tem um endereço. O dispositivo mestre envia um pacote com o endereço do escravo que ele deseja conversar e assim por diante. No I2C também é possível ter múltiplos mestres no mesmo barramento."
Ate ai já compreendi, mas então quando manda a informação com o endereço do escravo, este activa uma interrupção correcto? Para receber o valor, depois com esse valor o escravo faz o q vem entender? Ou da para definir no mestre onde vai guardar aquela informação no escravo?
Este tipo de comunicação com uma constante actualização de valores, não vai travar o desempenho do dispositivo escravo?
Um Abraço
Mendes

Enviado:
20 Out 2006 17:26
por Renie
Olá Luis!
Dê uma olhada no tutorial para memórias 24xxx I2C que tem no meu site,
mesmo não sendo o seu caso, ele tem informações do protocolo.
Para seu caso, creio que seja mais fácil usar a USART, pois até um
simples 16F628 tem esta facilidade, sendo de uma placa direto para
outra e próximas, pode ligar direto a saída de um PIC na entrada do
outro, não precisando nem dos MAX232 da vida.

Enviado:
20 Out 2006 19:51
por Visitante
Obrigadão Renie, como não podia falhar o teu tutoria esta muito bom, mesmo muito bom, mas essa era mesmo a ideia que eu tinha ca comunicação I2C com as memorias Série, do tipo 24Cxx, mas nunca vi como é nos PICxPIC, dai eu questionei, pois se funcionar como nas memorias, uma pessoa e só dizer a posição e ele escreve, ou lê dessa posição, correcto? mas n sei se funciona como na memorias, dai perguntar, pois se for como as memorias, para mim era muito útil, caso seja qual a solução mais rápida? O PIC dos sensores ser master e escrever no PIC central os valores actualizados? Ou o Central ser o master e ir directamente ao outro ler os dados?
Mendes

Enviado:
20 Out 2006 22:31
por Renie
Como eu disse, acho que no seu caso a USART é mais fácil:
- não precisa de endereço.
- a USART gera interrupção, seu mestre pode se preocupar com outras
coisas que será avisado quando necessário.
- O buffer da USART do PIC mais simples suporta suas 3 variáveis sem
overflow.
- Nos PICs mais simples não tem I2C por hardware, terá que ser
implementado por soft (ex o F628).
Eu não lembro da velocidade máxima da I2C dos PICs (se não me
engano 400Kbits), levando em conta que é necessário enviar o endereço
junto, essa velocidade cai mais em relação a Bytes úteis; a USART
não precisa de endereço, alcança grandes velocidades.
Como creio que seu robo não fará nenhuma cirurgia milimétrica de
alto risco

, a USART é a opção mais simples e adequada.

Enviado:
21 Out 2006 11:01
por lmdmendes
Obrigado Renie
Mas mesmo assim não respondeu a minha grnade duvida sobre o funcionamento do I2C entre PICs, nos PICs que tem I2C por hardware, que e o meu caso, como funciona? Vais escrever dentro da EEPROM do micro escravo? (se, sim, como esta por hardware, não intrefere no software, n interrompendo o processo do softeare)
Estas duas vairaveas sao estar a ter actualizadas muitas vezes por segundo, dai pela UART, não sei, mas penso que vai estar muito contantemente a gerar interrupções ficando o software mais lendo ou não?
Um Abraço
Mendes

Enviado:
21 Out 2006 11:14
por Fernando Guimarães Aguiar
Olá lmdmendes,
Se vc tiver usando PIC com controlador CAN (18F), uma boa opção poderia ser utilzar CAN. É um protocolo muito bom para comunicação multiponto, e se baseia na topologia multi-mestre, sendo que no protocolo já está implementado priorização de transmissão, retransmissão, CRC, etc.
É um protocolo de simples implementação haja visto que a maioria dos compiladores já tem bibliotecas CAN.
Particulamente, trabalho com transmissão utilizando protocolo CAN na comunicação entre PICs, e só tenho boas cosiderações a fazer.
PS.: Para utilizar CAN é necessário um transceiver, o MCP2551 (Microchip), que é muito simples de ser utilizado.
No mais é isso aí...

Enviado:
21 Out 2006 13:32
por lmdmendes
Eu também quero experimentar a rede CAN, mas alguém podia me esclarecer a minha duvida de como funciona na pratica o I2C entre PICs?

Enviado:
13 Abr 2007 08:29
por painho
Eu to usando a paralela para comunicar entre dois PIC a velocidade esta acima de 1mbits/s ta bom mas to usado 10 O/I, tentei I2C e SPI mais como tinha que ficar alterando escravo e mestre tava dando um delay muito grade
Se vc estiver um pic mandando e o outro so recebendo pode I2C ou SPI

Enviado:
13 Abr 2007 13:25
por Ander_sil
Não se tem muita documentação sobre I2C entre PIC à PIC, o mais comun é o uso do SPI e da UART.
O I2C usa muito de software, quero dizer, endereço do device e código do device por software, já SPI não tem muita frescura é só habilitar o CS do escravo e manda bytes.
No meu ponto de vista é melhor usar a serial ou a SPI, pois a I2C vai dar muito trabalho.
até+