Comunicar entre PICs: I2C, can, uart, etc ...

[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

[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

[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é +

[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

[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.

[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

[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.

[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

[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í...

[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?

[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

[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é+