Dovendo pilotare alcuni shift register SN74HC595 (clock, latch e data) da un Arduino Uno che si trova ad una decina di metri di distanza, m'è balenato in mente di utilizzare dei transceiver del tipo usato anche per le comunicazioni RS485. In pratica, il segnale "data" andrebbe sul driver di uno di questi transceiver (perennemente in trasmissione), quindi cavo twistato fino al ricevitore (perennemente in ricezione), dopodiché il segnale sul pin R di quest'ultimo trasnceiver lo mando al pin giusto dello shift register. La cosa, ovviamente, va fatta per "data", "clock" e "latch", quindi in tutto saranno 3 coppie di cavi twistati e 6 transceiver.
Quanta percentuale di fesseria c'è in questo mio ragionamento?
Altrimenti, cosa posso fare per ovviare al mio problema? Non vorrei mettere un altro Arduino nei pressi dello shiftregister, perché poi mi complicherei ulteriormente la vita cercando di farli comunicare senza problemi (tenendo presente che mi è rimasta pochissima memoria disponibile, e se caricassi anche solo la libreria ModBus me la sarei giocata).
Ops...credevo d'averlo fatto tempo fa, ma a quanto pare sbagliavo.
Ho provveduto...
Integro la mia richiesta: ho letto dell'esistenza di SPI Extender, per aumentare la distanza a cui può lavorare un segnale SPI. Esiste una cosa del genere anche per i semplici segnali I/O di Arduino? Non mi interessa aumentare il numero di porte, ma la distanza a cui posso veicolare il segnale senza problemi.
pdbc75:
m'è balenato in mente di utilizzare dei transceiver del tipo usato anche per le comunicazioni RS485. In pratica, il segnale "data" andrebbe sul driver di uno di questi transceiver (perennemente in trasmissione), quindi cavo twistato fino al ricevitore (perennemente in ricezione), dopodiché il segnale sul pin R di quest'ultimo trasnceiver lo mando al pin giusto dello shift register. La cosa, ovviamente, va fatta per "data", "clock" e "latch", quindi in tutto saranno 3 coppie di cavi twistati e 6 transceiver.
In teoria funziona, in pratica è da verificare, mai provato a fare una cosa simile, solitamente in questi casi preferisco delegare una piccola mcu, di quelle che costano 1 Euro, come interfaccia tra la 485 e il device.
Ti ringrazio del consiglio.
Se non ho capito male, dovrei lasciar stare i segnali data, latch e clock, e passare direttamente su RS485 il byte da trasferire allo shift register. Dall'altra parte ci sarà un ATtiny che tradurrà il byte in data, latch e clock.
Come protocollo di comunicazione su RS485? ModBus mi sembra oltremodo esagerato. Mando una stringa e la interpreto dall'altro lato, senza tanti fronzoli e con buona pace dei messaggi di ACK ?
Rimane ancora in piedi, comunque, la possibilità che esista un I/O Extender, alla stessa stregua degli SPI Extender. Consigli in merito?
Puoi usare un transrecevier 485, un tiny 85 e l'SN74HC595, oppure, se puoi sostituire l'SN74HC595, metti direttamente un transrevevier 485 con un tiny84 dove programmi 8 uscite come shift-register.
Devi contare se ti bastano i pin sull'84 però.
Con Tiny85 ce la fa solo se elimina il pin usato per la commutazione del 75176 e lascia questo fisso in ricezione.
Perché 2 fili per RX/TX ed un filo per la commutazione, siamo a 3 pin. Poi altri 3 pin per i comandi allo shift register. Siamo a 6 pin. Il Tiny85 ne ha solo 5 usabili.
Scusate l'ignoranza, ma dal datasheet dell'ATtiny85 vedo che le porte I/O sono 6, quindi ce la farei. Oppure il pin "reset" è meglio lasciarlo stare come Reset?
Il pin di reset è meglio lasciarlo stare come reset, a meno che tu non sappia come fare per rimetterlo a posto, e per farlo o hai un programmatorino H/V (come questo o quello presentato dall'utente Menniti sulla rivista E.In) oppure sia dotato di un programmatore professionale capace di operare ad alta tensione per riportare ai valori di fabbrica il chip. Se imposti il pin di reset come I/O poi non puoi più né spedirgli un nuovo sketch (serve il reset per avviare la programmazione) né rimettere il pin come linea di reset. A meno di non operare a 12V, appunto.
Il pilotaggio di una periferica seriale sincrona non è affatto una cosa insolita , si fa da decenni su macchinari di ogni tipo, solo son usare il sn75176 che è per la RS485.
ma usa il 26ls31 per la trasmissione da arduino e il 26ls32 per il SN74HC595 che sono fatti apposta per la RS422.
con una frequenza di clock di 10-20khz puoi portare il pin expander anche a 100 metri
Un piccolo follow up a favore di quelli che si imbattono in questo topic.
Allora:
ho fatto una prova della mia idea, ed ho trovato che lo shift register è pilotabile da RS485. Nel senso: i tre segnali "latch, clock, data" in uscita da Arduino vanno sui driver di 3 SN75176 (in cui i piedini notOE e DE sono fissi a livello HIGH). Da qui partono 3 coppie di cavi twistati verso i ricevitori (pin notOE e DE fissi a livello LOW), i cui pin Receiver sono collegati ai pin giusti dello shift register. Ho testato il tutto con lo sketch del tutorial "shiftOut", quindi non lo riporto.
alla fine ho seguito il consiglio sugli ATtiny 85. Praticamente da un pin Arduino (Tx di una SoftwareSerial) invio un comando molto semplice (due byte: indirizzo e byte da passare allo shift register S/P) tramite RS485 (quindi SN75176 con notOE e DE fissi HIGH da una parte e fissi LOW dall'altra). L'ATtiny è stato programmato (dopo averlo portato a 8MHz per consentirgli di utilizzare la libreria SoftwareSerial) per controllare il primo byte ricevuto e se corrisponde al suo indirizzo (fisso in fase di programmazione) prende il secondo byte e lo passa allo shift register S/P. Finito. Ed ho risparmiato pure sui cavi da passare (tre poli più alimentazione e GND per pilotare lo SR contro due poli più alimentazione e GND per inviare il comando all'ATtiny)
la questione della RS422 l'ho abbandonata non perché non mi piacesse, ma perché avevo in giro per casa già un po' di SN75176. Comunque ho dato uno sguardo ai datasheet, ed effettivamente era un'ottima soluzione. Lo terrò a mente per la prossima volta.
