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 (demasiados) componentes externos? Mi primer acercamiento fue usar un MCP2515, pero ahí ya necesito un reloj externo. ¿Hay una manera más barata de hacer eso?
Si tiene un problema con los protocolos en serie como SPI de más de 5 metros, la respuesta simple es reducir la frecuencia de reloj para recibir datos de dispositivos remotos. Ir a algo como CAN no es una solución simple para mi forma de pensar, pero, por supuesto, es posible que deba hacerlo si las distancias lo justifican y no puede reducir la velocidad PERO piense en esto ...
Poner un micro en ambos extremos (o el extremo remoto) para permitir comunicaciones de tipo CAN significa que su rendimiento general de recuperación de datos de un dispositivo remoto será limitado sin tener que pasar a una tasa de datos significativamente más alta a través del enlace CAN y tendrá para 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 CE, tendrá que enviar una solicitud más formal para que se le devuelvan los datos remotos.
La forma más sencilla es reducir la velocidad del reloj para adaptarla al cable y, si es necesario, usar controladores y receptores balanceados, es decir, hacer que todo funcione con el retraso que 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 medida sincronizados, pero tratar de recuperar los datos es el verdadero problema en largas distancias: el dispositivo receptor obtiene el reloj y sincroniza sus datos con el reloj entrante, pero por en el momento en que regresa al maestro, las cosas están sesgadas entre sí.
Es por eso que 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.
Si puede prescindir de un par trenzado adicional, puede optar por RS485. Usaría dos pares trenzados, uno para datos y otro para control de dirección, o podría ir semidúplex 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 esclavo al transmitirle, y deshabilitaría la salida maestra cuando se espera que el esclavo esté transmitiendo.
Estaba en una situación similar tratando de enviar una señal a través de i2c, pero mi distancia era mucho mayor. Estaba usando cable CAT5. Tenía una configuración bastante cursi para probar la idea. Había configurado un circuito para usar un chip extensor i2c (esto era para que 2 arduinos hablaran entre sí). Creo que frié uno o ambos chips en algún momento, así que simplemente conecté el circuito (saqué los chips de sus enchufes y pasé cables de puente muy cortos básicamente entrecruzando las líneas LxSy y SxLy). De todos modos, sin entrar en demasiados detalles, pude obtener la señal a través de unos 100 pies de CAT5. Es posible que desee probar antes de darse por vencido o asumir que no funcionará. De lo contrario, puede probar los diversos chips extensores de bus i2c que existen. Los circuitos son simples y los chips no cuestan mucho (TI y NXP los hacen P82B715PN).circuito extensor de bus i2c
sweber
Cuchara
arc_lupus
Stanri
Pedro Mortensen
arc_lupus
Sincrondino