Go Down

Topic: Fishino UNO.. interessante (Read 85520 times) previous topic - next topic

testato

Ignoro completamente come sia fatto il tuo driver, e non potrebbe essere altrimenti visto che lo ignori anche tu.
Se poi usare una serie di metodi che si basano su una API closed source tu lo chiami "scrivere un driver" allora buona scrittura.
 :)

- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

mdelfede

Ah, punto di vista interessante.
Ho l'impressione che di dia più fastidio non poter utilizzare / studiare il mio software sui tuoi eventuali progetti che il fatto puro e semplice che sia closed source, visto che mi par di capire (e non solo dai tuoi commenti qui) che l'ESP, nonostante sia fornito di un software E di un SDK closed source su almeno 2 livelli (il produttore del SOC, che NON è expressif, il quale ha integrato una ROM closed ed expressif col suo sdk), tu l'abbia provato eccome ;-)

In quanto al tuo commento sagace sullo "scrivere un driver", credo tu non abbia la minima idea di quanti drivers che circolano, open source e non, siano scritti facendo un parziale reverse-engineering di hardware e software closed.
Io una vaga idea ce l'ho, visto che qualche driver per il kernel Linux, nonchè qualche fetta discreta di Wine li ho anche scritti. Sarei curioso di vedere il TUO, di contributo alla comunità opensource. Stupiscimi ;-)

Detto questo, il discorso mi ha sinceramente stufato.
Ho cercato di fare un progetto carino basato sulla piattaforma Arduino, con hardware totalmente open e software idem, salvo il firmware del wifi che comunque non impedisce l'uso della scheda con il suo firm originale.
Le librerie di Arduino sono totalmente aperte e, a mio avviso, rappresentano, oltre che il 70% di tutto il lavoro svolto,  un discreto miglioramento rispetto a quelle originali, soprattutto per quanto riguarda la bufferizzazione ed il relativo notevole incremento di prestazioni.
Non ti garba ? Non comperarlo. Cercherò di dormire lo stesso la notte ;-)


gpb01

#62
Sep 14, 2015, 10:21 am Last Edit: Sep 14, 2015, 10:21 am by gpb01
@mdelfede : ... lascia stare, non te la prendere, quello è "Testato" ed è fatto così, ormai noi qui abbiamo imparato a conoscerlo (... e anche ad apprezzarlo)   :smiley-mr-green: :smiley-mr-green: :smiley-mr-green:

Guglielmo
Search is Your friend ... or I am Your enemy !

mdelfede


zoomx

Ignoro completamente come sia fatto il tuo driver, e non potrebbe essere altrimenti visto che lo ignori anche tu.
Se poi usare una serie di metodi che si basano su una API closed source tu lo chiami "scrivere un driver" allora buona scrittura.
 :)
Anche il Raspberry PI ha una parte nascosta, non è tutto open source. Così come l'ESP.

gpb01

@mdelfede: Leggo che sulla Fishino Uno hai usato, come convertitore USB - Seriale, il chip CH340G ...
... come la mettiamo con OS X ?

Hai un driver aggiornato che NON richieda di disabilitare il controllo delle estensioni con "sudo nvram boot-args="kext-dev-mode=1" ?

Considera che è da un po' di tempo Apple rilascia il certificato per "firmare" i driver anche agli sviluppatori quindi la scusa che "... non si possono firmare i driver perché Apple non lo consente" NON regge più :smiley-evil:  e che solo un pazzo, di questi giorni, disabiliterebbe il controllo di sicurezza sulla firma dei driver che vengono installati al momento del boot.

Purtroppo, l'unico driver che trovo per OS X, è quello cinese datato 2013-12-25 ... data sicuramente anteriore a quella dei problemi di firma dei kext (cosa introdotta con Yosemite) ...

Ora ... o tu hai un driver per OS X aggiornato e dici dove scaricarlo o ... per risparmiare pochi US$ hai fatto una pessima scelta scegliendo il CH340G e tagliando fuori buona parte degli utenti OS X (... che, salvo non siano degli incoscienti, specie di questi tempi, non disabiliteranno il controllo di autenticazione delle estensioni:smiley-eek:

Guglielmo

P.S. Ti faccio notare che "Cindori", che per prima aveva sollevato il problema con il suo ktext per il "trim", comunica ufficialmente sulla sua PAGINA che il suo nuovo driver è firmato con il certificato fornito da Apple
Search is Your friend ... or I am Your enemy !

mdelfede

#66
Sep 14, 2015, 02:09 pm Last Edit: Sep 14, 2015, 02:11 pm by mdelfede
Ah, non preoccuparti.... arriverà anche quello firmato per Mac, così com'è arrivato quello per windows.
Sempre che qualcuno non porti quello per Linux, incluso nel kernel, su Mac, cosa che potrei fare benissimo avendo un po' di tempo che purtroppo adesso non ho. Alla fine il mac osx non è altro che un BSD rimarchiato e reso proprietario, alla faccia di opensource &c.

Cmq, meglio un driver non firmato che utilizzare un chip il cui produttore ha rilasciato un firmware (firmato) che vaporizza i cloni del medesimo ad insaputa degli ignari clienti.... e qui ogni riferimento a fatti e cose realmente accaduti è puramente voluto ;)

http://blog.erratasec.com/2014/10/the-deal-with-ftdi-driver-scandal.html#.Vfa4a7NdRQs

O forse pensi che un cliente finale sia in grado di distinguere un FTDI originale da un clone, prima di vederselo vaporizzato da un driver "firmato" ? ;)
 

gpb01

#67
Sep 14, 2015, 02:15 pm Last Edit: Sep 14, 2015, 02:15 pm by gpb01
O forse pensi che un cliente finale sia in grado di distinguere un FTDI originale da un clone, prima di vederselo vaporizzato da un driver "firmato" ? ;)
... conosco perfettamente la situazione e ... pur se non nel metodo, perdona ma sono d'accordo con FTDI e che il cliente se la prenda con il produttore della scheda che usa dei chip COPIATI violando il copyright !

 ... o la violazione del copyright degli altri si può fare e quella del tuo firmware invece no ? ? ?  :smiley-twist: :smiley-twist: :smiley-twist:

Guglielmo
Search is Your friend ... or I am Your enemy !

gpb01

#68
Sep 14, 2015, 02:19 pm Last Edit: Sep 14, 2015, 02:21 pm by gpb01
E' ormai oltre un anno che c'è Yosemite e NON mi sembra che il produttore cinese si sia sbattuto per fare dei driver aggiornati e firmati, e, se permetti né io né gli altri (... con un minimo di testa sulle spalle) installeranno driver non firmati.

In particolare, quello del CH340G, usando il trucco della disabilitazione ... è noto per provocare il crash del sistema (una volta si e l'altra pure :D) come anche verificabile sul sito di supporto Apple.

Quindi, ribadisco ... non mi sembra sia stata una grande scelta ... ::)

Guglielmo

P.S. : ... e nota che mi dispiace, perché invece trovo molto interessante la scheda ... :(
Search is Your friend ... or I am Your enemy !

mdelfede

Assolutamente, puoi anche fare con il mio firmware, basta che ti sbatti un po' :smiley-mr-green:

Cmq, sono d'accordissimo con te nel condannare i produttori di chip cloni dell' FTDI, ma NON con la politica della medesima di vaporizzare quelli posseduti a loro insaputa dai clienti finali che di cloni & c possono benissimo non sapere un tubo, e soprattutto NON sono tenuti a saperlo.
Se avesse fatto un driver che mostrava una bella pernacchia e diceva "chip clonato, rivolgiti al produttore per i drivers", pur se anche qui il povero acquirente finale avrebbe dovuto sudare, sarei anche stato d'accordo.
Ma vaporizzare un chip NO.

Tra parentesi, tu parli di un "piccolo risparmio", ma sai benissimo che con i prezzi che girano attualmente 2 euro di risparmio sul prezzo d'acquisto si traducono in 4-5 sul prezzo di vendita che su queste schede è un abisso.
Ed il CHG funzia perfettamente, spesso anche meglio dell' FTDI.

gpb01

#70
Sep 14, 2015, 02:26 pm Last Edit: Sep 14, 2015, 02:26 pm by gpb01
Cmq, sono d'accordissimo con te nel condannare i produttori di chip cloni dell' FTDI, ma NON con la politica della medesima di vaporizzare quelli posseduti a loro insaputa dai clienti finali che di cloni & c possono benissimo non sapere un tubo, e soprattutto NON sono tenuti a saperlo.
Per primo ho scritto che non ero d'accordo sul metodo, bastava che il driver si rifiutasse di installarsi e la cosa sarebbe stata più pulita ;)

Comunque mi risulta che cancellano solo il Vid (o il Pid) USB mettendoci #00 e solo sotto Win ... senza fare alcun danno al chip che, su altre piattaforme, può essere ripristinato ed utilizzato  :P

Guglielmo
Search is Your friend ... or I am Your enemy !

testato

#71
Sep 14, 2015, 02:28 pm Last Edit: Sep 14, 2015, 02:33 pm by Testato
Sarei curioso di vedere il TUO, di contributo alla comunità opensource. Stupiscimi ;-)
Sono un idealista, troverai battaglie mie, non progetti  :)

Come avrai visto sul Megatopic nel primo post denuncio il fatto che l'ESP sia closed, e tante volte nelle pagine l'ho sottolineato. Questo non vuol dire che poi non si debba studiare un nuovo tipo di chip, sono due piani diversi. Anche su linux c'e' chi installa i driver proprietari Nvidia, e chi non lo fa. Non e' illegale che tu abbia chiuso il tuo codice, ma e' normale che da questa parte, su una community che nasce sul concetto di quanto e' giusto in assoluto che il sw e l'hw sia open, questo tipo di scelte trovino oppositori.

Secondo te il team Arduino potrebbe mai scegliere di fare una Arduino ufficiale con ESP ? No di certo, anche se tutto cio' che il team stesso scrivesse sarebbe open, figurati pensare di aggiungere al problema un ulteriore livello di chiusura.
Sembra il gioco che fa il governo, preso atto che il problema sono le tasse, si fa una riforma per risolvere il problema aggiungendo una nuova tassa  :)

Mi dai info sulla questione del produttore ? Ho sempre saputo che il produttore del SOC fosse Espressif, il quale ha messo assieme una MCU Tensilica ed una sezione RF che mantiene closed.

Comunque, benvenuto sul forum Arduino  :)

- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

zoomx

Testato,
a me sembra che l'Arduino sia l'unica piattaforma tutta open source ma... le Intel Edison sono open source?
La parte radio di un sacco di apparati, ad esempio la quasi totalità (forse tutti, non so) degli smartphone che usano Android, è closed source. 
Anche io sono per avere tutto open source per cui, ad esempio, Broadcom mi sta un po' antipatica visto che per alcuni chip non trovi neanche i datasheet, figurati i sorgenti. Sull'ESP non abbiamo, e penso non avremo, i sorgenti della parte radio che è una cosa comune a molti altri progetti. Credo che Atheros, usato sulla YUN, abbia dei sorgenti pubblici ma non ne sono sicuro.
Finiremo però per fare polemica.

mdelfede

@gbp01, non ho mai approfondito l'entità del "danno" sui chips FTDI... non è che mi interessasse più di tanto ;)
Ho solo letto di gente incaxxata nera per quella storia e me ne sono tenuto bene alla larga.
Cmq, pur non avendo mai scritto drivers per l'OSX, non è detto che tra un po' non mi ci provi, se nel frattempo non salta fuori qualcosa dal produttore. Questo sempre che la "certificazione" della Apple sia gratuita. Anche costasse solo 50 centesimi, per principio mi rifiuto di pagare una casa produttrice (che tra l'altro, in questo caso, ha sfruttato fino all'osso la comunità senza nemmeno ringraziare) per poter utilizzare un MIO software su una macchina che ho pagato con i MIEI soldini :D
Ho un io programma commerciale (windows e linux) che mi viene segnalato da Avira, ci ho litigato fino alla nausea, ed ho risolto attaccandogli in coda una marea di "spazzatura". Ovviamente non contiene virus, ma la loro soluzione è "vai alla microsoft e fatti dare il certificato per firmare l'eseguibile". E sti caxxi, se permetti ;)

@Testato : intanto grazie x il benvenuto ;)
Seppelliamo le armi, preferisco parlare di cose tecniche, sono più gratificanti.... e te lo dico da ingegnere edile, perennemente immerso nelle scartoffie.

Sull'ESP, da quel che so io (ma magari mi sbaglio, eh...) han preso un core Tensilica personalizzato, ed ho letto che il codice in ROM non è farina del loro sacco. La sezione RF invece è loro, come dici tu, e tutto il codice dell' SDK. Quasi tutto chiuso e assai poco documentato, anche se stanno migliorando rapidamente.

La mia decisione di mantenere chiuso il firmware non è stata indolore, ma è l'unico modo che ho per evitare, appunto, che nascano decine di cloni prima che io riesca a lanciare la linea del prodotto e a recuperare 2 lire per il tempo investito che, te lo posso garantire, non è stato poco. E continua a non essere poco.
Non è detto che prima o poi non lo apra, se le vendite vanno bene. Anzi, è più che probabile.

Questo non risolve comunque il tuo problema di "principio", vista la base di partenza.
Detto questo, non ci vedo nulla di male ad utilizzare una parte di software/hardware non open source, SE la cosa è ben documentata e SE l'assistenza è efficace e fonte di continui aggiornamenti.

Capisco anche che nell' ESP la parte da leone la fa il software, altrimenti chiunque potrebbe prendere una cpu a 32 bit prestante (vedi PIC32MZ per esempio...), appiccicargli una parte RF ed ottenere risultati anche migliori.
Quelli di Espressif hanno fatto un gran lavoro portando sul mercato un aggeggio estremamente interessante e ad un prezzo ridicolo, e capisco che vogliano tutelare il loro investimento. O così o avremmo continuato a pagare 4-5 volte tanto i moduli wireless.

Lo stesso vale per me. L'idea mi è nata da una necessità personale, per risolvere la quale ho provato i primi modulini ESP (ESP01) e ne ho constatato la quasi totale inutilità in modalità AT.
Mi son messo a cercare info (una rogna infinita...) per farlo lavorare in modalità SPI slave, ho modificato i 2 ESP01 che avevo (non hanno i pins per l' SPI e per giunta ne hanno uno connesso internamente a massa), ho fatto un po' di prove, visto che l'idea funzionava ed ho deciso di provare a realizzarci un prodotto commerciale.
E anche qui ti garantisco che una cosa è farsi una schedina in casa, magari con 4 "patch" sopra, un'altra è farne una commerciale, trovare produttori, venditori, ecc ecc. Son cose che hanno un costo e che deve essere recuperato e dare un po' di utile.
Pensa che qualcuno mi aveva suggerito di lasciare anche l'hardware chiuso.... ma quello non mi andava.
Il fishino è comunque utilizzabile in modalità AT, basta unire le due seriali. Ovviamente in quel caso le problematiche originali ci sono tutte, ma se non altro hai una schedina compatta e con SD e RTC sopra.

zoomx

I nuovi drivers FTDI non hanno più il comportamento aggressivo ma sembra si rifiutano di funzionare mandando un messaggio sulla console. Credo che il messaggio sia proprio quello che segnala questo utente
https://forum.arduino.cc/index.php?topic=265682.msg2394760#msg2394760
I driver della Prolific invece non partono proprio e danno l'infausto errore 10 come spiegano nel sito Prolific.

mdelfede,
anche gli autori del RaspberryPI hanno fatto la stessa cosa per motivi identici. Son passati circa 2 anni prima che rendessero pubblici i driver video, ma credo non i sorgenti.
Ne comprendo le ragioni.

Go Up