Dubbi sul 2.4GHz.. - BaroneRosso.it

elegos · 23 giugno 11, 12:55

Permettetemi due parole da programmatore... fesserie del genere bug ogni 3 righe di codice ci sarebbe da spararsi a livello professionale. I bug non sono "codici scritti con qualche carattere sbagliato", lungi da quello. I bug sono per lo più dead lock (richiesta di risorse costantemente bloccate da una mal programmazione), cicli che ci mettono troppo tempo perché non ottimizzati, logica incorretta (ma qui il programmatore dovrebbe testarlo prima di mandarlo in produzione).

Ovvio poi che sulla grande distribuzione funzioni particolarmente complesse il bug possa presentarsi, subdolamente, solo sotto alcune particolari circostanze. Se invece il bug si presenta di continuo, allora vuol dire che la società ha assunto programmatori alle prime armi / sottopagati / quel che volete.

Detto questo, il programma esente da bug esiste, è fattibile, specialmente nei sistemi embedded come quelli del radiocomando / ricevente (cosa stupida: il frigorifero ha un sistema embedded, altrimenti continuerebbe a raffreddare senza posa... non credo che un giorno abbiate mai trovato ghiaccioli al posto di creme!).

Ora, il trend delle ricetrasmittenti è "avere qualche bug", allora le società lanciano sul mercato prodotti insoddisfacenti. Essendo che tutte le major house lo fanno, son tutte contente, perché possono sempre ritirare ed aggiornare senza il rischio di perdere il cliente ("lo fanno tutti!"). Qui la tecnologia dei 2.4 Ghz c'entra poco o nulla (alla fin fine FHSS, FASST e le altre tecnologie sono letteralmente stampate su circuiti "che vanno" e che probabilmente sono gli stessi per le più disparate case produttrici), qui si parla di software di alto livello progettato male (ossia le varie opzioni di miscelazione etc), il quale manda in crisi il sistema che, per evitare il blocco permanente, si riavvia. E siete fortunati che il sistema si riavvii, perché se non l'avessero progettato così, semplicemente i vostri aerei cadrebbero senza possibilità di recupero. Sorge quindi spontanea una domanda: perché hanno PROGETTATO il sistema per andare in failsafe? Evidentemente sanno di avere qualche problema di logica del software, ma preferiscono inserire codici controllo piuttosto che debuggare (tempo?).

Discussioni simili
Discussione	Autore discussione	Forum	Commenti	Ultimo Messaggio
Dubbi su rx 2,4ghz!!	dadasco	Radiocomandi	2	15 giugno 11 20:10
Optic 6 - 2,4GHz Spectra a 2,4GHz Corona DSSS	halfi	Radiocomandi	3	06 novembre 10 21:45
Con una trasmittente 2.4ghz posso usare qualsiasi ricevente 2.4ghz?	searchworlds	Radiocomandi	5	12 novembre 09 20:23
corona 2.4Ghz - Dubbi atroci...	il_Zott	Radiocomandi	0	18 maggio 09 10:50
Jeti 2.4GHz - Richiamo su Moduli DUPLEX Tx 2,4GHz (TU, TF, TG, TGi)	nigel_uno	Radiocomandi	7	16 marzo 09 08:01

23 giugno 11, 12:55	#22 (permalink) Top
elegos User Data registr.: 10-06-2011 Residenza: Milano Messaggi: 158	Permettetemi due parole da programmatore... fesserie del genere bug ogni 3 righe di codice ci sarebbe da spararsi a livello professionale. I bug non sono "codici scritti con qualche carattere sbagliato", lungi da quello. I bug sono per lo più dead lock (richiesta di risorse costantemente bloccate da una mal programmazione), cicli che ci mettono troppo tempo perché non ottimizzati, logica incorretta (ma qui il programmatore dovrebbe testarlo prima di mandarlo in produzione). Ovvio poi che sulla grande distribuzione funzioni particolarmente complesse il bug possa presentarsi, subdolamente, solo sotto alcune particolari circostanze. Se invece il bug si presenta di continuo, allora vuol dire che la società ha assunto programmatori alle prime armi / sottopagati / quel che volete. Detto questo, il programma esente da bug esiste, è fattibile, specialmente nei sistemi embedded come quelli del radiocomando / ricevente (cosa stupida: il frigorifero ha un sistema embedded, altrimenti continuerebbe a raffreddare senza posa... non credo che un giorno abbiate mai trovato ghiaccioli al posto di creme!). Ora, il trend delle ricetrasmittenti è "avere qualche bug", allora le società lanciano sul mercato prodotti insoddisfacenti. Essendo che tutte le major house lo fanno, son tutte contente, perché possono sempre ritirare ed aggiornare senza il rischio di perdere il cliente ("lo fanno tutti!"). Qui la tecnologia dei 2.4 Ghz c'entra poco o nulla (alla fin fine FHSS, FASST e le altre tecnologie sono letteralmente stampate su circuiti "che vanno" e che probabilmente sono gli stessi per le più disparate case produttrici), qui si parla di software di alto livello progettato male (ossia le varie opzioni di miscelazione etc), il quale manda in crisi il sistema che, per evitare il blocco permanente, si riavvia. E siete fortunati che il sistema si riavvii, perché se non l'avessero progettato così, semplicemente i vostri aerei cadrebbero senza possibilità di recupero. Sorge quindi spontanea una domanda: perché hanno PROGETTATO il sistema per andare in failsafe? Evidentemente sanno di avere qualche problema di logica del software, ma preferiscono inserire codici controllo piuttosto che debuggare (tempo?).