Dubbi sul 2.4GHz..

[LONGFLYER]

Originalmente inviato da elegos

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.
Gli errori di stampo continuo, detti anche sistematici, sarebbero cmq. una fortuna nella sfortuna giacchè sarebbero i più visibili e quindi migliormente risolvibili, il problema vero sono invece quelli casuali che ovviamente sono passati indenni le prove delle case produttrici.

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!).
Un piccolo appunto: senza ombra di dubbio, oggi specialmente, i frigoriferi hanno un sistemino embedded a processore ma certo il frigorifero base non ne avrebbe bisogno: basta utilizzare un termostato ...

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.
Il riavvio non è una costante proprio perchè cmq. non cercato.

E siete fortunati che il sistema si riavvii, perché se non l'avessero progettato così, semplicemente i vostri aerei cadrebbero senza possibilità di recupero.
Anche con eventuale riavvio del sistema, il problema resterebbe non risolto e nemmeno "pezzato" giacchè il tempo di riavvio, il più delle volte è troppo grande, specie nel caso che il riavvio interessi la radio.

Sorge quindi spontanea una domanda: perché hanno PROGETTATO il sistema per andare in failsafe?
Il failsafe è una modalità opzionale che da la possibilità al pilota di porre quello specifivo comando in un determinato stato qualora si perda il segnale di controllo o questo arrivi corrotto. L'uso del fs a volte è anche condizionato dal fatto che in assenza di segnale si cerchi il male minore e, quindi, si preferisca far precipitare il più lentamente possibile il modello.

Evidentemente sanno di avere qualche problema di logica del software, ma preferiscono inserire codici controllo piuttosto che debuggare (tempo?).
Affatto! Il motivo vero è che ogni buon sistema di controllo deve prevedere e quindi curare la condizione di sconnessione.

Buoni voli ... in 2.4GHz

[elegos]

Per failsafe in questo caso intendevo codice controllo che individua i blocchi. Per l'ultima frase, continuo a sostenere il fatto che sanno di alcune pecche di programmazione, dove non si sa, ed implementano lo stesso codice controllo perché far rimanere il sistema in palla piuttosto che riavviarlo, è molto meglio la seconda ipotesi. Non necessariamente prevedono un sistema failsafe (questa volta inteso in caso modellistico), poiché sarebbe (1) ammissione di colpa e (2) non richiesto dall'utente finale.

[LONGFLYER]

Originalmente inviato da elegos

Per failsafe in questo caso intendevo codice controllo che individua i blocchi. Per l'ultima frase, continuo a sostenere il fatto che sanno di alcune pecche di programmazione, dove non si sa, ed implementano lo stesso codice controllo perché far rimanere il sistema in palla piuttosto che riavviarlo, è molto meglio la seconda ipotesi. Non necessariamente prevedono un sistema failsafe (questa volta inteso in caso modellistico), poiché sarebbe (1) ammissione di colpa e (2) non richiesto dall'utente finale.

Meglio essere ancora più precisi!

Si dice failsafe l'azione opzionale che l'utente ha deciso di eseguire a fronte del presentarsi di due estremi: l'errata ricezione o la disconnessione del link 2.4Ghz, parliamo quindi di riceventi e solo di riceventi giacchè problemi di crash del software della radio sono di norma ben salvaguardati dalla casa, come testimoniano anche le statistiche in campo (a parte rarissimi casi ...).
Tornando quindi al caso ricevente, nel caso si tratti di un errore di ricezione e questo per un qualsiasi motivo duri più a lungo di un previsto tempo, già impostato dalla casa, allora il failsafe ha una sua logica di recupero, giacchè è alta la speranza che lo stato di indeterminazione duri pochi attimi, diversamente, una disconnessione totale del link 2.4Ghz è di norma un fenomeno potenzialmente più lungo ma con ancora eccellenti possibilità di speranza che duri cmq. poco.
In entrambi i casi appena esposti, il riavvio della rx non avrebbe alcun esito positivo.

L'esito di un riavvio della rx appare determinante solo nel caso che il software della rx vada in crash ed a riguardo penso proprio che nessuna casa si sia lasciato scappare l'opportunità di inserirlo già nell'hardware della rx attraverso una comune tecnica di watch-dog.

[gattodistrada]

Originalmente inviato da LONGFLYER

Meglio essere ancora più precisi!

Si dice failsafe l'azione opzionale che l'utente ha deciso di eseguire a fronte del presentarsi di due estremi: l'errata ricezione o la disconnessione del link 2.4Ghz, parliamo quindi di riceventi e solo di riceventi giacchè problemi di crash del software della radio sono di norma ben salvaguardati dalla casa, come testimoniano anche le statistiche in campo (a parte rarissimi casi ...).
Tornando quindi al caso ricevente, nel caso si tratti di un errore di ricezione e questo per un qualsiasi motivo duri più a lungo di un previsto tempo, già impostato dalla casa, allora il failsafe ha una sua logica di recupero, giacchè è alta la speranza che lo stato di indeterminazione duri pochi attimi, diversamente, una disconnessione totale del link 2.4Ghz è di norma un fenomeno potenzialmente più lungo ma con ancora eccellenti possibilità di speranza che duri cmq. poco.
In entrambi i casi appena esposti, il riavvio della rx non avrebbe alcun esito positivo.

L'esito di un riavvio della rx appare determinante solo nel caso che il software della rx vada in crash ed a riguardo penso proprio che nessuna casa si sia lasciato scappare l'opportunità di inserirlo già nell'hardware della rx attraverso una comune tecnica di watch-dog.

anche le riceventi hanno un microprocessore con un software che gira, ed elegos intendeva far capire che anche in questo software c'e un sistema failsafe o sarebbe meglio chiamarlo con il suo termine watchdog, che permette il riavvio del software nel caso qualcosa (nella programmazione o altro) non funzioni correttamente o si pianti per qualunque motivo..
mentre noi aeromodellisti per fail safe intendiamo la semplice azione che fa la ricevente quando "non riceve" il segnale...

[LONGFLYER]

Originalmente inviato da gattodistrada

anche le riceventi hanno un microprocessore con un software che gira, ed elegos intendeva far capire che anche in questo software c'e un sistema failsafe o sarebbe meglio chiamarlo con il suo termine watchdog, che permette il riavvio del software nel caso qualcosa (nella programmazione o altro) non funzioni correttamente o si pianti per qualunque motivo..
mentre noi aeromodellisti per fail safe intendiamo la semplice azione che fa la ricevente quando "non riceve" il segnale...

Scusa ma è bene chiamare le cose con il loro nome: failsafe è un termine tipico del modellismo di cui tutti conosciamo il significato, da non confondere appunto con watch-dog che è una tecnica hardware e non software che, tra l'altro, credo cmq. applicata da sempre in una rx 2.4Ghz ...

[Naraj]

Originalmente inviato da LONGFLYER

Scusa ma è bene chiamare le cose con il loro nome: failsafe è un termine tipico del modellismo di cui tutti conosciamo il significato, da non confondere appunto con watch-dog che è una tecnica hardware e non software che, tra l'altro, credo cmq. applicata da sempre in una rx 2.4Ghz ...

Non mi sembra che la funzione "Watch-dog" sia una funzione hardware.
Infatti, queste poche righe di programma, vengono inserite in un software per togliere dai guai un qualsiasi programma.

Naraj.

[gattodistrada]

Originalmente inviato da LONGFLYER

Scusa ma è bene chiamare le cose con il loro nome: failsafe è un termine tipico del modellismo di cui tutti conosciamo il significato, da non confondere appunto con watch-dog che è una tecnica hardware e non software che, tra l'altro, credo cmq. applicata da sempre in una rx 2.4Ghz ...

sulla paternità del failsafe esprimo il mio dibbio che sia totalmente o esclusivamente modellistico, ma non sapendo non replico.
invece il timer del watchdog nei moderni processori solitamente e' hardware, in quelli sprovvisti di tale funzione si puo' ovviare facendo un'apposita routine software che fa le veci del timer hardware del watchdog , con tutti i limiti del caso, comunque sia, se a livello di software non lo richiami e lo "resetti" serve a nulla... tra l'altro in fase di programmazione si puo' scegliere se utilizzarlo oppure no..
credo che sia utilizzato già da un po su tutte le moderne riceventi in megahertz (PCM-ZPC-SPCM ecc.. provviste del failsafe) e non solo nelle 2.4ghz.
quindi per me e' e resta una funzione richiamata o implementata via software.

come meglio descritto qui, anche se fa riferimento ai microprocessori pic le regole della programmazione sono le stesse.
Guida pratica al PIC 16F84 - Watch-Dog


sono piu che sicuro che le case madri abbiano programmatori esperti che non trascurano certamente questa importantissima funzione, sono piu' propenso a credere che non sappiano esattamente cosa serva al modellista, e che quindi alcune funzioni possono non essere sufficentemente funzionali (passami il termine) e/o questo puo' creare soprattutto a livello di trasmittente la difficoltà dell'utente nel progrmmare la radio, o a questi famosi bug, che a mio avviso non sono altro he semplici difficoltà o limitazioni che l'utente incontra. che poi ci sia la radio che si spegne, o che si resetti o altro beh.... chi di voi non ha mai trovato o scaricato un files corrotto... e magari scricandolo nuovamente esso funzioni perfettamente... diciamo che puo' succedere che su tot programmazioni qualche processore non riesca a scrivere correttamente una o piu locaioni nella memoria flash e che quindi quando il softw arriva a quella locazione si pianta... (o che la locazione dimemoria si guasti o sia difettosa e perda l'informazione nel tempo, come la perdita di cluster che avviene negli HD)
fatto diverso se tutte le radio avessero indistintamente lo stesso difetto, allora si puo parlare di BUG.

[romoloman]

Originalmente inviato da Naraj

Non mi sembra che la funzione "Watch-dog" sia una funzione hardware.
Infatti, queste poche righe di programma, vengono inserite in un software per togliere dai guai un qualsiasi programma.

Naraj.

Naraj il watchdog è hardware, nel senso che se a software non resetti un contatore, che viene incrementato in modo indipendente da un timer hardware della CPU, la cpu si riavvia...

[Naraj]

Originalmente inviato da romoloman

Naraj il watchdog è hardware, nel senso che se a software non resetti un contatore, che viene incrementato in modo indipendente da un timer hardware della CPU, la cpu si riavvia...

Esatto, infatti questa funzione è già programmata nel microprocessore, quindi a mio avviso, è sempre una funzione software e non è "ferramenta dura" (hardware).

Naraj.

[pidue]

Originalmente inviato da Naraj

Esatto, infatti questa funzione è già programmata nel microprocessore, quindi a mio avviso, è sempre una funzione software e non è "ferramenta dura" (hardware).

Naraj.

la funzione software serve per dire all'hardware che il programma sta girando correttamente. l'hardware si occupa di resettare il processore se per un certo periodo non viene chiamata quella funzione software.