blisca <blisca_ snipped-for-privacy@tiscali.it ha scritto:
Se il protocollo è custom, come ha scritto pozz, quando vuoi inviare 20 byte su 485 fai 20 scritture da 1 byte verso l'interfaccia fisica, su CAN puoi fare 2 scritture di 8 byte e 1 da 4, o 4 scritture da 5 byte, o qualsiasi altra combinazione per arrivare a 20, compresa la 20 scritture da 1 byte. Al destinatario arrivano sempre gli stessi 20 byte, esattamente come gli arrivavano con la 485.
Ciao,sicuramente a queste domande sarà già stato risposto 20 o 30 anni fa,ma alcune risposte che ho letto mi sono sembrate poco chiare
2)IL filtraggio del contenuto dei messaggi.Il messaggio di un data frame del CAN non-extended è costituito ,tra l'altro di ID a 11bit e payload. Il filtraggio si applica solo all'ID o potrei filtrare anche per contenuto del payload? Grazie neh
Un bel giorno blisca digitò:
No, il bus deve essere terminato solo alle due estremità, non su ogni nodo.
Non ho mai visto controller che ti consentano di fare questo. Non credo che sia previsto dallo standard.
Lo puoi fare in software, ma questo è ovvio.
Il 30/01/2024 10:51, dalai lamah ha scritto:
Un nodo intermedio quanto puo' essere distante dal bus principale?
Un bel giorno RobertoA digitò:
Lo standard mi pare che richieda al massimo 30 cm. Se hai un singolo nodo intermedio molto distante da tutto il resto, può valere la pena di "raddoppiare" i fili, cioè invece di fare così:
N1 -------------+------------- N2 | | | | | | N3
Fare così:
N1 -----------+ +----------- N2 | | | | | | | | | | +-+-+ | N3
In ogni caso nei casi più complessi subentra la parte empirica, come accade spesso con argomenti che hanno a che fare con la signal integrity.
C'era una bella app note della Texas Instruments che parlava di queste cose ma ora non la trovo più. Ho trovato questo che parla in generale di cose da fare e da non fare:
Il 30/01/2024 10:51, dalai lamah ha scritto:
In effetti ora trovo solo link che me lo confermano,grazie
Certo,come hai capito intendevo il filtraggio hardware,dei filtri configurabili ,per esempio quelli nel modulo CAN di un microcontrollore Ok,grazie ancora
Il 30/01/2024 09:28, blisca ha scritto:
Mi aggiungo a questa discussione per una mia domanda sul CANbus, premettendo che lo conosco molto poco.
Spessissimo uso un bus RS485 half-duplex a "due fili" (tra virgolette perché ci devi comunque passare anche il riferimento di massa). Mi costruisco sopra il protocollo che voglio, praticamente sempre master-slave.
Ecco, l'approccio master-slave è qualcosa che voglio superare. Dover avere un master che deve fare polling su tutti gli slave per domandare se hanno qualcosa da dire, anche se inviano solo 100 byte all'ora, è uno spreco di banda enorme.
Così il multi-master del CANbus, implementato a livello molto basso, mi affascina. Però ho sempre avuto paura dei frame estremamente piccoli (se non ricordo male, in ogni frame puoi trasferire solo OTTO byte di dati).
In molte applicazioni devo trasferire tanti dati, diciamo qualche kB (spesso ho a che fare con liste di stringhe). E' uno scenario affrontabile con il CANbus?
Il 31/01/2024 09:07, pozz ha scritto:
Dalle mie domande è evidente che anch'io ne so poco Con l'FDCAN,implementabile su vari microcontrollori conme STM32431G puoi inviare 64 bytes di payload anzichè 8
"pozz" ha scritto nel messaggio news:upcv3k$1e5p7$ snipped-for-privacy@dont-email.me...
se gia' lo facevi con una interfaccia che poteva trasmettere solo un byte per volta (RS485), cosa ti preoccupa nel poter trasmettere 8 byte per volta ?
Il 31/01/2024 19:14, alfio ha scritto:
Ciao Alfio, secondo me non è l' esempio ideale perché RS485 dovrebbe essere solo l'interfaccia a livello fisico coi segnali in controfase ecc ,e potrebbe essere utilizzata con qualsiasi raggruppamento di bit o bytes. Per esempio nel Modbus che spesso è usato con RS485, nessuno vieta di richiedere o inviare il contenuto di 20 registri a 16bit in un singolo messaggio. Spero di non aver detto una boiata
Il 31/01/2024 23:40, alfio ha scritto:
Beh, però perdi un frame di lunghezza decente.
Normalmente su RS485 faccio dei frame di lunghezza anche di centinaia di byte. Il ricevitore li sposta in un buffer in RAM (tramite polling, interrupt o DMA) e individua la sua fine (tramite un suffisso fisso, una lunghezza fissa o comunque nota perché indicata ad inizio frame...)
A questo punto l'applicazione si ritrova il buffer di 200 byte bello pronto, può farci il parsing, il controllo di checksum e recuperare quello che serve, spostando per esempio le stringhe in variabili in RAM che serviranno al normalmente funzionamento.
Su CAN il concetto di frame si sposta ad un livello più alto. Immagino che il driver mi dia 8 byte di cui l'applicazione non se ne fa immediatamente nulla (potrebbe tranquillamente essere un pezzo di stringa da 20 caratteri). Deve spostarli e pusharli in un altro buffer. Non dico che non si possa fare, è solo più complicato.
Inoltre immagino che aumenti l'overhead. Su un payload di 200 byte, su RS485 posso immagina 10 byte di overhead (prefisso, suffisso, checksum, indirizzi, ecc. ecc.), quindi un 5% di overhead. Stando qui[1] Su CAN vedo 47 bit per un frame da 8x8=64 bit... siamo al
73%!! [1]Un bel giorno pozz digitò:
"Spreco" è un concetto relativo. Stai parlando di comunicazioni attraverso connessioni a consumo? Altrimenti non vedo il motivo di preoccuparsi dello spreco di banda. A meno che tu non abbia un bus talmente congestionato che anche qualche pacchetto di pochi byte ti causi problemi, ma in quel caso direi che il problema su cui concentrarsi sia la congestione.
Anche in questo caso, "affrontabile" è un termine relativo. Attraverso CANOpen (che è praticamente il "livello rete" del CAN bus) si trasferiscono comunemente anche dei megabytes, ad esempio per l'aggiornamento firmware di centraline automotive o cose del genere. Ma è ovvio che se ti serve un bus di comunicazione il cui scopo principale sia quello di spostare molti dati e più velocemente possibile, CAN bus non è la prima scelta, non solo per l'overhead ma soprattutto per il fatto che la sua bit rate è generalmente limitata a 1 Mbps.
"pozz" ha scritto nel messaggio news:upfhqm$1vga5$ snipped-for-privacy@dont-email.me...
Il 31/01/2024 23:40, alfio ha scritto:
Beh, però perdi un frame di lunghezza decente.
Normalmente su RS485 faccio dei frame di lunghezza anche di centinaia di byte. Il ricevitore li sposta in un buffer in RAM (tramite polling, interrupt o DMA) e individua la sua fine (tramite un suffisso fisso, una lunghezza fissa o comunque nota perché indicata ad inizio frame...)
A questo punto l'applicazione si ritrova il buffer di 200 byte bello pronto, può farci il parsing, il controllo di checksum e recuperare quello che serve, spostando per esempio le stringhe in variabili in RAM che serviranno al normalmente funzionamento.
si fa come hai scritto prima, quello che ricevi lo metti in un buffer che poi interpreti. il can e' solo il livello fisico, come lo e' la 485.
certo, e' una soluzione con i suoi pro e contro, ma non per questo si realizza in maniera diversa dalla 485.
nel tuo conto precedente su 485 mancano alcuni bit, perche' per ogni 8 di dati ne devi trasmettere 10 (o 11 se vuoi anche la parita'). facendo un paragone tra i 2 sistemi con un frame composto da: addr[1] + data[8] + crc[2], cioe' un frame can.
RS485 = 10 * (1+8+2) = 110 bit CAN = 47 + 8*8 = 111 bit
ovviamente la 485 vince alla grande quando il numero di byte di dati aumenta. nel tuo esempio da 200 byte diventa: RS485 = 10 * (200+10) = 2100 bit CAN = 111 * (200/8) = 2775 bit
"alfio" ha scritto nel messaggio news:upgk0p$25ih2$ snipped-for-privacy@dont-email.me...
oops, ho quotato da bestia !
si fa come hai scritto prima, quello che ricevi lo metti in un buffer che poi interpreti. il can e' solo il livello fisico, come lo e' la 485.
certo, e' una soluzione con i suoi pro e contro, ma non per questo si realizza in maniera diversa dalla 485.
nel tuo conto precedente su 485 mancano alcuni bit, perche' per ogni 8 di dati ne devi trasmettere 10 (o 11 se vuoi anche la parita'). facendo un paragone tra i 2 sistemi con un frame composto da: addr[1] + data[8] + crc[2], cioe' un frame can.
RS485 = 10 * (1+8+2) = 110 bit CAN = 47 + 8*8 = 111 bit
ovviamente la 485 vince alla grande quando il numero di byte di dati aumenta. nel tuo esempio da 200 byte diventa: RS485 = 10 * (200+10) = 2100 bit CAN = 111 * (200/8) = 2775 bit
Il 01/02/2024 09:35, dalai lamah ha scritto:
Normalmente il polling non è un problema... ma in alcune situazioni sì.
Immagina di aver un certo numero di nodi (diciamo 20) che parlano molto poco. Però è utile, per migliorare la reattività e l'usabilità da parte del cliente finale, che, almeno per alcuni, l'informazione che dicono arrivi in tempi rapidi al master.
Nel caso peggiore devi fare un giro di 20 polling. Non è tanto il numero di byte di andata e ritorno (moltiplicato per 20), ma potrebbe esserci una latenza con gli slave rispondono al polling. Ci devi mettere dei ritardi per dare la possibilità a tutti i transceiver di girare direzione prima di inviare il successivo frame.
Poi magari uno slave non risponde affatto perché è staccato, malfunzionante o chissà cosa, ma il master deve cercare di recuperarlo laddove dovesse ricollegarsi. E quindi il giro di polling si ferma per un timeout su quello slave.
Alla fine di tutto, in casi sfortunati, la reattività del sistema non è delle migliori. Eppure il payload di dati è bassissimo.
Con un multi-master questo non succederebbe.
No, non è questo lo scopo. Normalmente i miei sistemi hanno una configurazione di qualche kB che deve essere nota a tutti gli slave, ma non cambia pochissime volte.
Prima o poi darò un'occhiata a questo CAN.
Un bel giorno pozz digitò:
Ah ok... allora sì. Probabilmente ci si può inventare qualcosa "copiando" da altri protocolli. Ad esempio così: quando un nodo vuole inviare un aggiornamento al master, invia un pacchetto speciale sul bus composto da tutti 0 (una specie di "lungo start bit"). Quando il master rileva un pacchetto (anche malformato), interroga tutti i nodi in sequenza. Se lo slave non riceve l'interrogazione entro un certo timeout, reinvia il pacchetto dopo un tempo casuale o con un timing furbo (es. una specie di "exponential backoff" dei Ethernet).
In questo modo se due slave trasmettono contemporaneamente, non importa che vadano in collisione in quanto il master comunque "chiederà" a tutti. Se uno slave trasmette mentre il master trasmette, quest'ultimo non riceverà una risposta valida (supponiamo di parlare di MODBUS) e riproverà a richiederla dopo un tempo casuale o con timing furbo.
Il 02/02/2024 18:59, dalai lamah ha scritto:
Essì, oppure CAN bus dovrebbe risolvere il problema.
Il giorno Fri, 2 Feb 2024 15:50:05 +0100, pozz snipped-for-privacy@gmail.com ha scritto:
Io in una situazione anche peggiore, con un master e + di 40 slave ho usato un trucchetto per risparmiare banda.
In pratica ho aggiunto un terzo filo, oltre ai 2 della RS485, con una resistenza di pullup sul master e usato come input open collector. In pratica ogni volta che un dispositivo ha qualcosa da comunicare il filo si abbassa e inizia il polling fino a quando il dispositivo che ha richiesto la linea comunica i suoi dati, poi rialza la linea.
In questo caso il polling avviene solo su richiesta e solo quando c'è effettivamente qualcosa da fare, in pratica per la mia applicazione l'utlizzo della linea è passato da più di una scansione al secondo a una molto più scarsa, al punto che facevo fatica a vederla sull'oscilloscopio.
Invece la risposta agli input dei sensori è più rapida, magari è meglio mettere il numero più basso a un sensore che può cambiare spesso e lasciare quelli lenti in fondo alla scansione, ad esempio i sensori di temperatura ambiente, che vengono letti ogni tanto.
Chiaramente questo si può fare se si controlla l'hardware del master e degli slave, e magari non è adatto a tutte le situazioni, però a me ha dato buoni risultati.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required