La forma más barata de obtener una señal CAN

1

Tengo que transferir señales a unos cinco metros. Mis señales de entrada son compatibles con I2C o SPI, pero desafortunadamente no es una buena idea transmitirlas a una distancia tan larga. Por lo tanto, estaba pensando en convertir la señal I2C o SPI en una señal CAN (y viceversa). ¿Cuál es el mejor enfoque para convertir estas señales entre sí sin tener que usar (demasiado) componentes externos? Mi primer enfoque fue usar un MCP2515, pero ya necesito un reloj externo. ¿Hay una forma más barata de hacerlo?

    
pregunta arc_lupus

3 respuestas

6

Si tiene un problema con los protocolos serie como SPI a más de 5 metros, la respuesta simple es reducir la velocidad de reloj para recibir datos desde dispositivos remotos. Ir a algo como CAN no es una solución simple para mi forma de pensar, pero, por supuesto, esto puede ser necesario si las distancias lo justifican y no puede bajar la velocidad, PERO piense en esto ...

Poner un micro en ambos extremos (o el extremo remoto) para permitir las comunicaciones de tipo CAN significa que su rendimiento global de recuperación de datos desde un dispositivo remoto se limitará sin tener una velocidad de datos significativamente mayor a través del enlace CAN y usted Tendremos que adaptar su transmisión SPI maestra actual para que sea compatible con CAN y esto podría significar que, en lugar de simplemente enviar un reloj SPI y un CE, tendrá que enviar una solicitud más formal para que los datos remotos le sean devueltos.

La forma más sencilla es reducir la velocidad del reloj para adaptarse al cable y, si es necesario, utilizar controladores y receptores equilibrados, es decir, hacer que todo funcione con la demora que se obtiene al introducir los 5 metros de cable. Es fácil cuando se envían datos a un dispositivo remoto: tanto el reloj como los datos llegan en gran parte sincronizados, pero tratar de recuperar los datos es el verdadero problema en largas distancias: el dispositivo receptor recibe el reloj y sincroniza sus datos con el clk entrante, pero por El momento en que vuelve al maestro las cosas están sesgadas una respecto a la otra.

Por eso sugiero considerar la reducción de la velocidad del reloj: los sesgos no serán tan malos (como porcentaje) y es menos probable que den errores.

    
respondido por el Andy aka
4

Si puede ahorrar un par trenzado extra, podría usar RS485. Usaría dos pares trenzados, uno para datos y otro para control de dirección, o podría hacer dúplex medio con un par para cada dirección.

En el caso de datos / dirección, usaría la línea de control de dirección para deshabilitar la salida en el extremo del esclavo cuando se le transmite, y deshabilitar la salida maestra cuando se espera que el esclavo esté transmitiendo.

    
respondido por el WhatRoughBeast
0

Estaba en una situación similar tratando de enviar una señal a través de i2c, pero mi distancia era mucho mayor. Yo estaba usando el cable CAT5. Tenía una configuración bastante tonta para probar la idea. Instalé un circuito para usar un chip extensor i2c (esto fue para que dos arduinos se hablaran entre sí). Creo que frié uno o los dos chips en algún momento, así que simplemente conecté el circuito (saqué los chips de sus enchufes de inmersión y corrí cables de puente muy cortos que cruzaban básicamente las líneas LxSy y SxLy). De todos modos, sin entrar en demasiados detalles, pude obtener la señal a través de aproximadamente 100 pies de CAT5. Es posible que desee probar antes de darse por vencido o asumir que no funcionará. De lo contrario, puedes probar los distintos chips de extensor de bus i2c que hay. Los circuitos son simples y los chips no cuestan mucho (TI y NXP los hacen P82B715PN). Este enlace (en francés) es de lo que salí de i2c bus extensor circuit

    
respondido por el john bower

Lea otras preguntas en las etiquetas