Subject:
|
Velocità del firmware Lego
|
Newsgroups:
|
lugnet.loc.it
|
Date:
|
Wed, 10 Apr 2002 08:42:02 GMT
|
Viewed:
|
432 times
|
| |
|
|
Per quelli che non leggono robotics, o nel caso che a qualcuno sia sfuggito,
questo è un post illuminante sulla velocità di esecuzione dello
pseudo-codice sul RCX quando si utilizza il firmware originale Lego (e
quindi anche NQC):
http://news.lugnet.com/robotics/?n=17666
Sintetizzo i punti salienti per quelli che hanno difficoltà con l'inglese:
- La velocità media di esecuzione di un'istruzione, con il firmware 3.09
(RIS 1.0 e 1.5) è di 2ms, che significa 500 istruzioni al secondo.
- Il firmware 3.28 (RIS 2.0) ha aumentato il tempo di esecuzione del 50%,
portandolo a circa 3ms per istruzione, pari a 330 istruzioni al secondo.
L'aumento è dovuto alla gestione degli eventi e ad altre caratteristiche
introdotte nel sistema.
- La maggior parte di questo tempo deriva da attività di gestione del
sistema. Nel caso del firmware 3.09 circa 1.75ms sono utilizzati dal SO
(gestione dei task, sensori, motori, display, batteria...) e 0.25ms per
interpretare ed eseguire l'istruzione. Ciò rende il multitasking
"vantaggioso" in termini di tempo, dato che ogni 1.75ms di tempo di SO viene
eseguita una istruzione da 0.25ms per ogni task. Quindi, con un task abbiamo
una istruzione ogni 2ms, mentre con 5 tasks 5 istruzioni ogni
1.75+0,25*5=3ms, pari a un tempo medio di 0.6ms per istruzione.
Dal punto di vista pratico questa estrema lentezza conferma ciò che avevamo
già sperimentato "sul campo": NQC (e tutti i linguaggi basati sul firmware
originale) non è assolutamente idoneo per applicazioni dove la reattività è
fondamentale.
Un esempio: supponiamo che abbiate costruito un robot per una gara tipo Gran
P-RIS, che viaggia alla tranquilla velocità di 50cm/s (se ricordate Indy
viaggiava a 70cm/s, e i dragster a 130-150cm/s). Supponiamo ancora che nel
momento in cui il robot si accorge di essere sul bordo abbia bisogno di 10
istruzioni (1) per intraprendere l'azione correttiva. A 3ms cadauna
(firmware 3.28) devono passare 30ms, 1/33 di secondo, duranti i quali il
robot ha già percorso 1.5cm! Aggiungiamo che i motori hanno bisogno anche
loro di qualche ms per vincere l'inerzia del veicolo, e a questo punto il
robot è già in difficoltà: dato che si è "addentrato" nel bordo la
correzione che deve eseguire è molto maggiore di quella che gli sarebbe
bastata con un tempo di reazione minore.
Sapevamo che scrivere codice in NQC comportava questi inconvenienti, ma non
immaginavo che i tempi fosserò così dilatati. 3ms per istruzione sono
veramente un'eternità.
Ciao
Mario
1) Basato sul numero medio di istruzioni eseguite dal mio codice.
"Istruzioni" in realtà vuol dire opcodes nativi, e una istruzione NQC
complessa può essere espansa anche in più opcodes. 10 istruzioni non sono
tante se si tenta di adottare una strategia più sofisticata della mia.
Paradossalmente, più la strategia è sofisticata, più rischia di essere
penalizzata per l'incremento del tempo di reazione :-)
|
|
Message has 1 Reply:
 | | Re: Velocità del firmware Lego
|
| (...) Quando ho letto il messaggio originale mi sono cadute le braccia ... effettivamente non è lento ... E' FERMO !!!! 8-))))) Mi ero accorto "a naso" che la velocità di esecuzione non fosse questo gran che, ma 3ms per istruzione fanno (...) (23 years ago, 10-Apr-02, to lugnet.loc.it)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
