Ciao Ragazzi,
sia @Danveal che @Ciskje hanno fatto un ottimo lavoro , partendo da approcci molto diversi e comunque altrettando validi . Sicuramente le risorse HW di un arm7 a 60 Mhz non sono paragonabili a un ATmega a 8 bit e 16-20 Mhz di clock. Tante volte pero' e Elnonino ce lo insegna gestire in modo ottimale risorse HW con un linguaggio di basso livello puo' portare a performance di tutto rispetto anche su micro con meno risorse dei fratelli maggiori.
Un esempio di facile comprensione è la differente efficienza di un hardware con sistemi operativi diversi .. per esempio io sto' usando un mac che se monta Mac OSX o Windows cambia drasticamente nelle sue performances verso l'utente finale ... per esempio all'accensione un mac ci mette 3-4 secondi windows invece se va bene sei attorno al minuto prima di poterlo impiegare normalmente.
Quindi il fattore di come si scrive il software è fondamentale per l'efficienza dell'HW. Mi fa' piacere ad esempio che i test di Ciskje confermano che qualche mhz in piu' su Multipilot rispetto ad un arduino standard portano ad un incremento interessante delle prestazioni. I compilatori Basic non hanno mai brillato per efficienza del codice prodotto è molto che non li uso e sui micro non li ho proprio mai usati , ma in ambiente pc non hanno mai creato codice troppo ottimizzato.
Per fare un confronto concreto bisognerebbe scrivere del semplice codice di benchmark sia in C++ che in Basic e vedere sulla stessa piattaforma i risultati dei test che risultati danno. In merito alla possibilità di lavorare assieme a progetti complessi sicuramente il C/C++ è il linguaggio principe.
Il basic ha un po' di limiti e non ha sui micro community così ampie come quelle di arduino .
In merito ai problemi del codice nidificato ... mhhh ... il problema non è tanto nei cicli for che comunque indubbiamente rallentano i processi computazionali , ma secondo me il problema è sulle chiamate a funzioni ricorsive , dove su di un micro avendo una profondità di stack molto bassa si rischia di andare out of stack e perdere il controllo del codice ... e da li si esce solo con un buon watchdog. Che purtroppo su di un quad potrebbe avere conseguenze catastrofiche ...
Questi piccoli accorgimenti a livello di programmazione , come tenere sott'occhio l'allocazione delle variabili che in genere per sicurezza dovrebbero essere tutte pre assegnate a livello globale e non a livello locale , perchè un'assegnazione globale occupa una posizione fissa in ram mentre invece una locale assegna la variabile temporanea in stack a meno che la si definisca static.
Tutti questi piccoli accorgimenti che garantiscono maggior affidabilità sul firmware non so' come siano gestiti a livello di Basic sui micro e onestamente i problemi nel debug del codice di solito derivini da questi piccoli accorgimenti e non tanto da una corretta sintassi del firmware .
@Danveal , come avviene l'allocazione della memoria in Basic questi paricolari sono controllabili come in C ?
Un saluto a tutti e buon lavoro
Roberto
sia @Danveal che @Ciskje hanno fatto un ottimo lavoro , partendo da approcci molto diversi e comunque altrettando validi . Sicuramente le risorse HW di un arm7 a 60 Mhz non sono paragonabili a un ATmega a 8 bit e 16-20 Mhz di clock. Tante volte pero' e Elnonino ce lo insegna gestire in modo ottimale risorse HW con un linguaggio di basso livello puo' portare a performance di tutto rispetto anche su micro con meno risorse dei fratelli maggiori.
Un esempio di facile comprensione è la differente efficienza di un hardware con sistemi operativi diversi .. per esempio io sto' usando un mac che se monta Mac OSX o Windows cambia drasticamente nelle sue performances verso l'utente finale ... per esempio all'accensione un mac ci mette 3-4 secondi windows invece se va bene sei attorno al minuto prima di poterlo impiegare normalmente.
Quindi il fattore di come si scrive il software è fondamentale per l'efficienza dell'HW. Mi fa' piacere ad esempio che i test di Ciskje confermano che qualche mhz in piu' su Multipilot rispetto ad un arduino standard portano ad un incremento interessante delle prestazioni. I compilatori Basic non hanno mai brillato per efficienza del codice prodotto è molto che non li uso e sui micro non li ho proprio mai usati , ma in ambiente pc non hanno mai creato codice troppo ottimizzato.
Per fare un confronto concreto bisognerebbe scrivere del semplice codice di benchmark sia in C++ che in Basic e vedere sulla stessa piattaforma i risultati dei test che risultati danno. In merito alla possibilità di lavorare assieme a progetti complessi sicuramente il C/C++ è il linguaggio principe.
Il basic ha un po' di limiti e non ha sui micro community così ampie come quelle di arduino .
In merito ai problemi del codice nidificato ... mhhh ... il problema non è tanto nei cicli for che comunque indubbiamente rallentano i processi computazionali , ma secondo me il problema è sulle chiamate a funzioni ricorsive , dove su di un micro avendo una profondità di stack molto bassa si rischia di andare out of stack e perdere il controllo del codice ... e da li si esce solo con un buon watchdog. Che purtroppo su di un quad potrebbe avere conseguenze catastrofiche ...
Questi piccoli accorgimenti a livello di programmazione , come tenere sott'occhio l'allocazione delle variabili che in genere per sicurezza dovrebbero essere tutte pre assegnate a livello globale e non a livello locale , perchè un'assegnazione globale occupa una posizione fissa in ram mentre invece una locale assegna la variabile temporanea in stack a meno che la si definisca static.
Tutti questi piccoli accorgimenti che garantiscono maggior affidabilità sul firmware non so' come siano gestiti a livello di Basic sui micro e onestamente i problemi nel debug del codice di solito derivini da questi piccoli accorgimenti e non tanto da una corretta sintassi del firmware .
@Danveal , come avviene l'allocazione della memoria in Basic questi paricolari sono controllabili come in C ?
Un saluto a tutti e buon lavoro
Roberto
)
Commenta