Newsgroup: it.hobby.elettronica.digitale
Titolo: Probabilità collisioni

Ciao,
ho una scheda che in base a un file di dati invia su un bus seriale dei 
pacchetti verso unitï¿œ periferiche. A spanne diciamo che ï¿œ composta da 
una manciata di byte a 38400 bps, quindi dura meno di 350 us.
La distanza tra due tramissioni ï¿œ "casuale" nel senso che dipende dal 
file utilizzato ma tipicamente ï¿œ mooolto difficile che avvenga prima di 
2-3 secondi, spesso invece avviene anche dopo decine di secondi.
Bene, ora dovrei aggiungere al bus (almeno) una scheda che si occupa di 
monitorare 16 ingressi digitali: sono pulsanti o sensori PIR.
Scopo del gioco ï¿œ far sapere al controller centrale lo stato di questi 
ingressi.
La soluzione piï¿œ ovvia sarebbe il polling, perï¿œ questo mi costringerebbe 
a inviare continuamente (almeno ogni 100 ms) il pacchetto di 
interrogazione e ciï¿œ comporterebbe un aggravio del carico a cui giï¿œ ï¿œ 
sottoposto il micro. Senza contare di dover gestire un sistema di 
semafori per coordinare anche la tramissione dei pacchetti di cui 
all'inizio.
Vice versa, potrei far prendere l'iniziativa alla scheda periferica 
stessa di inviare il pacchetto (anche qui di circa 350 us) quando si 
verifica un cambiamento sugli ingressi.
A naso la probabilitï¿œ di una collisione ï¿œ abbastanza remota, ma 
ovviamente vi puï¿œ essere. Io ho pensato a questa soluzione per arrivare 
a un compromesso, vediamo perï¿œ se ce ne sono di migliori:
- tenuto conto che la trasmissione dall'unitï¿œ centrale non potrï¿œ mai 
essere cosï¿œ ravvicinata da creare problema e che il bus ï¿œ broadcast, se 
NON sono in fase di ricezione posso trasmettere tranquillamente, in 
entrambe le direzioni. Se invece sto ricevendo, attendo giusto la fine 
del pacchetto e poi invio.
In questo caso la probabilitï¿œ di collisione dovrebbe essere trascurabile 
perchï¿œ la finestra critica ï¿œ limitata alla latenza dell'interrupt 
relativo al primo carattere trasmesso.
Che ne dite?
Marco

 relativo al primo carattere trasmesso.
Che la probabilita' sia bassa non conta, perche' se qualcosa puo' 
accadere allora accadra' sicuramente (e qualcuno dice anche nel momento 
meno opportuno;)
Quindi la domanda da porti e': posso perdere qualche pacchetto ogni tanto?
Se la risposta e' no allora in genere si riceve cio' che si sta 
trasmettendo per verificare che non sia stato corrotto da una 
trasmissione contemporanea di un altro master, nel qual caso si ripete 
la trasmissione (magari dopo un tempo random), quasto e' il MA/CD 
(multiple-access-with- collision-detection).
ciao
Claudio_F

 (multiple-access-with- collision-detection).
Perï¿œ questo comporterebbe una modifica hw immagino e non posso farla :(
La trasmissione ï¿œ su RS485 e quindi dovrei inserire a monte del driver 
un circuito di loopback per ricevere durante la trasmissione.
Marco

 un circuito di loopback per ricevere durante la trasmissione.
Tornerebbe a fagiolo la descrizione della vecchia rete picnet di 
Tanzilli, che faceva proprio cio' che dici. Nessuna modifica hw, il lato 
ricezione del driver 485 era sempre attivo per cui in ogni caso si 
poteva sepre ricevere quello che si trasmetteva... a meno che il tuo non 
sia un driver sola trasmissione.
In questo caso io farei trasmissioni multiple... due distanziate di 
qualche millisecondo gia' dovrebbero bastare (trasmettendo uno stato e 
non una variazione).
ciao
Claudio_F

 non una variazione).
Si si, trasmetto sempre degli stati io :D
In effetti ï¿œ forse il sistema piï¿œ semplice, ora ci penso un po' su.
Marco

 In effetti è forse il sistema più semplice, ora ci penso un po' su.
Direi che funziona, perche' al massimo uno dei due pacchetti viene 
corrotto (entrambi i master dovranno fare due trasmissioni separate da 
un diverso numero di millisecondi).
Se pero' in futuro vorrai aggiungere un terzo master allora siamo da capo ;)
ciao
Claudio_F

 capo ;)
Certamente. Grazie della discussione, vedrï¿œ come procedere.
Marco