Newsgroup: it.hobby.elettronica.digitale
Titolo: Rete di Pic

Salve a tutti,
sapete se esistono progetti per la realizzazione di un sistema "bus" che
collega in
rete vari uC PIC ? (...tipo PicNet di Tanzilli).
Grazie mille
Claudio
cmus...@iper.net
--
Posted from 
ns.iper.net
 [194.21.26.1] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

claudio ha scritto:

Ne ho cercati anche io per un mesetto buono, poi ho dedotto che quello
di Tanzilli fosse l'unico in rete e che se uno voleva fare qualcosa di
diverso doveva mettersi li e "inventarselo"
Ciao Paride
-- 
Hiroshima 45, Cernobyl 86, Windows 98, Windows 2000

Io avevo pensato un po' di tempo fa di realizzare qualcosa di diverso dalla
rete di Sergio Tanzilli, ovvero una rete che avesse una maggiore
predicibilità rispetto alla PicNet+ (che funziona con un protocollo del tipo
CSMA/CD). L'idea nasce dal voler collegare una serie di dispositivi di
controllo (es motori, sensori, schede di elaborazione, ecc) via RS485 per
evitare grossi fasci di cavi in apprecchiature complesse. Come modello avevo
preso le reti di campo (Fieldbus foundation, Profibus, ecc), che sono nate
appunto con l'intento di collegare apparecchiature industriali distanti tra
loro con stringenti vincoli temporali di comunicazione.
Attualmente non ho molto tempo per realizzare la cosa da solo, ma se
qualcuno volesse partecipare potremmo formare un gruppo di lavoro via
'news'. Fatemi sapere. Nel frattempo vi formalizzo meglio la mia idea:
* Rete RS485 i cui nodi sono PIC dotati di seriale hardware
   (sono accettati anche altri microcontrollori, ma io ho solo
    il programmatore per i pic)
* Gestione mediante arbitro di bus (PIC od altro se necessario):
* Hardware Plug & Play, il sistema riconosce i nodi sulla rete all'avvio
* Traffico periodico e aperiodico: scambio di dati basato su variabili
   condivise
I dati scambiati dovrebbero riguardare:
* dati primari (variabili, cioè informazioni per il controllo dei processi
   in atto)
* dati secondari (per il controllo dell'affidabilità e il buon funzionamento
   dei nodi)
* dati di taratura
* dati di allarme
Per scambiare le informazioni pensavo ad uno schema di questo tipo:
L'arbitro trasmette sul bus l'indirizzo e il nome di una variabile e
immediatamente l'entità (il nodo) produttore trasmette il valore della
variabile sul bus. Questo è acquisito da tutti i nodi interessati a quella
variabile. L'arbitro utilizza una lista predefinita per mettere in
circolazione le variabili in momenti (intervalli) prestabiliti,
soddisfacendo le esigenze del controllo di processo servito (traffico
periodico).
Oltre tale servizio deterministico ce ne deve essere uno aperiodico su
richiesta per soddisfare esigenze di aggiornamenti o trasmissioni punto
punto direttamente tra nodi.
L'attività dell'arbitro dovrebbe essere divisa rigidamente in cicli, con
finestre temporali destinate ai vari tipi di traffico, stabiliti sulla base
di una priorità, determinata automaticamente nella fase (aperiodica) di
riconoscimento dei nodi della rete.
La velocità dovrebbe essere di 300Kbit/secondo o più. La rete
dovrebbe comunque presentare una discreta affidabilità.
Per quanto riguarda la fase PnP pensavo ad uno schema di questo tipo:
    1) fase di riconoscimento dei nodi: basata sul modello CSMA/CD (al
       reset):
       - l'arbitro si pone in attesa (dopo aver messo sul bus un codice di
         "richiesta di identificazione" asincrono),
       - i diversi nodi attendono un tempo casuale e poi provano a porre il
         proprio ID sul bus (se libero)
       - se c'è un conflitto si torna ad attendere un tempo casuale
       - il tempo casuale è dato da generatori di numeri casuali, stesso
         algoritmo x tutti nodi, differente SEED
       - il SEED coincide con l'ID della scheda (progressivo ed unico), ed è
         un valore ad almeno 16 bit
       - se l'arbitro di bus riconosce la scheda inizia uno scambio di
          informazioni (successivo al riconoscimento di tutte le schede)
       - viene stabilito un tempo max (dall'ultimo riconoscimento) dopo il
         quale si suppone che non ci siano più schede che vogliono farsi
         riconoscere
    2) dopo il riconoscimento avviene uno scambio di informazioni sotto il
        controllo dell'arbitro. Per ogni nodo l'arbitro acquisisce:
    - variabili generate e caratteristiche
    - variabili acquisite e caratteristiche
    - traffico asincrono possibile
    3) l'arbitro costruisce la tabella delle priorità e la schedulazione
       degli accessi ed inizia il ciclo di funzionamento vero e proprio.
Per quanto riguarda il ciclo di funzionamento pensavo a due diverse
possibilità (da valutare):
a) l'arbitro di bus chiama il nodo interessato e gli fa mettere i sui dati
    sul bus. Gli altri nodi ascoltano e acquisiscono i dati se interessati.
b) l'arbitro di bus comunica ad ogni nodo ogni quanti clock_tick può
    mettere i sui dati e quanto max deve durare la trasmissione (inclusa la
    tolleranza). Il nodo quindi prende l'iniziativa quando è il momento.
    Affinchè questo meccanismo funzioni occorre:
       - un servizio di sincronismo periodico (gestito dall' arbitro)
          necessario per compensare le tolleranze nei quarzi
       - ogni nodo deve avere un timer dedicato al clock_tick
       - occorre un meccanismo per rispettare il tempo max ammesso (esempio
          suddivisioine dei dati in più pacchetti, trasmessi in intervalli
          successivi se necessario)
Buona meditazione.
Flavio

Mi interessa , sono a disposizione per sviluppare il progetto,
coordiniamoci.
ciao.
stefano scibilia
hwhis...@tiscalinet.it
Flavio Cappelli ha scritto nel messaggio ...


Io sono abbastanza interessato, i miei "targets" sono:
- controlli
- automazione
- reti
- domotica (lo so, e' cacofonico!)
- porting del SW su LINUX
Ho un programmatore Yapp (firmware 2.7) ed una evaluation board
autocostruiti. Se c'e' l'intenzione di costituire qualcosa di organizzato,
forza... io sono qui
Per adesso forse e' meglio sondare il terreno sul NG, poi vedremo
eventualmente di scambiarci gli indirizzi di email.
ciaux a tutti
Mau

Qualcuno ha gia' provato il programma di Castricini e Marinangeli ?
(
http://www.hth.com/snap
)
Che ne pensate ?
Ciao a tutti


 wrote in message
000901bfaef1$54c34d20$303d15c2@default...


Bene, vedo che la mia idea ha suscitato interesse, propongo quindi di
iniziare una discussione sull'hardware da utilizzare.
Penso che la prima cosa da determinare sia il bit-rate raggiungibile e
l'interfaccia tra il PIC e il bus RS485 in modo da realizzare almeno due
nodi e l'arbitro di bus con cui iniziare poi a provare i protocolli.
Qualcuno ha un'idea abbastanza precisa di che bit-rate un PIC può sostenere
mentre è impegnato in operazioni di controllo classiche, tipo ciclo PID e
generazione di traiettorie ?
Volendo creare una rete abbastanza veloce e indipendente dal uC utilizzato
che ne dite di usare come interfaccia il MAX3140, UART/Transceiver RS485
dotato di interfaccia SPI e buffer fifo di 8 word (in RX) ? L'unico problema
potrebbe essere il package (28 pin QSOP).
E cosa proponete per l'arbitro di BUS ? Dovrebbe in ogni caso avere una
discreta capacità di RAM per la memorizzazione delle tabelle e  dello
scheduling degli accessi al BUS. Sarebbe anche comodo avere una copia di
tutte le variabili scambiate dai nodi con le loro caratteristiche per ovvie
questioni di diagnostica e messa a punto dei protocolli, pertanto propongo
un interfaccina RS232 tra l'arbitro di BUS e un PC. Forse più vantaggioso
sarebbe usare (almeno all'inizio) direttamente un PC come arbitro di bus: il
problema è la bassa predicibilità dei S.O. risolvibile usando Linux con il
modulo RealTime. Ma so che non tutti amano Linux.
A presto.
Flavio
P.S. Per il nome che ne dite di Rete SBCS (Serial Bus for Control Systems) ?
Altrimenti attendo proposte.

 generazione di traiettorie ?
Il bit rate sostenibile da un PIC mentre lavora è abbastanza basso, diciamo
che un 16F84 con clock a 4 mhz potrebbe lavorare in seriale a 2400 baud
senza troppi problemi, se invece si va sui PIC di fascia alta, quelli con
l'UART incorporata, puoi tranquillamente gestire una comunicazione seriale a
19200 baud in real time senza creare troppi problemi alle normali funzioni
di controllo che deve svolgere la MCU, cmq la velocità max raggiungibile è
direttamente in funzione del carico di lavoro normale che ha il PIC.
Se per la tua applicazione lo usi al 100% delle sue possibilità scordati di
farlo dialogare in rete, inoltre usare il collaudatissimo I2C con il
relativo protocollo vi fa poi così schifo ? Usandolo è facile mettere in
rete molti dispositivi (non solo PIC, fino a 127 per ramo) con un piccolo
carico di lavoro per la cpu.
Ciao
Marco d'Ambrosio  
m.dam...@tiscalinet.it
http://utenti.tripod.it/razzimodellismo
    ACME I-RM-05 /TRA L1/
http://web.tiscalinet.it/mda
http://digilander.iol.it/robotica
 (under construction)

relativo protocollo vi fa poi cosě schifo ? Usandolo č facile mettere in
stefano

 Scusa la mia ignoranza, potresti descrivermi il progetto I2C ?
l'I2C non è un progetto ma un'interfaccia hardware/software creata da
Philips un bel po di annetti fa per far colloquire tra loro vari IC (sia
processori che periferiche) in modo semplice ed affidabile.
Detto molto a grandi linee si tratta di una comunicazione seriale sincrona
implementata tramite solo due linee bidirezionali denominate SDA (Data) e
SCL (Clock), in pratica la linea clock serve a sincronizzare la trasmissione
dei dati sulla linea Data, ogni dispositivo ha un numero identificativo ed è
possibile connettere fino a127 dispositivi su una singola linea, il baud
rate può essere anche molto alto (>100kbit/sec).
Se vuoi posso mandarti sulla tua email personale un pò di documentazione
tecnica (in lingua inglese) realtiva al bus I2C, personalmente ritengo che
per mettere in rete una serie di dispositivi basati sulle MCU sia uno dei
modi migliori, se non altro perchè è una cosa che ho già realizzato (per
motivi di lavoro) ponendo in rete con 24 unità per controllo movimento
motori dc basate su processori PIC 16F873 (gestione comunicazione e
generazione comandi) + HCTL1100 (controllo Encoder ottici + generazione PWM
x motori)


Interessa anche a me....   quello che serve a me è più che altro un sistema
per controllare serre...   quindi i PIC non devono fare chissà quali
calcoli!...   devono solo acquisire dati dai sensori..
CMQ nella mia facoltà ci sono un paio di tesi sul controllo di ROBOT..    e
li utilizzano un bus standard industriale.. non mi ricordo come si chiama...
cercatelo qui:  
www.dist.unige.it
Ciao ciao
--
----------------------------------------------------------------------------
--------------------------------------------------
  Alberto Gorni - 
Albert...@ingegneria.studenti.unige.it
  -
san...@libero.it
  Via Emilio Da Pozzo 39/15 - 16133 - Genova (GE) - Italy
  Fast E-Mail; 
san...@mail.omnitel.it
 - Fax: 
+39 178 2219016
  Member of CityLAN - 
http://citylan.floating.net
  Engegnering Leader of G^2Tech - 
http://web.tiscalinet.it/g2tech
----------------------------------------------------------------------------
--------------------------------------------------

tecnica (in lingua inglese) realtiva al bus I2C, personalmente ritengo che
Ti ringrazio, mi servirebbe proprio approfondire questo argomento.
Se tu hai anche uno schema o la descrizione di quello che hai fatto tu,
forse lo potrei utilizzare per il lavoro che devo realizzare.
Grazie in anticipo.
stefano
hwhis...@tiscalinet.it

 ...Usandolo è facile mettere in rete molti dispositivi (non solo PIC, fino
a 127 per ramo) con un piccolo carico di lavoro per la cpu.
Il "piccolo carico di lavoro per la cpu" mi lascia un po' perplesso... stai
parlando di I2C controllato interamente via software usando una porta di I/O
oppure di microcontrollori che dispongono di funzionalita' I2C in hardware?
Nel primo caso mi pare che la cpu debba usare tutto il suo tempo per
campionare SDA e SCL per non rischiare di perdere le transizioni di start e
stop e rimanere "agganciata" al clock generato dall'unita' master... come
hai fatto?
ciao
Claudio

 wrote in message 8eeuf1$


Mai sentito parlare di interrupt ? Non sei obbligato a fare il polling
eterno della linea SDA in attesa che qualcuno la porti a 0.
Per esempio sui PIC16F84 i pin RB4-RB7 quando sono usati come input possono
essere collegati ad un 'interrupt on change', ovvero fino a che la linea
designata non cambia stato il soft del pic si dedica esclusivamente al suo
lavoro, nel momento in cui la linea SDA viene portata a 0 si attiva la
routine di interrupt e inizi a gestire la comunicazione I2C.
Lo stesso concetto vale anche per la ricezione/trasmissione dei dati, se
questa non avviene a velocità elevatissime (il 90% dei casi) puoi usare
l'interrupt anche per gestire gli impulsi di clock, tra un bit e un'altro
che ricevi/trasmetti la tua cpu continua a lavorare al suo compito primario.


 ha scritto nel messaggio
news:vjEO4.60073$xt2.7...@news.infostrada.it...

mhmm... mi potresti inviare il codice giusto giusto per il 16F84....
anzi.. già che son qui a "romperti le scatole..."  :-)   lo hai percaso in C
oppure direttamente in ASM??
Grazie
Ciao


 tecnica (in lingua inglese) realtiva al bus I2C,
se non è troppo... "ingombrante" (leggi 10MB di .pdf) me la mandi anche a
me!?!?
Te ne sarei grato!!..   e a proposito... i pic come la gestisono!??  in modo
"trasparente" o bisogna sbattersi di bestia per farla andare!?!
Grazie e ciao
--
 ---------------------------------------------------------------------------
--------------------------
   Alberto Gorni - IW1REL - 
Albert...@ingegneria.studenti.unige.it
  -
san...@libero.it
   Via Emilio Da Pozzo 39/15 - 16133 - Genova (GE) - Italy
   Fast E-Mail; 
san...@mail.omnitel.it
 - Fax: 
+39 178 2219016
   Member of CityLAN - 
http://citylan.floating.net


   Member of CityLAN - 
http://citylan.floating.net
