Radio Devention 8/8S - firmware OpenSource

[eriskio]

Originalmente inviato da system450

Provata la revisione 2.1.1, solo che non c'è il menu classico delle curve, mix, travel adjust, ecc. come nella 3 e ci sono molte meno opzioni.
C'è solo un mixer in cui non ci capisco 'na mazza. Voglio il menu solito che c'è in tutte le altre radio.
Ultima spiaggia... l'ultima nighthly revision e poi getto la spugna.

Mah, direi che nella 2.1.1 (ma anche nella 2.0 peraltro) c'è tutto: curve, mix, travel adj, e anche di piu' (il principio del software è stato sviluppato sull'esempio della Open9x e simili).
Magari può non essere immediato il suo uso ma le possibilità che offre sono infinitamente maggiori.

Detto questo io avrei intenzione di aspettare qualche mese ancora per vedere a che punto arrivano i lavori.
In autunno pensavo di fare un fork del progetto e - senza introdurre modifiche - renderlo semplicemente il piu' stabile (e sbacato) possibile.
Compilare il codice e rilasciarlo direi che "se po' fa'".

Ciao

[romoloman]

Originalmente inviato da eriskio

Mah, direi che nella 2.1.1 (ma anche nella 2.0 peraltro) c'è tutto: curve, mix, travel adj, e anche di piu' (il principio del software è stato sviluppato sull'esempio della Open9x e simili).
Magari può non essere immediato il suo uso ma le possibilità che offre sono infinitamente maggiori.

Detto questo io avrei intenzione di aspettare qualche mese ancora per vedere a che punto arrivano i lavori.
In autunno pensavo di fare un fork del progetto e - senza introdurre modifiche - renderlo semplicemente il piu' stabile (e sbacato) possibile.
Compilare il codice e rilasciarlo direi che "se po' fa'".

Ciao

Scusa perchè non sbacare l'esistente ?
I fork senza introdurre modifiche sono generalmente quanto più dannoso e dispendioso possa esistere per un progetto opensource.

Quando Bertrand ed io abbiamo fatto il fork di opentx (all'epoca open9x) era per aggiungere feature e modifiche che non erano ben accette nel progetto originale.
Se era solo per fare debugging saremmo rimasti in gruvin9x.

[system450]

Ho messo su l'ultima nights revision, ma ho dovuto comprendere il mixer advanced perché nell'altro menu non ci sono i mix.
Ci ho messo un po', ma alla fine ho capito come funziona, solo che è tutto diverso e tutto ha una dicitura differente: ad esempio l'hold è la sicurezza del throttle, ma ogni canale ce l'ha e questa è una cosa in più, ad esempio.
Programmare il modello è più complicato e lungo, però, anche se ci sono molte più possibilità. Questo è quello che penso al momento... magari abituandosi, viene tutto più semplice e immediato.
Per il momento la radio non si è più riavviata, ma mi riservo qualche voletto col cb100, che anche se impazzisce non fa danni...

[-c3po-]

mi raccomando,
testa anche qualche blade!

sei il mio tester ufficiale.



ps - Darsh, tu che release usi?
hai mai avuto riavvii o altre anomalie?

[system450]

Provati walkera cb100 col protocollo wk2401 e Blade MSR col protocollo dsm2.
L'ho tenuta accesa parecchio tra settaggi, mix, dual rate, curve varie e 4 lipo in tutto e non ho avuto alcun problema di riavvii o bloccaggi o perdite di controllo.
Sto usando la nights revision del 7 luglio 2013.
Per il momento tutto ok. Persino il bind lento senza id fixed walkera del cb100 è molto più veloce che col firmware walkera originale.
Quello dell'msr è velocissimo e funziona con l'id fixed.

Farò altre lipo coi piccolini prima di decidere se usarlo in modo definitivo o no, ma per il momento sono soddisfatto !

[eriskio]

Originalmente inviato da romoloman

Scusa perchè non sbacare l'esistente ?
I fork senza introdurre modifiche sono generalmente quanto più dannoso e dispendioso possa esistere per un progetto opensource.

Quando Bertrand ed io abbiamo fatto il fork di opentx (all'epoca open9x) era per aggiungere feature e modifiche che non erano ben accette nel progetto originale.
Se era solo per fare debugging saremmo rimasti in gruvin9x.

No, ed è il motivo per cui esistono (e mi piacciono) progetti come FreeBSD, OpenBSD e NetBSD: il primo traina lo sviluppo, gli altri "specializzano" (sicurezza e stabilità l'uno e portabilità l'altro).
La fase di stabilizzazione di un software "complesso", specie se non eseguito da integratori specialisti ma da una base piu' o meno larga di sviluppatori e utenti, deve fare tesoro delle esperienze personali.
Il trovare e risolvere un baco, dovrebbe portare alla scrittura di uno (o piu') test di non regressione anzitutto, cosa che sui progetti opensource delle radio finora non ho visto fare. questo perchè ogni singola modifica al codice anche minima potrebbe portare ad un disastro; insomma ritengo che debba esistere un sistema organico di test automatico delle funzionalità (come esiste nei progetti industriali).
Fare un fork significa freezare (bloccare) lo sviluppo ad un certo punto, stabilizzandolo il piu' possibile da un lato per offrire un prodotto finito e serio, ma lasciando contemporaneamente che chi sviluppa nuove funzionalità possa continuare liberamente a farlo.
Purtroppo la perfezione nello scrivere codice è molto di là da venire, e qualche bachetto scappa sempre anche ai piu' meticolosi, precisi e bravi programmatori.
Tu mi dirai che questo può essere fatto solo con una branch nel repository centrale: vero ma forse è meglio duplicare permettendo a ciascuno di essere libero di agire secondo la propria disponibilità di tempo/risorse e poi riallineandosi secondo esigenza che non obbligarsi ad un inseguimento continuo e senza senso.
Per inciso, se stabilizzo un pezzo un di codice, non mi posso permettere il lusso di doverlo rivedere perchè nel frattempo qualcuno mi ha fatto un merge per disegnare qualche faccina in piu' sul display...
Ovviamente questo è frutto di mia personale esperienza/abitudine ed è quindi assolutamente una visione personale.

Ciao

[romoloman]

Originalmente inviato da eriskio

No, ed è il motivo per cui esistono (e mi piacciono) progetti come FreeBSD, OpenBSD e NetBSD: il primo traina lo sviluppo, gli altri "specializzano" (sicurezza e stabilità l'uno e portabilità l'altro).
La fase di stabilizzazione di un software "complesso", specie se non eseguito da integratori specialisti ma da una base piu' o meno larga di sviluppatori e utenti, deve fare tesoro delle esperienze personali.
Il trovare e risolvere un baco, dovrebbe portare alla scrittura di uno (o piu') test di non regressione anzitutto, cosa che sui progetti opensource delle radio finora non ho visto fare. questo perchè ogni singola modifica al codice anche minima potrebbe portare ad un disastro; insomma ritengo che debba esistere un sistema organico di test automatico delle funzionalità (come esiste nei progetti industriali).
Fare un fork significa freezare (bloccare) lo sviluppo ad un certo punto, stabilizzandolo il piu' possibile da un lato per offrire un prodotto finito e serio, ma lasciando contemporaneamente che chi sviluppa nuove funzionalità possa continuare liberamente a farlo.
Purtroppo la perfezione nello scrivere codice è molto di là da venire, e qualche bachetto scappa sempre anche ai piu' meticolosi, precisi e bravi programmatori.
Tu mi dirai che questo può essere fatto solo con una branch nel repository centrale: vero ma forse è meglio duplicare permettendo a ciascuno di essere libero di agire secondo la propria disponibilità di tempo/risorse e poi riallineandosi secondo esigenza che non obbligarsi ad un inseguimento continuo e senza senso.
Per inciso, se stabilizzo un pezzo un di codice, non mi posso permettere il lusso di doverlo rivedere perchè nel frattempo qualcuno mi ha fatto un merge per disegnare qualche faccina in piu' sul display...
Ovviamente questo è frutto di mia personale esperienza/abitudine ed è quindi assolutamente una visione personale.

Ciao

Per il primo neretto guarda la quintalata di gtest code presente in opentx...
Prima di dire che nessuno ha messo regression test guarda bene il codice: se non li vedi mi sa che è un tuo problema....

Riguardo al fork sono assolutamente contrario, infatti vedo una grossa differenza fra branch e fork..
opentx-frsky è un branch stabile da noi gestito per conto di frsky. ma ci consente di lavorare ancora tutti assieme.
Proprio gli esempi che hai portato di sistemi operativi che hanno avuto parecchi fork dovrebbero farti vedere con facilità come il livello di supporto di nuovo hardware presente, a causa della dispersione di risorse umane, non sia neanche paragonabile a quello di linux che di fork del kernel non ne ha avuti, la stessa cosa l'ho vissuta fra libreoffice e openoffice

Poi ognuno fa quello che vuole...
Buon lavoro...

[eriskio]

Originalmente inviato da romoloman

Per il primo neretto guarda la quintalata di gtest code presente in opentx...
Prima di dire che nessuno ha messo regression test guarda bene il codice: se non li vedi mi sa che è un tuo problema....

Riguardo al fork sono assolutamente contrario, infatti vedo una grossa differenza fra branch e fork..
opentx-frsky è un branch stabile da noi gestito per conto di frsky. ma ci consente di lavorare ancora tutti assieme.
Proprio gli esempi che hai portato di sistemi operativi che hanno avuto parecchi fork dovrebbero farti vedere con facilità come il livello di supporto di nuovo hardware presente, a causa della dispersione di risorse umane, non sia neanche paragonabile a quello di linux che di fork del kernel non ne ha avuti, la stessa cosa l'ho vissuta fra libreoffice e openoffice

Poi ognuno fa quello che vuole...
Buon lavoro...

Primo neretto: sarà un mio problema, ma ho girato un po' il codice di OpenTX ma di Suite di Test automatici, - ma che dico Suite? test! - non ne ho visto neanche l'ombra.
Dove sono i programmi di test (ovviamente da fare girare sul buildato) per evidenziare eventuali regressioni? Quale tool è stato usato?
Fammi sapere.

Secondo neretto: Linux più che supportare "pasticcia" la funzionalità di un'infinità di periferiche.
E' per quello che - persa la voglia di smanettare - Linux lo si abbandona. Perchè?
Potrei anche spiegarlo ma non è il posto per scrivere un trattato.
Il PC è un utensile come lo sono il coltello e la forchetta: per usarli non bisogna conoscere la teoria degli acciai speciali e della tempra.

Vero che le famiglie BSD sono meno aggiornate, ma sono infinitamente piu' concrete e solide. E quando viene rilasciata una versione è quella, è una e le cose si fanno ad UN SOLO modo (non n-mila modi diversi). La sicurezza del sistema è dichiarata, consolidata e provata, non è chiaccherata (e se devi mettere su qualcosa che stia in piedi per anni facendo un servizio serio...)
Poi per carità hai ragione: ognuno fa' quello che vuole.
E non sono certo io a criticare qualcuno, per carità.
Tieni però presente che il bello (e il primo desiderata di Stallman) era proprio il fork e non il branch

Ciao

[-c3po-]

ordinata la devo10.

presto vi tartasserò di domande,
anzi...

ho dovuto prendere quella con stick del gas a sinistra,
mentre io volo in mode3...
ci sono precauzioni/accortezze da rispettare per la conversione?
tks.

[system450]

Originalmente inviato da -c3po-

ordinata la devo10.

presto vi tartasserò di domande,
anzi...

ho dovuto prendere quella con stick del gas a sinistra,
mentre io volo in mode3...
ci sono precauzioni/accortezze da rispettare per la conversione?
tks.

Mi raccomando ! Installa l'ultima nightly build che è derivata dalla 3.00, ma ne corregge i bug/riavvii.