Ringrazio Marco M. che riapre il diabattito proponendo CAN bus come alternativa al bus RS485.
CAN è il bus utilizzato nelle automobili moderne, negli apparecchi elettromedicali e nell’industria.
Sicuramente alza di molto il profilo e quindi va provato.
Ma il grande problema è nei costi alti, per esempio, la sicuramente ottima scheda della SparkFun CAN-BUS Shield DEV-10039 sarebbe un’eccellente scelta ma costa più del doppio della scheda microcontroller.
Un po’ di tempo fa volevo avviare dei test soprattutto verso il bus dell’automobile.
E’ interessante il post tratto dalla pagina del prodotto Sparkfun:
“If you are using this board to actually create a CAN bus system (as I am for a robotic drone vehicle) then the skpang (designer of this board) code is not that helpful and a bit of a mess. It is well and good to be able to read things from your vehicle and log them, but that’s not helpful when you are trying to create an actual bus.Also, I really find it difficult when sample code does every conceivable thing all at once, forcing you to piece out the parts/understanding you need.
To create a network of senders and receivers, I tried a few different libraries. I recommend using the CANDUINO one http://code.google.com/p/canduino). Although the boards are not exactly the same, it will work, and you can see a sender and receiver working. Other libraries I tried, such as the one from saeed studios, didn’t work for me, even though their boards are pin compatible. Might have something to do with their library using a CAN interrupt which, for me, was not reliable. Receiver would get only a single CAN message and then the interrupt would never fire again. Who knows why. Spent a number of hours on this.
So just want to save other folks some time if they are looking to build an actual bus system, and not just read data from their vehicles.”
La scheda utilizza il componente elettronico MCP2515 che si collega verso Arduino mediante SPI.
La porta SPI, che è una seriale molto veloce adatta per esempio per collegare CAM SPI, ma apre alcune problematiche spinose con Arduino: non rientra nel contesto usuale gestire più di una SPI, che viene utilizzata in modo esclusivo da atre periferiche quali lettore SD oppure (aut) dalla scheda ethernet. E’ noto che chi ha utilizzato l’ethernet shield, il programma che inserisce non può aprire contemporaneamente la scheda rete e un file in SD.
La gestione SPI su Arduino è piuttosto complessa.
L’alternativa è usare I2C o wire, bus molto più lento, creato dalla Philips come seriale veloce per interconnettere componenti elettronici, per esempio la scheda madre con i suoi sensori. Ma si aprono molte problematiche: le tensioni in gioco sono i 3.3 o i 5V e sono piuttosto delicate, è delicato convertire il segnale tra tensioni, il cavo non può superare grossomodo il metro e mezzo, un componente instabile sul bus può compromettere la comunicazione, …
Molti invece sono i motivi a favore del I2C: è il più diffuso bus tra componenti elettronici, quindi ci si apre alla comunicazione con l’elettronica, la libreria I2C per Arduino è abbastanza stabile, Grove ha un HUB per I2C per Arduino, ….
Arduino gestisce in origine la seriale usata per comunicare verso USB, PIN 2 e 3, con il secondo microcontroller a board (il vecchio chip FTDI è superato).
La libreria seriale poi è stata affiancata da una libreria migliore che permette di gestire più coppie di pin in contemporanea, quindi avere più seriali TTL. Il chip MAX485 incanala la coppia di PIN al bus RS485.
Il segnale è bilanciato, collaudatissimo, può arrivare a 1200 metri, richiede due resistenze di terminazione. Le velocità sono quelle della seriale. Il protocollo è da perfezionare.