Newsgroup: it.hobby.elettronica.digitale
Titolo: [LUNGO] Due micro: uno per la logica, uno per il display

Mi trovo spesso a dover affrontare (e penso molti di voi) due problemi 
contemporaneamente: in una macchina elettronica devo
- controllare alcuni parametri (tensioni, temperature, correnti, switch, 
relè, ecc.) in modo affidabile e in real-time
- visualizzare tutto su un display, gestire i tasti, comunicare via 
seriale con un PC
Il primo problema è ovviamente di vitale importanza perchè 
l'affidabilità e la tempestività degli interventi (per esempio, lo 
spegnimento di parti delicate quando un interruttore si chiude/apre) 
determina l'affidabilità di tutta la macchina.
Il secondo problema (la classica HMI), invece, ha una importanza 
"estetica" e funzionale, ma non inficia l'affidabilità della macchina 
(almeno non completamente). Qui la tempestività degli interventi è 
sicuramente molto meno richiesta.
Spesso risolvo il tutto con un solo microcontrollore che gestisce sia i 
task real-time, sia la HMI. Quello che mi vien fuori, però, è qualcosa 
di poco affidabile. Il task della HMI (soprattutto la gestione del 
display) impiega e sottrae tempo ai task real-time rallentandoli 
(purtroppo non riesco a creare task a bassa priorità interrompibili da 
altri ad alta priorità).
Visto che la HMI diventa sempre più complessa (al posto dei display 
monocromatici si passa ai grafici TFT a colori, al posto delle vecchie 
RS232 si passa a USB o addirittura ad Ethernet con tanto di Web server), 
avevo pensato di suddividere i due problemi su due micro diversi: uno 
piccolo (anche ad 8-bit) e affidabile per i task real-time, uno grande 
e performante (un 32-bit con OS) per la HMI.
A questo punto, però, mi chiedo che tipo di comunicazione potrei 
sviluppare tra il micro HMI e il micro real-time, soprattutto se la 
macchina è molto complessa e necessito di alcuni micro real-time 
(diciamo una decina) per vari task e un'unica HMI.
In questo caso dovrei scegliere e/o sviluppare un bus di comunicazione 
veloce, da un lato per acquisire i dati di stato dai micretti, 
dall'altro per impartire i comandi (provenienti dai tasti o da remoto).
Naturalmente il bus deve essere veloce (se scatta un allarme lo dovrei 
vedere presto sul display e non dopo 10 secondi), ma al contempo non 
deve occupare continuamente i micretti (altrimenti stanno sempre a 
comunicare con la HMI e siamo punto e daccapo).
E come al solito siamo al solito dilemma: bus multi-master o singolo 
master? La prima soluzione alleggerirebbe molto l'occupazione del bus 
(il micretto comunica con la centrale solo se ha qualche variazione da 
fornirgli), ma sarebbe molto più complicata (dovrei andare su soluzioni 
tipo Ethernet o CAN).
Inoltre mi preoccupano le misure analogiche che dovrei visualizzare a 
display. Se ho un segnale audio campionato da un micretto per i suoi 
scopo e che devo visualizzare a display (o su una pagina web) con un 
meter abbastanza veloce, ho paura che la comunicazione su bus possa 
rallentare troppo.
Potrei anche far arrivare le "analogiche veloci" sia al micretto che al 
micro HMI, ma mi sembra una soluzione a metà. Se dovessi far comunicare 
il valore dell'analogica solo su variazioni, praticamente starei sempre 
a trasmettere un nuovo valore, con il pericolo di creare troppe 
collisioni sul bus (tutti i micretti vorrebbero trasmettere).
Se siete arrivati sin qui, avete anche la voglia di darmi dei suggerimenti?

 collisioni sul bus (tutti i micretti vorrebbero trasmettere).
Allora usa un solo master ed un bus SPI controllato dal processore dedicato
alla HMI: se esso non ha tempo per chiedere i dati ai "micretti", di certo
non ha il tempo per visualizzarli, quindi a che scopo riceverli?
Tieni conto che ci sono controller (ma mi vengono in mente solo il V25 NEC,
non più in produzione e gli ATxmega, non ancora in produzione), che
permettono di gestire le comunicazioni senza intervento della CPU, che si
ritrova, alla fine, un solo interrupt ed un buffer già pieno di un sacco di
bei dati.

Se siete arrivati sin qui, avete anche la voglia di darmi dei suggerimenti?
L'idea di usare più µC è buona e viene sempre più sspesso usata per le ragioni
che hai scritto tu, principalmete la difficoltà di essere real-time e usare
strutture con cpu impegnate con cose impegnative come la grafica e i touch
screen.
L'alternativa è tra usare un bus tipo CAN, ci sono i controller appositi, e
qualcosa di diverso.
Io in un applicazione in cui, per varie ragioni tra cui la modularità ho dovuto
usare una rete di µC, ho scelto un altro approccio, dettato soprattutto dalla
necessità di avere collegamenti veloci, anche se non frequenti.
In quel caso ho usato degli AtTiny2313 con la UART in modo sincrono (USART)
gestendo il collegamento master-slave con dei fili in 3 state pullup.
Se una periferica chiede comunicazione abbassa il segnale collegato ad un INT\ a
quel punto inizia una scansione dal master che trova chi ha chiamato e esegue il
task.
Questo mi consente di evitare il polling e risolve anche il problema di
collisioni, perchè è sempre una scansione master-slave, e potendo andarecon la
USART a qualche Mhz di baud rate (fino a 4 tutto ok) non ci sono stati
particolari problemi di velocità.
Naturalmente il tutto è all'interno dello stesso contenitore e con connessioni
flat cable.
--
ciao
  Stefano

 bei dati.
Ripeto che il problema non credo sia sul lato HMI, piuttosto sul lato 
micretti che risponderanno con i loro tempi e con le loro velocità.
Quello che tu dici si potrebbe immagino fare con un micro dotato di 
almeno un canale DMA.

 flat cable.
Come mai una seriale sincrona, piuttosto che asincrona?
Inoltre nel tuo caso la scelta mi sembra valida perchè volevi dei 
collegamenti veloci ma non frequenti. Non la vedrei nel mio caso dove 
devo poter rinfrescare tutte le misure velocemente e in continuazione. 
Non trovi?

 trovi?
Qual'è la frequenza di campionamento dei vari micretti?
-- 
  Filippo 

 un canale DMA.
Vista l'architettura distribuita e la necessità del realtime,ti consiglio da 
subito il CAN.
Ci metti un controller standalone (se non vuoi prendere un micro con 
controller integrato) e se vuoi togli pure il polling: quando ci sono 
variazioni di ingressi, le varie schede manderanno sul bus messaggi con l'id 
opportuno e la scheda 'master' prenderà le operazioni del caso.
Quando ci sarà una variazione dei dati da visualizzare, la 'master' spedirà 
il messaggio e solo la scheda interfaccia/utente lo gestirà, quando sarà 
premuto un tasto quest'ultima scheda manderà il messaggio sul bus e lo 
gestirà solo la master, e così via...
I conflitti sul bus e gli eventuali retry li gestisce autonomamente il 
controller.
CAN nasce come sistema di comunicazione realtime, quindi fa ciò che tu 
chiedi.
Senza stare ad inventare nulla, puoi utilizzare protocolli già esistenti ed 
affidabili (la maggior parte dei quali di derivazione modbus). 

 (diciamo una decina) per vari task e un'unica HMI.
Un conto č se hai un processore dotato internamente di piů cores, ma
altrimenti anziché dieci micro magari č meglio impiegare una singola FPGA,
implementando le varie funzioni nel modo piů comodo (con soft processor e/o
direttamente in VHDL) e effettuando l'interfacciamento con la CPU
principale tramite delle dual port RAM, che sono piů veloci di un qualsiasi
accrocchio seriale e soprattutto ti risolvono una quantitŕ infinita di
problemi rispetto ai suddetti accrocchi.
Per inciso, per sistemi di una certa complessitŕ l'utilizzo di dual port
RAM č piuttosto comune anche quando si utilizzano dei processori "fisici"
anziché delle FPGA.
-- 
emboliaschizoide.splinder.com

 l'id opportuno e la scheda 'master' prenderà le operazioni del caso.
Bene per gli ingressi che variano lentamente, come i segnale di tipo 
ON/OFF. Cosa succede però per le tensioni analogiche che variano in 
continuazione?

 anziché delle FPGA.
Avevo un amico che scriveva anche qui (Rinux) che le dual port le usava 
sulle sue schede di visione/sorveglianza dove montava 4-8 dsp insieme.
coals 

 anziché delle FPGA.
Non pensavo che la mia applicazione fosse così "complessa".
In realtà si tratta di mandare a video (magari un TFT) o su pagine web 
(eventualmente richieste) dei dati collezionati da vari punti della 
rete. Le operazioni che devono fare i micretti sono veramente semplici, 
ma devono essere affidabili (cioè senza grandi latenze), niente di più.
Inoltre per la mia applicazione dovrei dislocare i micretti in 
contenitori diversi, quindi non posso usare una FPGA soltanto per tutto.

 continuazione?
Variare in continuazione è 'tipico' delle grandezze analogiche.
Dipende poi ogni quanto tempo vuoi/puoi effettuare le letture e che cosa 
devi fare con le grandezze acquisite.
Se le devi solo visualizzare, viste le latenze dei display e considerando di 
visualizzare un valore 'leggibile' a schermo, è sufficiente aggiornare il 
valore ogni qualche centinaio di ms.
Se devi visualizzare un grafico, memorizzi i valori in un buffer e trasmetti 
pacchetti di un certo numero di campionamenti.
Se devi confrontare il valore con una soglia preimpostata, questa operazione 
la può effettuare anche la scheda di acquisizione, comunicando solo l'evento 
se e quando accade.
Una volta definito il baudrate, ti tieni un certo margine per non saturare 
il bus e poi puoi trasmettere tutte le letture che vuoi.

Non trovi?
Dipende dall'applicazione, io posso avere periferiche che non hanno necessità di
comunicare nulla anche per 1 secondo, poi possono avere 100 scambi di dati nel
secondo successivo.
In quel caso è importante non sprecare tempo a fare scansioni periodiche con
conseguente spreco di banda, e allo stesso tempo avere la possibilità di
intervenire rapidamente se è il caso.
Naturalmente questo dipende anche da come suddividi la logica tra i processori,
cioè da come è stato pensato il sw globalmente.
Se ad esempio sto monitorando una temperatura e quest'ultima non sta variando in
modo significativo, facendo il polling stupido interrogherò in continuazione la
periferica e leggerò sempre lo stesso dato sprecando tempo e banda.
Se invece nel µC (Tiny) metto la condizione che solo la variazione di
temperatura maggiore di 0,5C° è significativa e di comunicarlo in caso si
superi, a quel punto la banda sarà occupata solo se c'è realmente la necessità.
Ma per far questo bisogna che le periferiche non siano del tutto 'stupide'.
--
ciao
  Stefano

 sufficiente aggiornare il valore ogni qualche centinaio di ms.
Magari riuscissi ad arrivare ad un centinaio di millisecondi.
Facciamo due calcoli veloci e supponiamo un bus a 1Mbps. Diciamo 10 
slave con 10 valori analogici a 16 bit.
16bit/campione * 10 campioni/slave * 10slave / 1E6bit/s = 1.6ms
Considerando quindi un grado di utilizzazione della banda al 100% 
(trasmetto in continuazione senza sprechi) starei abbondantemente nei 
100ms. Quanto può inficiare la latenza (i micretti possono impiegare un 
po' a rispondere, a meno che non trasmetto in interrupt) e l'overhead 
del protocollo?
Per evitare protocolli master/slave (che fanno aumentare l'overhead 
notevolmente) pensavo ad una trasmissione automatica da parte di 
micretti. Ogni volta che c'è una variazione degli ingressi (analogici o 
digitali) il micretto invia il dato all'HMI. Il CAN bus sarebbe penso 
abbastanza indicato per questo genere di protocollo.
Il fatto è che, proprio per le analogiche che cambiano in continuazione, 
tutti i micretti vorrebbero trasmettere e la probabilità che ci sia 
collisione è molto alta. Come potrei fare per fare in modo che i 
micretti possano tra loro sincronizzarsi senza darsi fastidio l'un l'altro?
Mi viene in mente il token ring. Il micretto 1 invia il messaggio:
- sono il micretto 1 e questa è il valore del mio segnale 1
Tutti i micretti, oltre l'HMI, ricevono questo messaggio. Il micretto 2 
può quindi trasmettere subito dopo (sapendo che il precedente ha appena 
finito). Quindi trasmette:
- sono il micretto 2 e questo è il valore del mio segnale 1
Secondo voi potrebbe funzionare? Ho paura che, se per qualche motivo un 
micretto si blocca oppure si perde un pacchetto, tutta la rete si 
blocchi (e mi sa che la possibilità è molto alta... peccato, mi sembrava 
una soluzione con una utilizzazione massima della banda).
Altra possibilità è quella di utilizzare una Ethernet low-cost (10Mbps 
con controller SPI esterno al micretto, tipo quello della Microchip, 
oppure integrato nel micretto... quale micretto low-cost ha un 
controller Ethernet 10Mbps?). In questo modo sono in vantaggio di 10 
(rispetto al già citato 1Mbps) e posso sfruttare i meccanismi di 
gestione della collisione di Ethernet. Ma al solito, senza una 
sincronizzazione tra i micretti, rischio che stiano sempre in collisione.

 rischio che stiano sempre in collisione.
Da quanto ho capito non ti serve espressamente il livello fisico o la 
compatibilità ethernet.
Se utilizzi TCP/IP, con tutto lo stack appesantisci notevolmente la 
comunicazione, limitando di fatto la banda a disposizione.
Se invece utilizzi UDP, non hai nessu controllo sui dati inviati ed equivale 
in pratica ad utilizzare una qualsiasi seriale.
Io continuo a suggerirti il CAN.
Visto che hai citato Microchip, prova a vedere il controller MCP2515:
abbinato al driver MCP2551 e collegato via SPI al tuo micro, avendo 2 buffer 
interni,  ti consente di fare ciò che vuoi. 

 verificare lo stato del tuo messaggio e l'eventuale risposta ricevuta.
Scusate se mi intrometto, ma l'argomento interessa anche me. Se 
ipotizziamo la situazione proposta, cioè 10 micretti che vorrebbero 
autonomamente trasmettere in continuazione, come può la gestione delle 
collisioni rendere uniforme l'accesso al bus? Il CAN prevede anche questo?
Io avevo risolto più o meno nel modo suggerito da pozz (stile token 
ring) aggiungendo però un timeout: se un micro si blocca gli altri se ne 
accorgono e proseguono la trasmissione, segnalando il problema all'unità 
centrale.
In generale però utilizzo sempre un sistema di ACK/NACK da parte del 
'master' come segnale di sincronismo e segnalazione per i vari satelliti.
Marco

 buffer interni,  ti consente di fare ciò che vuoi.
In effetti posso seguire questa strada... grazie per le indicazioni.

 'master' come segnale di sincronismo e segnalazione per i vari satelliti.
Il messaggio di ack può essere mandato e/o richiesto comunque: un nodo manda 
un pacchetto e se il nodo che lo deve gestire lo riceve manda l'ack sul bus.
Nel CAN i pacchetti hanno sempre l'indirizzo del 'mittente', ma non è 
richiesto che ci sia l'indirizzo del 'destinatario': sono le periferiche che 
quando identificano un messaggio con un id specifico, lo processano e 
mandano eventualmente un messaggio di risposta. 

 e mandano eventualmente un messaggio di risposta.
Ok, grazie mille della panoramica sul CAN. E' da tempo che vorrei 
provare ad usarlo e mi sa che ci darò presto uno sguardo più da vicino.
Marco

 l'ACK del master funge da segnale di "clock" per lo slot successivo).
E' fondamentalmente il mio dubbio...
Il CAN bus è nato per permettere a nodi ad elevata priorità (immagino 
nodi che si occupano della sicurezza nelle auto) di trasmettere senza 
ritardi il proprio messaggio.
Nella nostra applicazione, invece, servirebbe un bus che desse a tutti i 
nodi la stessa possibilità di trasmettere i dati, senza rischiare di far 
bloccare il bus da un solo micretto (e mi torna in mente Ethernet...).
Il CAN potrebbe funzionare nella nostra applicazione solo se la 
percentuale di occupazione della banda è bassa. Se il micretto più 
prioritario vuole sempre trasmettere, trasmetterà solo lui.
L'unica soluzione in questo caso è prevedere un certo tempo sufficiente 
tra un pacchetto ed un altro, diciamo T. In quel tempo T tutti gli altri 
micretti devono avere la loro possibilità di trasmettere.
Però questa logica fa perdere la semplicità del CAN in quanto il 
micretto non deve semplicemente dire al controller di trasmettere un 
pacchetto, senza preoccuparsi di altro, ma deve anche preoccuparsi di 
attendere un tempo T dalla trasmissione utile dell'ultimo pacchetto da 
lui inviato.
Tornando ad Ethernet, si potrebbe addirittura evitare il sovrasistema 
IP+UDP/TCP. Alla fine si potrebbe usare Ethernet per il livello fisico e 
quello delle collisioni (come si chiama?), nient'altro. Non mi serve 
tutto l'IP per l'instradamento dei pacchetti (non ho mica sottoreti tra 
loro connesse).

loro connesse).
Se non ci sono problemi di ambiente, cioè se siamo all'interno dello stesso
contenitore, io sono ancora dell'idea che la soluzione che ti avevo proposto
prima abbia una sua validità e sia competitiva.
Mi è anche venuto in mente perchè ho usato la UART in modo sincrono.
Dal momento che volevo usare l'oscillatore interno nei Tiny2313, ho notato che
non tutit ce la fanno ad agganciare una UART e ci vuole o un oscillatore esterno
o una taratura del clock interno, che è sempre una complòicazione in più.
Inoltre usando segnali a 5V non hai nessuna complicazione hardware, che sia il
controller CAN o Ethernet, al massimo metti qualche resistenza per il pullup e
la protezione degli I/O.
Se hai qualche filo e pin liberi puoi anche usare linee diverse per gestire la
priorità delle chiamate, io all'inizio avevo pensato ad una cosa del genere, poi
quando ho visto la velocità del sistema in pratica ho lasciato solo un INT\.
--
ciao
  Stefano

 quando ho visto la velocità del sistema in pratica ho lasciato solo un INT\.
In effetti è una soluzione semplice quando i micretti sono vicini o 
sulla stessa scheda. Nel mio caso non posso.

sono sparsi in diversi contenitori distanti circa qualche metro.
Questo mi era sfuggito, allora devi orientarti su qualcosa come il CAN, se le
tue aspettative sulla banda possono essere rispettate, o al limite su qualcosa
come il modbus che girando su RS485 può raggiungere velocità di qualche Mb.
--
ciao
  Stefano

 bloccare il bus da un solo micretto (e mi torna in mente Ethernet...).
Devi condiderare che il supporto fisico è uno solo, quindi la trasmissione 
contemporanea di più messaggi non può in ogni caso essere effettuata.
Ethernet divide i dati in pacchetti di lunghezza fissa e nel caso tu debba 
inviare uno stream 'lungo' lo stack si occupa della suddivisione in 
pacchetti e relativo ricompattamento.
In questo caso diventa importante lo stack TCP/IP che effettua 
effettivamente il controllo e impacchettamento di ogni messaggio ricevuto, 
mentre l'UDP ti passa i dati in forma 'grezza' lasciando a te l'onere dei 
controlli del caso.
Visto che ogni messaggio può essere inviato 'spezzettato', lo spazio 
temporale fra i paccehtti può essere utilizzato da un'altro 'trasmettitore'.
Nel CAN, ogni controller controlla lo stato del bus dopo ogni singolo bit 
inviato.
Nel caso di trasmissione assolutamente contemporanea, il messaggio con il 
campo di arbitraggio prioritario termina l'invio del proprio messaggio in 
modo non distruttivo, quindi sei sicuro che il ricevitore interessato può 
processare il messaggio stesso.
L'altro nodo ritrasmette il proprio messaggio appena il bus si libera.
Essendo la lunghezza massima di un pacchetto CAN (in genere) di 16 bytes, 
supponendo di non andare alla massima velocità (1Mbps) ma a 500kHz, il 
pacchetto è trasmesso in 32usec: direi che rimane abbastanza banda per tutti 
i 10 nodi...
Il timing preciso lo puoi ottenere facendo in modo per esempio che (in base 
all'indirizzo del nodo), tutti trasmettano autonomamente al msec xx, 
risincronizzando eventualmente i 'ritardi' ad ogni messaggio ricevuto.
In questo modo, avendo timeslot assegnati e predeterminati puoi avere le 
trasmissioni di tutti i nodi senza nessun 'accavallamento'.
Esiste altrimenti un utilizzo simile della 485: ogni nodo quando trasmette, 
riceve nel contempo i dati trasmessi.
Se si accorge che c'è qualcosa che non va, attende un tempo random prima di 
ritentare la ritrasmissione.
Questa casualitàà nei ritardi fa si che il successivo tentativo non avvenga 
contemporaneamente all'altro nodo.
Con tale metodo però devi accettare di avere sul bus messaggi 
errati/non_completi e relativi ritardi di ritrasmissione.
Inoltre non tutte le uart sono in grado di spingersi a 500kbps...1Mbps.
Dopo tutto ciò e questi ultimi miei interventi, non vorrei sembrare uno che 
vuole a tutti costi spingere ad utilizzare il CAN e che sia la soluzione a 
tutti i problemi.
Semplicemente però venendo da anni di lavoro con RS232/RS485/SPI/I2C e dopo 
avere lavorato negli ultimi 3 anni con CAN ed ethernet,
mi sono alla fine convinto che il CAN è un figata pazzesca...
E che mi avrebbe, anche in progetti passati, evitato una serie di 
problematiche che ho dovuto affrontare e risolvere vis sw, visto l'approccio 
master-slave ed il supporto fisico adottato. 

 Non pensavo che la mia applicazione fosse così "complessa".
Ah, se non lo sai tu... :)
In base alle informazioni che ci hai dato nel messaggio precedente, mi
sembrava che il problema che ti ponevi fosse principalmente quello di fare
una suddivisione "logica" dei compiti, invece ora sembra trattarsi più di
una suddivisione fisica. Più che di un problema architetturale, si tratta
semplicemente di scegliere un bus di comunicazione; a questo punto la
soluzione più semplice sembra proprio essere quella che ti hanno già
consigliato, ossia la CAN.
-- 
emboliaschizoide.splinder.com

 l'approccio master-slave ed il supporto fisico adottato.
La tua esperienza vale mille parole. Soprattutto se mi dici che hai 
lavorato anche con Ethernet e il bus CAN ti è sembrato comunque migliore.

 tanti :(
Dubbi ne ho tanti anche io...
Un passo alla volta cerco di trovare le risposte e le soluzioni, riportando 
nel contempo le mie esperienze,
c'è ancora tanto da imparare....

avere le linee tx/rx separate non porta nessun beneficio).
I µC moderni sono tutti full duplex, ad esempio  AtTiny2313 che citavo negli
altri post utilizza una USART full duplex fino a un massimo di 2Mbaud
(asincroni), oltre 4 Mb(sincroni) e costa 50c.
Half-duplex non me ne viene in mente nessuno, forse qualche vecchio pic.
--
ciao
  Stefano

 collisione.
Mi pare che non sia stato chiarito come funzioni il CAN al livello
elettrico. Il CAN, fondamentalmente è un RS485. In entrambi i casi (qui
vado a memoria, può darsi che sia l'esatto contrario, ma il concetto non
cambia) per trasmettere un 1 ("bit dominante" nella terminologia CAN)
manderai la linea A a livello alto e la B a livello basso. La differenza è
nel fatto che, per trasmettere uno zero, con l'RS485 metterai la linea A
bassa e la B alta, mentre col CAN lascerai entrambe ad alta impedenza.
Il byte di arbitrazione non sono altro che gli (mi pare) 11 bit che sono
l'indirizzo del nodo che trasmette.
I nodi si autosincronizzano a livello di bit, ovvero è garantito che, se
più di un nodo trasmette qualcosa, i relativi bit saranno sincronizzati .
Un controller CAN ha bisogno di un clock assai più alto della velocità di
trasmissione appunto per potersi risincronizzare a livello di bit.
Se due nodi trasmettono contemporaneamente, il messaggio del nodo a
priorità più alta, ovvero quello che il cui indirizzo inizia con tutti uno,
passerà assolutamente indisturbato, visto che il nodo a priorità più bassa
interromperà immediatamente la trasmissione non appena si accorgerà che sul
bus è presente un uno mentre lui avrebbe voluto trasmettere uno zero (ti
ricordo che lo zero non viene trasmesso, il bus rimane ad alta impedenza).
Quindi il messaggio a priorità più alta non dovrà essere ritrasmesso,
evitando la saturazione del bus da eccessivo numero di retry come può
accadere su di una Ethernet utilizzata al limite della sua capacità.
Per quanto riguarda la quantità di dati che puoi trasmettere, tieni conto
che, col CAN, hai un overhead, se ben ricordo, di un paio di byte per
pacchetto, il quale pacchetto mi pare possa contenere al massimo un paio di
byte di "payload". Documentati meglio, vado a memoria fallata, ma sappi
che, grosso modo, più di 250 kb/s non potrai trasmettere.
Se non altro, tutta la banda ti sarà *sempre* disponibile, eventuali
collisioni non ti portano via banda.
Per inciso il CAN è nato per trasmettere la velocità delle singole ruote ed
i comandi di modulazione frenata per il sistema ABS.
Più "mission critical" di così...

 elettrico.
Dimenticavo: esiste una versione "semplificata" del bus CAN che si chiama
LIN. Se usi processori AVR cercati la AN relativa, che non solo, se ben
ricordo, lo spiega abbastanza bene, ma ti fornisce anche un'implementazione
puramente software. Oppure ci sono gli AVR con controller CAN built-in, una
soluzione che potresti prendere in considerazione, in quanto semmai più
economica di "micretto"+controller CAN, senza contare la complicazione di
gestire il controller via SPI.
Un'ultima, forse molto importante cosa: se devi trasmettere dati davvero
banali, dai un'occhiata all'offerta Microchip: se ben ricordo hanno dei
controller CAN che non hanno bisogno di alcuna programmazione e che
trasmettono direttamente i dati letti direttamente dai loro pin.

 (asincroni), oltre 4 Mb(sincroni) e costa 50c.
Il problema è che saprai se hai avuto una collisione solo dopo aver
trasmesso (e quindi ricevuto) un intero byte. Per i famosi alberi in
carbonio ho fatto di necessità virtù: visto che l'ATtiny44 non ha una UART,
l'ho implementata via software, ottenendo così anche di avere, direttamente
dal micro un output ed un input (tramite il comparatore) bilanciati, oltre
la possibilità di leggere "in tempo reale" lo stato del bus e poter quindi
interrompere tempestivamente la trasmissione in caso di collisione.
L'implementazione è relativamente semplice: un interrupt al doppio della
frequenza di trasmissione, negli interrupt pari trasmetti ed in quelli
dispari controlli il bus. Non ho implementato il contenuto di una AN Atmel
che descrive come sincronizzare le UART a livello di bit, cosa utile sia
per avere un sistema più robusto che per risparmiare sui quarzi...

interrompere tempestivamente la trasmissione in caso di collisione.
Il rischio di collisioni c'è praticamente solo nel multimaster, in quel caso il
CAN se la cava bene, però ha lo svantaggio della velocità e del pacchetto corto
a lunghezza fissa.
Nel caso queste non siano limitazioni, il CAN va benissimo, del resto Devicenet
e canopen sono usati nel campo PLC e automazione in generale.
Se però c'è un host (come mi sembrava di capire) il sistema master-slave ha i
sui vantaggi, io trasmetto a 4Mb pacchetti che possono arrivare anche oltre
1Kbyte con un paio di CRC di controllo, e il protocollo è semplice.
Il contatore dei reSend poi è praticamente sempre a zero.
--
ciao
  Stefano

 una volta che li ha esso stesso ricevuti).
Utilizzando uno switch aumentano i ritardi e diminuiscono le collisioni, 
con un hub non ci sono ritardi ma aumentano le collisioni. Avrei pure la 
possibilità di scelta.

 1Kbyte con un paio di CRC di controllo, e il protocollo è semplice.
Il protocollo è semplice perché hai due segnali in più, l'interrupt dal PIC
(che il controller non si chiami così non importa, il "micretto" è proprio
un Peripheral Input Controller ;-)  ) e il chip select dal master
(opzionale, se si usa il "CPU to CPU mode" degli AVR).
Ma, se i PIC sono in giro per la stanza, due segnali in più da mandare in
giro non sono poca cosa.
Infatti, nella mia risposta iniziale, quando consigliavo SPI o I2C avevo
premesso "se sono sulla stessa scheda". Ma così pare non essere.
Se guardi il problema più in generale, si può dire che, per distanze
inferiori ai 5 cm è meglio I2C, per distanze < 50 cm meglio la USART, per <
50 m meglio il CAN, oltre è meglio Ethernet.
 

 16 bit. E almeno alcune di queste si muovono rapidamente
Scusa, ma allora come fai a scrivere "Potrei anche far arrivare le
"analogiche veloci" sia al micretto che al micro HMI"?
Non è che stai cambiando le specifiche mentre ne parliamo? ;-)

 Più "mission critical" di così...
In realtà la mia applicazione del bus non è mission-critical, serve solo 
a comunicare un bel po' di valori ad una unità centrale che gestisce l'HMI.

F. Bertolazzi ha scritto:

Il problema di base è che in questo sistema ho un bel po' di analogiche, 
alcune delle quali velocemente variabili, ed altri segnali (digitali) 
molto meno variabili.
Mi domandavo all'inizio quale potesse essere la soluzione migliore per 
separare l'HMI dalla logica "mission-critical".
Inviare sul bus i segnali digitali non è un problema, perchè queste 
informazioni sono lentamente variabili e occupano poca banda. Il 
problema è soltanto relativo alle analogiche veloci e così mi chiedevo:
"devo far arrivare le analogiche veloci sia al micretto che al micro HMI?".
Ovvio che facendo così risolverei un bel po' di problemi (il bus sarebbe 
molto meno "carico" e l'HMI potrebbe disegnare tranquillamente le misure 
analogiche senza ritardi), ma la cosa mi sarebbe molto complicata perchè 
questi segnali analogici dovrebbero viaggiare per qualche metro in 
ambienti ostili. Preferirei evitare questa soluzione e cercare di 
trasmettere i segnali veloci sul bus. Da qui tutti i problemi che mi sto 
ponendo su una scelta di un bus affidabile per questa applicazione.

 contemporaneamente: in una macchina elettronica devo
 > [...]
Ragazzi, ringrazio tutti quanti per aver partecipato alla discussione. 
Non voglio tediarvi oltre, anche per il thread è oramai poco leggibile.
Non c'è dubbio che le due soluzioni che sono emerse sono Ethernet e CAN. 
Devo meditare un po' sulla scelta. L'ideale sarebbe fare delle prove, ma 
metter su due reti diverse con hardware e software diversi per fare solo 
dei test mi porterebbe via troppo tempo.
Devo scegliere sulla carta...

 ponendo su una scelta di un bus affidabile per questa applicazione.
Pensa anche a quale topologia di bus ti convenga. I cablaggi sono spesso
parte consistente della spesa (monetaria e di affidabilità) totale.
Personalmente preferisco un solo doppino con morsettiere ad un cablaggio
con gli RJ-45, ma dipende molto dall'ambiente dove il tutto andrà
installato.

50 m meglio il CAN, oltre è meglio Ethernet.
 
Direi  se sono sulla stessa scheda I2C o SPI, nello stesso contemitore va bene
la USART, per distanza meggiori fino a 50-100m CAN o MODBUS a seconda della
configurzione e delle prestazioni da raggiungere, fino a 200m Ethernet su cavo,
oltre Ethernet su fibra ottica.
Poi, va bè, ho usato una RS485 fino a più di 800 metri, (non ci credevo nemmeno
io quando l'ho vista, ma è in funzione in Francia) usando solo un interfaccia
optoisolata.
--
ciao
  Stefano

Devo scegliere sulla carta...
Fai la carta più alta     :-))
--
ciao
  Stefano

 ha scritto nel messaggio 
news:dhqvl.286071$FR.5...@twister1.libero.it...

La prima volta che ho docuto affrontare lo stesso problema ho predisposto il 
circuito sia per un ENC28J60 (con relativo trasformatore) che per un MCP2515 
(con relativo MCP2551).
I connettori di comunicazione erano 2 RJ45 (collegati in parallelo fra di 
loro), 4 pin (2 coppie, pin 1,2,3,6) destinati all'ethernet e 4 pin (le 
rimanenti 2 coppie, pin 4,5,7,8) destinati al CAN + alimentazione.
I primi prototipi li ho montati 'full optional', poi una volta eseguiti test 
e scritto il fw, ho continuato a montare x la produzione solo la parte 
relativa al CAN.
I 2 connettori collegati in parallelo in questo caso mi consentono un 
collegamento in cascata di tutti i nodi utilizzando comuni cavi patch 
commerciali (la terminazione la attivo su comando fw utilizzando un mosfet).
Non nascondo che in alcune applicazioni, mi ha fatto comodo avere entrambe 
le interfacce, dotando così il sistema base di connettività ethernet.
Ora che mi ricordo, il CAN è stato scelto rispetto all'ethernet anche perchè 
il relativo bootloader per l'aggiornamento da remoto richiedeva molta meno 
rom, lasciando così più spazio per l'applicativo.

 optoisolata.
Che spreco, l'interfaccia optoisolata! ;-)
Io, per un test, avevo fatto passare in un rocchetto da 100 metri a 4
conduttori non twistati, un segnale RS 422 a 1 Mb/s su due conduttori e
l'alimentazione per un grosso trapano sugli altri due.
Non perdeva manco un bit.

Non perdeva manco un bit.
Ci credo, ma sei un sadico    :-)
--
ciao
  Stefano

 Non perdeva manco un bit.
La tua prova è inifluente, e sembra quella che faceve un mio collega 
avvolgendo il cavo di comunicazione intorno ad un grosso trasformatore da 
qualche kVA....;-)
Il segnale differenziale è di per sè immune a gran parte dei disturbi di 
modo comune e una migliore immunità la si ha senz'altro utilizzando cavi 
twistati.
Il problema maggiore con la RS485 non isolata e su lunghe tratte è che che 
la differenza di potenziale fra gli zero volt (massa) non può (in genere) 
essere superiore a qualche volt (dipende dai drivers).
Questo problema (per quanto ne so io) lo si elimina solo separando le masse, 
quindi adottando un optoisolamento.

 
io sono della parrocchia del polling stupido. Il mio ragionamento è 
questo: per le casistiche che affronto di solito, devo garantire un 
perfetto funzionamento, senza glitches di alcun tipo, anche nel worst 
case, quindi tanto vale dimensionare tutto per il worst case e fare un 
polling stupido.
Come detto il discorso è relativo. Ad esempio io non ho mai lavorato su 
progetti che richiedano limitazioni di assorbimento di corrente (es. 
batterie): in quei casi è necessario abbandonare questo polling stupido, 
tenendo sempre presente però il worst case.

tenendo sempre presente però il worst case.
Non sprecare risorse è prima di tutto una filosofia di progetto, poi in alcuni
casi si può anche fare impunemente, ma a me non piace a prescindere.
--
ciao
  Stefano

 da ogni nodo ?
Per come la vedo io, cerco sempre di garantire il 100% del funzionamento 
anche nel "caso peggiore" ovvero nella situazione considerata quando 
tutti i segnali variano continuamente. Che poi sia un'eventualità rara o 
meno io la terrei presente (a meno che la probabilità che si verifichi 
sia *davvero* trascurabile). Se poi normalmente i nodi trasmettono molto 
meno di frequente è tutto un vantaggio, ma non la vedrei come specifica 
progettuale.
Marco

 quindi adottando un optoisolamento.
Sě, certo, ma forse tu non sai che io sulle interfacce optoisolate ci
campo. ;-)

 campo. ;-)
;-) 

 casi si può anche fare impunemente, ma a me non piace a prescindere.
Neppure a me, anzi, mi fa inorridire ma, ragionando razionalmente, a me
sembra che abbia ragione BQ.
Senza contare che, se il master fa il polling quando meglio gi aggrada,
potrebbe gestire al meglio le *sue* risorse, e, se l'operazione viene fatta
in modo sequenziale, non c'è manco bisogno di mandare in giro tanti bit di
indirizzo. Se uno slave non risponde perché fuori servizio, non c'è molto
da rinegoziare. Vabbè, latenza permettendo, e si sa che le reazioni che
provochi arrivano sempre nel momento peggiore...
No, davvero, anche se lo slave risponde quando c'è da fare dell'altro, se
non altro nessun'altro romperà le scatole prima del tempo. Se i dati non
sono scartabili, al limite i messaggi successivi saranno più lunghi.

sono scartabili, al limite i messaggi successivi saranno più lunghi.
Non è un problema del lavoro dello slave, ma del massimo utilizzo delle risorse
in genere, e si vede poi proprio nel worst case che diventa un evento sporadico.
--
ciao
  Stefano

 ;-)
In effetti non avevo neppure precisato che, dall'altra parte, c'era un
allora nuovissimo e costosissimo HCPL-2601.

 in genere, e si vede poi proprio nel worst case che diventa un evento sporadico.
Sì, ma devi comunque dimensionare il tutto per poterlo gestire e quindi, a
quel punto, perché non usare queste risorse costantemente?
Chiaramente, lo dico per eventuali terzi, stiamo facendo solo due
chiacchere per scambiarci esperienze ed impressioni, non ho dubbi che, per
il tuo specifico problema, tu abbia scelto la soluzione migliore.

il tuo specifico problema, tu abbia scelto la soluzione migliore.
Ti ringrazio per la fiducia, io invece di dubbi ne ho sempre.
Anzi quando prendo una strada sono sicuro che ce n'era un'altra migliore solo
che non l'ho vista.
--
ciao
  Stefano

 o su pagine web 
E ti preoccupi per la latenza dei dati? :D

 E ti preoccupi per la latenza dei dati? :D
Ho visto certi apparati con interfaccia Web per il controllo che sono 
spettacolari. Pagine web degne del miglior sito web, spesso scritte in 
Flash. E lì i dati veloci venivano visualizzati veramente in modo veloce 
senza latenze.
Non chiedermi come facevano, probabilmente il Flash permette di metter 
su una comunicazione dei soli dati in modo da rinfrescare solo quelli 
sulla pagina (e non tutta la pagina).
Ti assicuro che era fatto veramente bene e latenze non ce n'erano.