consiglio per protocollo

ice:

CAN

Il giorno Mon, 02 Nov 2009 14:33:00 GMT, ice ha scritto:

Una rete in RS485 è una soluzione, più consigliabile però con un master-slave. In alternativa penserei al CAN bus.

Ci sono, però devi prevedere e correggere i data collision, un discreto casino, cosa che invece il CAN fa da solo nel controller.

Il CAN può fare 125 kbit/s per distanze di 500 m, a 1Km la velocità sarà grossomodo la metà.

Se decidi questa strada ci sono il CanOpen - Devicenet su cui si trova parecchia roba.

-- ciao Stefano

SB:

Per las precisione, le data collision, col CAN, vengono rilevate dal trasmittente stesso, quello a più bassa priorità interrompe la trasmissione prima ancora di generare alcun errore sulla rete.

Il giorno Mon, 02 Nov 2009 15:45:48 +0100, SB ha scritto:

Ti serve anche un aggeggio come questo:

-- ciao Stefano

Il giorno Mon, 2 Nov 2009 15:51:54 +0100, "F. Bertolazzi" ha scritto:

E' vero, ma quello a priorità più alta deve comunque ripetere la trasmissione. Difatti nella gestione più sofisticata del protocollo resta traccia nei log di queste collisioni.

Ma la cosa più interessante per ICE è che la gestione è fatta dal controller in modo automatico e trasparente.

-- ciao Stefano

SB ha scritto:

quindi inutile sbattersi ad implementare il protocollo?

conviene scegliere un micro con CAN integrata (alcuni modelli di PIC so che c'è l'hanno) oppure un controller CAN da mettere esternamente al micro?

grazie

-ice-

SB:

Ne sei certo? Quello a priorità più bassa è tale perché ha, nel suo node-address che inizia il messaggio CAN, un bit recessivo, mentre quello a priorità più alta ha un bit dominante, che quindi "sovrascrive" quello recessivo. A questo punto il nodo a priorità più bassa si accorge che sul bus c'è un bit dominante anzichè il recessivo che ha trasmesso lui ed interrompe la trasmissione, senza aver minimamente turbato il messaggio del nodo dominante.

Se poi c'è qualche nodo che non è sincronizzato con gli altri per via di tolleranze sballate o per la lunghezza del bus, non so.

Una seriale similCAN è anche facilmente implementabile via software con gli AVR, e non necessita di alcun hardware aggiuntivo, a parte resistenze di terminazione e componenti di protezione. Su mezzo cavo CAT5 si possono far passare alimentazione e dati.

Basta usare i pin del comparatore e settarli, come valore in uscita, uno alto ed uno basso. Se si trasmette un bit dominante si mettono i pin in output, se si trasmette un bit recessivo li si mette in input e si controlla che l'uscita del comparatore sia effettivamente corrispondente alla configurazione recessiva, altrimenti si interrompe la trasmissione e ci si rimette in ascolto per aspettare la fine del messaggio e riprovarci.

ice:

Il solo controller CAN esterno che ho usato è quello della Microchip, ed è un discreto casino da usare.

Il giorno Mon, 2 Nov 2009 16:36:12 +0100, "F. Bertolazzi" ha scritto:

Si, dal momento che è un open collector può rilevare la trasmissione bit per bit e quindi accorgersi se è stato trasmesso uno zero quando lui vuole passare un uno.

Può restare traccia magari solo im quello a priorità più bassa, adesso non ricordo i dettagli, ma ricordo i log abbastanza dettagliati.

Mi ricordo che dicevi di aver fatto qualcosa con un AVR, ma se ICE ha necessità di sfruttare la velocità non so se gli conviene provare questa strada o partire con un controller finito.

Io ho usato un AT90CAN128 e sul sito Atmel si trova un appnote molto utile.

Anni fa ho usato un controller Philips, non ricordo la sigla, forse era un antenato di questo:

-- ciao Stefano

SB ha scritto:

in effetti sarei più orientato al controller finito... il top sarebbe un bridge che si interfacci al micro (spi, I2C, parallel-load, ...) e si fa carico di tutto il resto per andare sul bus CAN

ora mi guardo i link che mi hai girato; cmq si, la scelta è decisamente il CAN

-ice-

SB:

Ni. Ti confondi col LIN, anche se il CAN, essendo fondalmentalmente un RS-422 che o trasmette un mark o non trasmette nulla, è, a tutti gli effetti, la stessa cosa.

Chi può saperlo meglio di te? Sì, proprio loro, i cacchio di estensimetri per i cacchio di alberi in carbonio. Approposito, grazie ancora e, dimenticavo, eccoti alcune foto. Acc, no, una sola, il "controller di anello" con gli optoisolatori e il DC-DC non lo trovo più.

I dettagli dati sono piuttosto vaghi.

Immagino di sì. L'avevo valutato, ma quello Microchip, ai tempi, era meglio. E comunque già solo studiare i datasheet relativi è un lavoro più lungo che non implementare una UART via software.

Il giorno Mon, 2 Nov 2009 17:28:45 +0100, "F. Bertolazzi" ha scritto:

Effettivamente non potrebbero andare @ 125Kb a 500 metri con un oc.

Qui specifica meglio il CAN, per ICE

ed elenca diversi fabbricanti di drivers e transceivers.

Bellino, alla fine ha funzionato?

Quello con il AT128CAN ha funzionato quasi subito, ma la librerie erano già pronte.

L'altro non ricordo, mi sembra ci fosse addirittura su un NTSC800, un misto tra

8080 e Z80 che usavo diversi lustri fa. Roba che adesso è da museo, tanto per dire:

oramai mi sento un fossile anch'io ;-)

-- ciao Stefano

SB ha scritto:

ottimo link; grazie!

-ice-

F. Bertolazzi:

Da sinistra a destra:

- Il primo prototipo, analogico (anche se c'era il posto per un ATtiny25) con i trimmer di offset e gain per l'AD 631 e il TS922 che pilotava cosa? Il gain? Boh.

- Il primo prototipo digitale, ovvero quando ho scoperto che, con il debugwire, non si possono programmare i fusibili, da cui il connettore a pin che s'è un po' scivertato. L'A/D è stato recuperato ed usato altrove.

- La schedina concentratore/disaccoppiatore. Ci sono due fotoaccoppiatori per poter anche mandare comandi alle schedine di raccolta dati. Il DC-DC è il coso nero sulla sinistra, montato così per minimizzare lo spessore del tutto. I componenti mancanti erano la terminazione del bus (totalmente isolata dal resto), disegnata prima di scoprire che non c'è modo di fare un giro completo dell'albero con i fili.

Un bel giorno F. Bertolazzi digitò:

Il MCP2515? Scherzi? E' una manna dal cielo! Con tre comandi ci fai tutto, figurati che lo uso persino collegato alle FPGA (senza soft processor, in VHDL nudo e crudo!).

--
emboliaschizoide.splinder.com

dalai lamah:

Certo, se sai quali usare, e se non devi usare i loro cervellotici filtri.

E, a ripensarci, se sai come funziona il CAN e non lo devi dedurre da un datasheet. ;-)

dalai lamah:

No, quello prima, quello con più bachi che transistor.

Il giorno Mon, 2 Nov 2009 18:56:17 +0100, "F. Bertolazzi" ha scritto:

[...]

Mi sembra di capire che non hai finito, spero tu sia riuscito a riscuotere.

Una soluzione da tener presente con problemi di ingombri, o anche per risparmiare le strip, da un genovese... ;-)

La crisi picchia duro anche qui, e oltre al calo del fatturato è anche difficile incassare.

-- ciao Stefano

SB:

No, non ho finito perché si è rifiutato di corrispondermi le spese vive, documentate, per quanto realizzato fino al punto in cui sono arrivato. Ma non l'avevo raccontato estensivamente, col cabernet berto che sparava cazzate a raffica?

Per l'incasso ho avviato una procedura giudiziaria da qualche mese. Per fortuna rientriamo nel range del giudice di pace, quindi dovrebbero volerci meno di 12 anni.

Eh, so' soldi.

difficile

E poi si chiedono perché mettimao lo scudo fiscale al 5% mentre gli Americani lo mettono al 50%. Se hai dei soldi all'estero, li porti in un paese dove le tasse sono troppo alte, i sindacati troppo ingordi e la Giustizia non funziona?

E' questa percentuale del 5% (ed il modesto livello di adesione) che indica quanto vale il nostro Paese.