Vai al contenuto
PLC Forum


Comunicazione Tra Arm


kikko77

Messaggi consigliati

Buongiorno, è un pò di tempo che non scrivo sul forum, quindi saluto tutti.

Di recente sto lavorando con microcontrollori ARM cortex M3, ora sorge la necessità di far comunicare due o più controllori tra di loro con tempi molto bassi, cioè mi servirebbe far comunicare in modo molto veloce 3/4 schede di mia costruzione tra di loro con un bus.

L' architettura che ho pensato è con una scheda Master con il suo micro che contiene il programma di funzionamento centrale e una serie di altre schede con relativi micro di periferia che svolgono il lavoro di I/O.

Chiedo quindi quale potrebbe essere questo tipo di bus e se esiste già qualcosa nei sistemi arm da utilizzare

Link al commento
Condividi su altri siti


Ciao,

Probabilmente c'è bisogno di qualche info in più ....

in un PC ci sono diverse schede che comunicano tra loro, alta velocità bassa distanza

in auto ci sono diverse schede che comunciano tra loro

in un impianto industriale ci sono diverse schede che comunicano tra loro.

Come puoi vedere da definire anche l'ambito applicativo, le distanze e la velocità ( in maniera deterministica).

Link al commento
Condividi su altri siti

RESNIC+19/01/2012, 14:05--> (RESNIC @ 19/01/2012, 14:05)

Effettivamente hai ragione mi è rimasta qualche informazione nella testa...

1) L'ambiente è di tipo industriale (per capirsi le schede sono all'interno di un quadro elettrico)

2) La velocità che di cui ho bisogno è la più alta possibile ma ragionevolmente un millisecondo potrebbe andare bene

Grazie delle info

saluti

Link al commento
Condividi su altri siti

In ambito industriale ci sono diversi protocolli, dal Modbus su Rs232 oppure RS485 al Modbus TCP su Ethernet, opppure protocolli CanOpen o Devicenet su Canbus.

Cosiglio di sviluppare un protocollo open per diversi motivi :

1) non inventare l'acqua calda

2) dare la possibilità in futuro, oppure in altre occasioni di potersi interfacciare a dei sistemi standard.

Link al commento
Condividi su altri siti

Se hai bisogno di tempi di risposta di circa 1ms considera che una sessione di trasmissione deve essere inferiore ai 500uS. Con un po' di buon lavoro il Cortex M3 può soddisfare questi requisiti.

Valuta bene le distanza in gioco, dire "vicino" o "lontano" non è molto ingegneristico smile.gif

Se le distanze superano anche i pochi decimetri, spesso e volentieri, sono necessarie comunque linee bilanciate per compensare eventuali rumori ambientali.

Con una RS485 puoi arrivare anche ad ottime velocità (diciamo intorno ai 250Kbits).

Teoricamente puoi raggiungere anche molto di più.

Se vuoi stare un pochino più tranquillo usa il CANBus (1Mbit).

Valuta bene anche l'utilizzo di Ethernet. Sul Cortex-M3 della serie NXP (LPC17xx) è disponibile un EMAC 10/100 Mbits. Questo ti mette al riparo da qualsiasi problema di velocità del bus, ovviamente a scapito di un abbondante lavoro di scrittura firmware

RT

Link al commento
Condividi su altri siti

Ciao,

Ottime le considerazioni di RealTime.

Un piccolo consiglio potrebbe quello di valutare lo sviluppo del Master ( sempre con i protocolli standard industriiali), e l'acquisto di I/O remoti commerciali.

Purtroopo l'esperienza insegna che dove ci sono i numeri ( prodotti commerciali) ci sono:

1) affidabilità.

2) immediata disponibilità.

3) prezzo (rispetto ai costi da suportare per startup, e i meri costi di produzione).

Link al commento
Condividi su altri siti

RealTime+19/01/2012, 21:19--> (RealTime @ 19/01/2012, 21:19)

1) Dicaimo che la distanza va da un minimo di 10cm ad un massimo di 50cm

2) Diciamo che vorrei stare sul tranquillo biggrin.gif userei quindi un CAMbus (1Mbits) come suggerito.

però qui mi sorge un dubbio:

1Mbits = 1024Kbits = 1.048.574bits

però a me interessano i byte disponibili quindi divido per 8

1.048.574bits / 8bit = 131.072Bs

e visto che lavoro in millisecondi divido per 1000

131.072bits / 1000 = 131,072 B/milli

questo però mi dice poco perchè non è detto che un dispositivo che lavora a 1Mbits riesca a spedire 131,072 B/milli

Qualcuno mi può chiarire?

grazie dell' aiuto

Saluti

Link al commento
Condividi su altri siti

Ovviamente il calcolo che hai fatto tu è relativo alla "pura" velocità massima attuabile sul bus.

Diciamo che il fattore più importante, oltre alla velocita del dispositivo hardware, è sicuramente L "overcharge software".

Definire quanto il software puo' incidere sulle prestazioni finali di un driver di protocollo non è cosa semplice. Qui entrano in gioco molteplici fattori tra cui sicuramente.

- Prestazioni del microprocessore e frequenza di lavoro

- Prestazioni della periferica hardware (Per esempio presenza di h/w FIFO)

- Tipo di linguaggio utilizzato (Ovviamente anche l'ottimizzazione del compilatore), In generale la grande differenza è tra Compilato/Interpretato/VM

- Sistema operativo utilizzato (Nel caso si basi il s/w su una piattaforma O/S RT)

- Abilita' ed esperienza del programmatore nello scrivere codice smile.gif

Detto questo, la cosa migliore e' quella di iniziare la sperimentazione.

Scrivi il tuo protocollo e misura con precisione, utilizzando per esempio un oscilloscopio, le prestazioni finali del tuo sistema.

Normalmente per questo tipo di misura si puo' prelevare il segnale da misurare direttamente sul bus oppure utilizzare qualche I/O come trigger per segnalare le fasi di trasmissione/ricezione.

Un'altro metodo puo' essere quello di utilizzare i timers dello stesso micro e magari, con qualche print, ti aiuti nello studio del tuo protocollo ...

RT

Link al commento
Condividi su altri siti

Grazie delle dritte Realtime

Però non ho ancora capito una cosa, a vostra idea scrivendo tutto bene e ottimizzando al massimo riuscirò alla fine ad interrogare 3/4 schede di periferia con una cadenza di 1milli o 0,5milli oppure è una chimera la mia idea???

cioè non vorrei una risposta precisa si o no però almeno capire se sto tentando di andare in guerra con un fucile o con lo spazzolino da denti biggrin.gif , che poi la vinca la guerra questo è tutto da vedere ma se parto con lo spazzolino sicuramente la perdo...

grazie dell' attenzione

saluti

Link al commento
Condividi su altri siti

Per stare tranquillo usa un fattore del 50%, e' abbondante ma ti tiene al sicuro.

Se con CANBus riesci a far transitare circa 130 bytes/mS avresti circa 65 bytes/mS.

Considera che nel frame CAN 2.0 ci sono molte informazioni che non riguardano il tuo Payload (Ovvero le tue informazioni) ma che ovviamente occupano banda utile. Controlla bene la struttura del Frame CAN 2.0 e fai un conto preciso

RT

Link al commento
Condividi su altri siti

Non vorrei sconvolgere la discussione, ma considerati i requisiti richiesti dall'applicazione non sarebbe sbagliato usare un protocollo proprietario.

Non è chiaro che tipo di comandi deve inviare il master verso gli slave, ma con molta probabilità si tratta di comandi semplici, come ad esempio un attivazione. Se è così, anche includendo un CRC nel pacchetto si può fare il tutto con pochissimi byte (5-6), il che ridurrebbe notevolmente i tempi di comunicazione. In un protocollo stratificato, quando si trasmettono pochi byte sono più quelli usati dal protocollo di quelli del dato vero e proprio, e visto che uno dei requisiti è la velocità... smile.gif

a 115200 bps si trasmette un byte in 87 uS circa, quindi 5 byte in poco più di 400 uS.

sarebbe già sufficiente e volendo, su distanze così brevi, si può andare abbondantemente oltre i 115200 bps.

I ricevitori possono lavorare sotto interrupt e la risposta può essere immediata.

Ovviamente tutto ciò non è compatibile con niente di commerciale, ma se non ho capito male è un applicazione fine a se stessa.

Link al commento
Condividi su altri siti

Concordo! Proprio per questa ragione ho suggerito in partenza l'uso di IC2; vista anche la massima distanza prevista si può tranquillamente lavorare alla massima velocità prevista dal bus.

Io considererei anche SPI.

Link al commento
Condividi su altri siti

Come già accennato è fondamentale sapere la quantità di bytes da "muovere". Questo è il primo passo ...

Sono concorde con Livio per il bus SPI. E' il giusto compromesso tra complessità e prestazioni ....

RT

Link al commento
Condividi su altri siti

Per completezza di informazione, descrivo più in dettaglio il sistema che andrei a realizzare:

Mi piace molto il sistema con SPI visto anche il mio protocollo semplificato, lavorando con gli interrupt penso si potrebbe arrivare a velocità molto elevate con questo tipo di portocollo

Link al commento
Condividi su altri siti

Ok, la SPI è perfetta per questa applicazione.

Con un minimo sforzo hai la possibilità di effettuare un trasferimento Full-Duplex nello stesso ciclo del FRAME SPI.

Nel dettaglio puoi scrivere mentre leggi le informazioni dallo slave interessato.

Potresti scrivere un protocollo cosi' organizzato

1) Un byte di header che ti identifica l'inzio di un pacchetto (Sync). In questa fase gli slaves, ancora tutti in ricezione non sanno come operare

2) Un indirizzo slave. Teoricamente a questo punto lo slave interessato puo' trasmettere verso il master in modo simmetrico pilotando la linea MISO (Master In Slave Out)

3) Blocco dati

4) CRC

Questo tipo di protocollo, se fai una considerazione, ha un solo problema. Nella fase (2) uno degli slaves potrebbe "interpretare" male il dato e considerare il valore letto come indirizzato a lui. Potresti replicare 2 volte l'indirizzo dello SLAVE in modo da fornire maggiori garanzie di sicurezza. Molto spesso, per questo tipo di dati critici, i dati vengono replicati piu' volte in forma complementata. Per esempio, se hai l'indirizzo SLAVE = 02 trasmetti 0x02 e poi 0xFD (Complemento). L'allertamento dello slave avviene solo se il criterio stabilito viene onorato. Ovviamente puoi utilizzare altri metodi... nessun problema per questo.

Viste le distanze in gioco gli errori di comunicazione dovrebbero essere praticamente nulli. In ogni caso ti consiglio di utilizzare una linea bilanciata RS485-like come interfaccia fisica tra le schede. Questo ti garantisce una buona immunita' al rumore e ti isola abbastanza il processore dal resto del mondo.

Per semplificazione ti consiglio di scegliere una lunghezza di pacchetto fissa che possa contenere tutte le informazioni possibili. Per esempio ... 16 o 20 bytes .. fai tu. Puoi lasciarti qualche bytes per espansioni future.

RT

Link al commento
Condividi su altri siti

Concordo con RT, aggiungo solo che se vuoi fare un protocollo a lunghezza variabile (per risparmiare tempo nella comunicazione con gli altri slave che necessitano di meno byte), ti basta inserire un byte di LEN subito dopo il sync.

In questo modo oltre ad avere un pacchetto di lunghezza variabile abbatti anche le possibilità di errore, ricevere un pacchetto che ha la sync corretta, che dopo la len dichiarata nel secondo byte ha il pacchetto seguito da un CRC giusto... è piuttosto improbabile che contenga errori.

Anche la tecnica per gestire la routine di ricezione si semplifica, aspetti il sync, ricevi il byte successivo (LEN), aspetti i byte specificati nella len e dopo aver ingozzato tutto in un buffer controlli il CRC e gestisci i dati ricevuti. Il tutto gestito con eventuali timeout.

Modificato: da Nikiki
Link al commento
Condividi su altri siti

Si, ovviamente il pacchetto puo' essere a lunghezza variabile.

Se si vuole operare in full-duplex simmetrico non è invece possibile attendere la fine del pacchetto e della sua CRC.

Per far si che lo SLAVE si predisponga per trasmettere i suoi dati simultaneamente alla richiesta del MASTER bisogna che le operazioni da effettuare siano chiare nei primi bytes trasmessi dal MASTER stesso.

Per fare questo bisogna che SYNC ed indirizzo siano "recepiti" nella forma piu' sicura dallo slave.

A questo punto, una volta che lo slave ha capito di essere stato chiamato in causa, abilita la trasmissione verso la linea MISO. In questo caso ci torna proprio comodo il driver RS485 ed il suo TX-EN.

Per tutto il resto del tempo gli slaves lasciano il bus in three-state.

Quindi, ipotizziamo una struttura finale

[sYNC] [ADR] [ADR_COMPLEMENT] [LEN] [...DATA...][CRC]

Lo slave interessato non trasmette (impegnando il bus MISO) fino al raggiungimento del terzo byte. Il MASTER, per questi bytes, trasmette semplicemente degli ZERI (qualunque valore va bene ovviamente)

RT

Link al commento
Condividi su altri siti

Per risparmiare il massimo del tempo è un'ottima idea che lo slave inizi a rispondere prima possibile, ma fino a quando non ha ricevuto il comando, anche se ha ricevuto l'address e sa che sta per essere interpellato, come fa a sapere cosa deve rispondere? Mi sta sfuggendo qualcosa? smile.gif

cosa intendi dire?... non ho capito.

Link al commento
Condividi su altri siti

Se hai bisogno di un byte di comando per definire le operazioni da effettuare, questo è ovvio, lo devi aggiungere.

Nello schema che ti ho inviato ti ho fatto semplicemente un esempio di trasferimento dati con contenuto "statico", ovvero lo slave riceve e manda sempre la stessa classe di informazioni

Nel testo

Volevo dire ....

Lo SLAVE, per questi bytes, trasmette semplicemente degli ZERI (qualunque valore va bene ovviamente)

Se, come ipotizzato, utilizziamo uno schema simmetrico, anche i primi 3 bytes inviati dallo slave sono corrispondenti a [sYNC][ADR][ADR_CMP].

Dato che il MASTER non ha una reale necessita' di queste informazioni, a meno che tu non voglia comunque trasmetterle, puoi fare in modo che lo slave, in corrispondenza di questi bytes, invii dei valori nulli ....

RT

Link al commento
Condividi su altri siti

  • 10 months later...

Bene dopo molti mesi sono tornato a riconsiderare il progetto, rileggendo la discussione, e rivedendo un pò le cose in base

all' esperienza attuale, direi che il modo migliore per risolvere le mie problematiche è l' utilizzo di una scheda base di mia progettazione

con periferie di tipo commerciale comandate magari con un bus molto veloce, quidni mi viene da pensare l' utilizzo di CAN, nello specifico

CANopen, che inizia ad essere discretamente diffuso anche nel settore dell' automazione.

Ora ho visto che esistono molti fornitori di dispositivi di IO slave come ad esempio: Beckoff, Crevis, Phenix. Tutti hanno molti bus disponibili

ma il CANopne sembra essere la miglior scelta per quanto rigurda velocità e compatibilita.

Il problema però è che gli Arm della serie STM32F della ST hanno a bordo le porte CAN ma non ho trovato nessuna implementazione del

protocollo CANopen, o meglio le ho trovate ma di tipo commerciale a costi che vanno dai 7 ai 10 mila euro.

Mi chiedo quindi se esiste qualcosa di open source per noi poveri mortali che non abbiamo migliaia di euro da spendere :-)

Link al commento
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora
×
×
  • Crea nuovo/a...