ASM51

Boa tarde pessoal,

Estou pensando em construir um circuito RS-485 conectado a um 8051 full duplex para evitar de direcionando a comunicação. Deixando assim bem semelhando a uma comunicação RS-232.

Alguma sugestão ?


O circuito que pretendo usar é este,

Sinto muito em lhe informar, mas já tiveram esta ideia antes de você, e ainda deram um nome prá esse protocolo: se chama RS422.
Vai na fé que funciona.

Valeu xultz, pesquisando achei um circuito bem parecido.

Uma outra dúvida, será que tem como conectar esse circuito com um equipamento com 485 ?

Pensei nesse esquema de ligação, porem algo me diz que não funcionará. Alguma sugestão ?

Se o transceiver do TX ficar com o enable ligado, você deixará o barramento setado e o outro device não irá conseguir utilizá-lo.

É, pelo jeito vou ter que arrumar uma porta de i/o para controlar o R/D. Obrigado a todos.

É a forma mais barata.
Existem "repetidores" de sinal RS485 bidirecionais que controlam o enable com um temporizador. Ele sobe quando detecta o start bit e desde após um silêncio de N bits no barramento.

Olá, longo.251272


Eu trabalhei a uns anos atrás, bem lá atrás, com esse drive,

Eu usava ele para comunicação dentro do protocolo DMX512.

Salvo engano e se eu entendi direito, esse driver, não é rx tx? Eu não me lembro direito,

Porque então usar dois drivers, se você pode fazer a comunicação com um apenas...

Se falei abobrinha, peço desculpas..

Bom dia Vonnilmam,

Um driver só não consegue enviar e receber ao mesmo tempo, sendo necessário controlar a porta que determina se está enviando ou recebendo. Como a intensão era aplicar uma RS-485 no lugar de uma RS-232 não vi como controlar essa porta que determina se está enviando ou recebendo e ai veio a idéia de usar dois drivers um direcionado pra transmitir e outro pra receber.

Um abraço
Ricardo

Bom dia, longo.251272


Meu amigo, eu não sei qual é a prioridade da sua aplicação, mas vamos ver se consigo te ajudar com o pouco de entendimento que nós temos.

Realmente eu peço desculpas, o RS485 é half duplex, ele envia ou recebe dados, e o controle do fluxo é através de um pino de controle, se RX ou TX.

Eu trabalhei muito com DMX512, para quem não sabe é um protocolo que trabalha a uma velocidade razoável (250kbps "dependendo da aplicação essa velocidade pode ser alterada"), e o formato do protocolo é muito simples e eficiente. Apesar dele ser indicado e criado para trabalhar no controle de fluxo de dados entre equipamentos microcontrolados, ele também pode ser utilizado para diversas outras aplicações onde se deve ter controle, com rapidez e eficiência, porém de forma muito simples.

O protocolo (http://www.iar.unicamp.br/lab/luz/ld/C% ... mx_512.pdf), utiliza o rs485 para fazer a comunicação entre equipamentos, e é muito bem tolerante a ruídos, exemplo, ele é ou era utilizado em equipamentos de iluminação (quer ambiente mais ruidoso que esse?).

Salvo engano, eu acho que com pequenas modificações no conteúdos dos dados desse protocolo, você pode formar uma comunicação RX TX (half duplex), muito eficiente. Inclusive com acknolege de retorno.

DMX512 sempre achei que fosse unidirecional......

Então DMX512 é um protocolo de comunicação, porém foi elaborado da forma mais simples possível para ganhar velocidade de comunicação.

Originalmente você tem um "mestre" e os "escravos", porém nada impede de você criar uma rede de comunicação "fechada" adicionando novos pacotes de dados dentro do protocolo afim de interagir, "mestre" com escravos", eu já fiz isso a muito muito tempo atrás, justamente porque precisava de algo bem simples em termos de protocolo e que fosse rápido o suficiente na troca de informações.

Na época achei muito "robusto" os protocolos existentes comumente utilisandos em pcs e o que eu precisava era apenas de identificação, e sinais de alerta e de quem era a vez de "falar" e os demais escutarem...

Por isso perguntei ao criador do post, para qual aplicação ele iria utilizar...

O que eu tenho visto é que muitos programadores de grandes empresas, utilizam os protocolos comuns por assim dizendo, afim de manter uma linguagem de comunicação amigável dentro de certo ambiente, porém noto que acaba-se criando dentro do proprio protocolo ( e isso é perfeitamente aceitável ), uma série de macro protocolos internos ao protocolo padrão, para comunicação restrita entre equipamentos da família, tipo o protocolo MIDI com suas tramas sisex..salvo engano...

A rs485 apesar de ser half, tem ótima estabilidade a longas distância e muito bem tolerável a ruidos, inclusive EMI...

Dependendo também da aplicação do nosso amigo, não seria interessante fazer isso via bluetooth ou utilizar wifi...

Obrigado a todos.

Boa noite pessoal,

A aplicação é para facilitar a entrada de dados em 20 CLP's dedicados que estão equipando uma máquina. Para o usuário não ter que ir um a um digitando os dados vou colocar uma IHM que vai mandar via RS485 os dados para os CLP's. Esses CLP's tem saída 232 e I2C no conector externo.

Num primeiro momento pensei em utilizar um conversor RS232-RS485 e utilizar o microcontrolador para controlar o protocolo e ir jogando os dados na EEPROM que está no I2C.

Mas depois de ver que o espaço de memória disponível no microcontrolador está reduzido, estou chegando a conclusão que é melhor eu montar um circuito com um microcontrolador com barramento I2C e RS485, ele vai ler os dados vindo da IHM e jogar direto no barramento I2C assim não vou nem precisar parar o processo da máquina pelo fato de não depender do microcontrolador do CLP.

Oque acham ?

Se for CLP´s o mais fácil é usar o Modbus, pelo menos a maioria dos CLP´s tem um e se usar um compilador CCS já tem as libs prontas......