Subject:
|
Re: Idea per ELF. Riassunto.
|
Newsgroups:
|
lugnet.loc.it
|
Date:
|
Tue, 28 Dec 1999 02:12:10 GMT
|
Viewed:
|
597 times
|
| |
|
|
> Sono d'accordo.
> Sara' certamente necessario identificare ogni RCX che partecipera'
> al coro con un ID univoco. Il "direttore" dovra' quindi prevedere
> una fase iniziale di assegnazione di questi ID. Un'idea potrebbe
> essere quella di accendere i "coristi" uno per volta da destra a
> sinistra, dando modo al maestro di incrementare ogni volta un suo
> contatore dei componenti del coro, contatore che va a comunicare
> via via ad ogni nuovo corista che si aggiunge. In questo modo
> tutti i coristi possono avere lo stesso software, sara' il
> direttore a differenziarli nella fase iniziale.
Già tutto ideato come tu dici. In + il software del maestro, dato il totale
dei coristi, dividerà per area centrale, destra e sinistra. Tutto ciò con
una semplice operazione di div intera.
(tra l'altro questo tuo messaggio mi ha ridimensionato i problemi in testa.
Per il progetto chorus non ci sono problemi di collisione, visto che
trasmette solo il maestro, per cui va benissimo l'NQC :-)) )
> Questa strada mi sembra poco praticabile, perche' pone limiti
> seri o al numero di partecipanti del coro o al payload di ciascun
> byte inviato (se i coristi sono p.es. piu' di 8 puoi veicolare solo
> 4 bit di informazione). Inoltre la decodifica dei messaggi puo' essere
> piuttosto onerosa, se consideri che in NQC le funzioni di scorrimento
> dei bit agiscono solo sulle costanti e non sulle variabili. In pratica
> bisognerebbe implementare "a manovella" gli operatori ">>" e "<<" con
> spreco di variabili preziose, nonche' di tempo macchina.
Come scritto prima, per questo progetto non c'è bisogno di infrastrutture di
networking complesse. Sono dunque daccordo con te.
> Questa mi sembra decisamente la strada da percorrere.
> Bisognera' solo fare in modo che i byte di "inizio" e "fine" non
> possano essere presenti nei byte del contenuto. Inoltre farei anche
> in modo che il destinatario, una volta ricevuto il byte "fine", mandi
> un messaggio di ACKnowledgement al mittente. In mancanza di ACK il
> mittente trasmettera' il messaggio di nuovo.
I messaggi multi byte sono stati pensati dall'inizio. Il messaggio sarà
composto da 2 byte di range (specificano il gruppo di esecutori a cui è
destinato il messaggio), 1 byte (o +?) che specifichi la nota da suonare, 1
o 3 eventuali byte per il codice del colore da riprodurre (nel caso in cui
questi siano assenti l'algoritmo produrrà tonalità associate alle note), 1
byte di chiusura.
I codici da me pensati includono il 255 come terminatore e il 254 come
codice di escape. Il codice per l'inizio messaggio potremmo ometterlo, visto
che si tratta di una situazione con un'ottima "visibilità" ed un'elevata
sincronia. Eventualmente potremmo usare lo 0. Naturalmente, nel caso in cui
si debba trasmettere un 255 o un 254 durante il messaggio, dovremo
trasmettere prima un 254 di escape.
> P.S. Qualcuno sa qual e' la velocita' di invio dei messaggi
> con la funzione SendMessage() di NQC?
Mi sembra di aver letto 9600 Kbps.
|
|
Message has 1 Reply:
 | | Re: Idea per ELF. Riassunto.
|
| (...) OK (...) Guardando il manuale di NQC mi sono accorto di un problema che forse ti costringera' a rivedere un po' l'impostazione del progetto: PlayTone("frequency", "duration"); Plays a single tone of the specified frequency and duration. The (...) (25 years ago, 1-Jan-00, to lugnet.loc.it)
|
Message is in Reply To:
| | Re: Idea per ELF. Riassunto.
|
| (...) Sono d'accordo. Sara' certamente necessario identificare ogni RCX che partecipera' al coro con un ID univoco. Il "direttore" dovra' quindi prevedere una fase iniziale di assegnazione di questi ID. Un'idea potrebbe essere quella di accendere i (...) (25 years ago, 27-Dec-99, to lugnet.loc.it)
|
11 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
