Il programma definitivo del diyer!

[Hades]

Allora... Mi sono messo un po' all'opera, e ho sfornato la prima versione ALPHA for TEST (0.1).
Feature:
- Multiprogramma: la finestra principale agisce come un desktop, e le finestre dei vari programmi di calcolo possono essere spostate, rimpicciolite, chiuse, messe in background come le finestre dei normali programmi, il tutto dentro alla finestra principale;
- Possibilita' di aprire piu' programmi e piu' maschere dello stesso programma contemporaneamente, in modo da avere sempre tutti i calcoli visibili o perlomeno reperibili;

Per ora comprende soltanto i seguenti calcoli:
- Calcolo della corrente di Bias;
- Calcolo di VOut in un partitore di tensione resistivo;
- Calcolo di R1 in un partitore di tensione resistivo;
- Calcolo della banda passante di un filtro RC (il tool e' chiamato RCH perche' prevedo di aggiungere filtri con induttanze e/o gyrator).

Ancora da implementare:
- Immagini nei pannelli dei programmi, per rendere facilmente identificabile il programma che si sta utilizzando (specie se si hanno piu' programmi aperti contemporaneamente);
- Possibilita' di stampare i calcoli;
- Possibilita' di esportare i calcoli in altri formati (xls, csv, altro);
- Tanti tanti altri calcoli utilissimi.

Se si riesce, pensavo magari di inglobare i datasheet dei componenti piu' utilizzati, e magari un programma di ricerca delle equivalenze, ma soprattutto il secondo richiede un lavoro mostruoso di ricerca, non tanto di implementazione...

Se vi piace, e vi va di darmi una mano, postate formule per i vari calcoli, e se magari ve la cavate con un linguaggio di programmazione qualsiasi (magari C, C++, C#, Javascript, VB, .Net, che sono i piu' simili al Java che sto attualmente utilizzando) postate pure gli algoritmi o le funzioni, se volete pure i metodi e le classi intere! 

Ci tengo a precisarlo, e' fatto completamente con IDE OpenSource (Eclipse 3.5) e le interfacce sono costruite con Jigloo, anch'esso plugin OpenSource di Eclipse.

Requisiti Minimi: Java SE 6 (jre1.6.0_10). Se non avete questa versione del Java, aggiorantela altrimenti le maschere rischiano di fare schifo (le versioni precedenti non hanno il Look&Feel NIMBUS).

Aspetto opinioni!!! Ciao!!!

[gnogno]

E' fighissimo!

Io più che i datasheet (che farebbero pesare il programma più del dovuto, a meno di non poter mettere una ricerca online...anche se non saprei come...) e le equivalenze (lavoro mostruoso) aggiungerei, come hai già detto tu altri calcoli!

Io mi son fatto un xlc dove ho in più la formula r-c-f con tutte le incognite, e quella per la corrente per i led...
E' interessante anche il calcolo della frequenza di taglio del filtro a T http://sim.okawa-denshi.jp/en/TwinTCRkeisan.htm, della quale non conosco la formula e potremmo metterci anche le formule che ha postato robi qualche giorno fa!

[davidefender]

ciao Hades!

ora sono all'uni, ma appena torno a casa ti dò un paio di suggerimenti  cmq, complimenti! molto bello e gradevolissimo, ora tocca solo mettere in pentola qualche buona idea per renderlo davvero INDISPENSABILE al buon diyer! 

[robi]

ottima idea.
prendi spunto da qui per integrare i file:
(password: mecojoni)

[Hades]

E' fighissimo!

Io più che i datasheet (che farebbero pesare il programma più del dovuto, a meno di non poter mettere una ricerca online...anche se non saprei come...) e le equivalenze (lavoro mostruoso) aggiungerei, come hai già detto tu altri calcoli!

Io mi son fatto un xlc dove ho in più la formula r-c-f con tutte le incognite, e quella per la corrente per i led...
E' interessante anche il calcolo della frequenza di taglio del filtro a T http://sim.okawa-denshi.jp/en/TwinTCRkeisan.htm, della quale non conosco la formula e potremmo metterci anche le formule che ha postato robi qualche giorno fa!

Paolo, devi spiegarmi esattamente di cosa tratta il link... io la teoria non la conosco molto, e questo mi complica molto il debug... Non hai idea di quanti moccoli ho tirato per far funzionare a dovere le conversioni del filtro R-C! 

@robi: interessantissimo il calcolo delle rette di carico dei triodi... Mannaggia per il programma BIAS...Ho il Mac... 

[botti1988]

per i datasheet dei transistor si potrebbe usare il pdf di nuova  elettronica con tutti i valori principali dei transistor piu' comuni, digitalizzarlo e fare un algoritmo che a partire da un dato specificato in ingresso trovi i modelli equivalenti o piu' simili (hfe ecc ecc) a quello voluto.......

che ne dici come idea?

[Hades]

botti, ottima idea, era quello a cui avevo pensato anche io.
Il punto e' che tutti i valori vanno inseriti a mano, per cui richiede un po' di tempo.

Purtroppo quello che fa perdere tempo nei programmi, come sempre, non e' tanto l'implementazione dell'algoritmo o della formula di calcolo, quanto l'inserimento dati. Oltretutto e' noiosissimo e soggetto a errori madornali, basta una virgola sbagliata o un numero digitato per sbaglio che ti sballa il calcolo e non sai mai perche' sbagli, dato che non e' un errore logico o procedurale segnalato dal compilatore.

Su dritte di Luix e robi sto elaborando un programma di calcolo per le polarizzazioni dei triodi. Sara' un pochetto complicato perche' siccome prevede parecchi dati fissi a cui appoggiarsi per il calcoli, non so che database embedded utilizzare... Probabilmente Derby, ma mi devo studiare anche l'interfaccia relativa.

[luix]

Se ti può essere utile ho recuperato il topic http://www.diyitalia.eu/forum/index.php ... 593.0.html

[botti1988]

botti, ottima idea, era quello a cui avevo pensato anche io.
Il punto e' che tutti i valori vanno inseriti a mano, per cui richiede un po' di tempo.

Purtroppo quello che fa perdere tempo nei programmi, come sempre, non e' tanto l'implementazione dell'algoritmo o della formula di calcolo, quanto l'inserimento dati. Oltretutto e' noiosissimo e soggetto a errori madornali, basta una virgola sbagliata o un numero digitato per sbaglio che ti sballa il calcolo e non sai mai perche' sbagli, dato che non e' un errore logico o procedurale segnalato dal compilatore.

Su dritte di Luix e robi sto elaborando un programma di calcolo per le polarizzazioni dei triodi. Sara' un pochetto complicato perche' siccome prevede parecchi dati fissi a cui appoggiarsi per il calcoli, non so che database embedded utilizzare... Probabilmente Derby, ma mi devo studiare anche l'interfaccia relativa.

se trovo un po' di tempo vedo se riesco a battere qualche valore. io sto iniziando adesso con il C, mi sapresti dare qualche link con una guida in cui si spiega come creare un database con C?

[mario.ferroni]

Io il database lo farei in mdb (quindi con access) almeno è facile da manutenere anche non da codice

[botti1988]

Io il database lo farei in mdb (quindi con access) almeno è facile da manutenere anche non da codice

ma qualcosa da costruire che sia compatibile con piu' piattaforme come mac windows e linux? c'è openoffice per mac? almeno facendo una cosa multipiattaforma puo' essere usato e modificato da tutti...

[Hades]

Io il database lo farei in mdb (quindi con access) almeno è facile da manutenere anche non da codice

*mdb non e' multipiattaforma e soprattutto non e' SQL compliant, per cui qualsiasi interfaccia voglia collegarsi deve usare le librerie M$. Siccome voglio utilizzare solo software Open Source, che e' anche migliore, preferisco un database embedded compatibile 100% e facile da utilizzare con Java. Per cui mi ero orientato su JavaDB e Apache Derby, SQL compliant e FOSS.

se trovo un po' di tempo vedo se riesco a battere qualche valore. io sto iniziando adesso con il C, mi sapresti dare qualche link con una guida in cui si spiega come creare un database con C?

[Teacher Mode ON]
botti1988, il C e' la cosa meno Multipiattaforma che esista, dato che lavora pesantemente sui registri, sullo stack, sull'heap e risente pesantemente dell'architettura su cui viene compilato (ad esempio pensa al problema dell'Endianess fra processori RISC (MIPS ad esempio, Little Endian) e x86 (Big Endian) o a quanto una word sia differente fra sistemi a 64bit o 32bit).
Inoltre implementare un DB da zero e' un lavoro mostruoso, ti conviene utilizzarne uno gia' fatto (MySQL, Postgresql, FirebirdSQL, ad esempio) e imparare un po' di linguaggio SQL.
Ora come ora, se non hai esigenze di scrivere driver hardware o altre cose dipendenti dal sistema operativo o Mission Critical, ti consiglio di imparare un linguaggio ad oggetti.
Lo stesso C++, che ha le stesse basi del C ma con in piu' a programmazione ad oggetti e semplificazione nella gestione della memoria (che e' mostruosa da capire ma soprattutto da gestire come si deve).
[Teacher Mode OFF]

ma qualcosa da costruire che sia compatibile con piu' piattaforme come mac windows e linux? c'è openoffice per mac? almeno facendo una cosa multipiattaforma puo' essere usato e modificato da tutti...

OO per mac esiste eccome, ed e' basato su Java!

Java E' multipiattaforma, inoltre ha una libreria sterminata per cui ci si puo' praticamente fare qualsiasi cosa...
Ad esempio questo programma lo sto sviluppando da un MacBook, provato su Windows XP/Vista/7 e funziona alla perfezione, su Linux altrettanto.

PS: non sto pubblicizzando Java, e' soltanto che per applicazioni di questo tipo e' molto piu' comodo sviluppare in questo linguaggio. Personalmente preferisco il C/C++, ma in questo caso Java ha innumerevoli vantaggi... 

[botti1988]

*mdb non e' multipiattaforma e soprattutto non e' SQL compliant, per cui qualsiasi interfaccia voglia collegarsi deve usare le librerie M$. Siccome voglio utilizzare solo software Open Source, che e' anche migliore, preferisco un database embedded compatibile 100% e facile da utilizzare con Java. Per cui mi ero orientato su JavaDB e Apache Derby, SQL compliant e FOSS.


[Teacher Mode ON]
botti1988, il C e' la cosa meno Multipiattaforma che esista, dato che lavora pesantemente sui registri, sullo stack, sull'heap e risente pesantemente dell'architettura su cui viene compilato (ad esempio pensa al problema dell'Endianess fra processori RISC (MIPS ad esempio, Little Endian) e x86 (Big Endian) o a quanto una word sia differente fra sistemi a 64bit o 32bit).
Inoltre implementare un DB da zero e' un lavoro mostruoso, ti conviene utilizzarne uno gia' fatto (MySQL, Postgresql, FirebirdSQL, ad esempio) e imparare un po' di linguaggio SQL.
Ora come ora, se non hai esigenze di scrivere driver hardware o altre cose dipendenti dal sistema operativo o Mission Critical, ti consiglio di imparare un linguaggio ad oggetti.
Lo stesso C++, che ha le stesse basi del C ma con in piu' a programmazione ad oggetti e semplificazione nella gestione della memoria (che e' mostruosa da capire ma soprattutto da gestire come si deve).
[Teacher Mode OFF]

OO per mac esiste eccome, ed e' basato su Java!

Java E' multipiattaforma, inoltre ha una libreria sterminata per cui ci si puo' praticamente fare qualsiasi cosa...
Ad esempio questo programma lo sto sviluppando da un MacBook, provato su Windows XP/Vista/7 e funziona alla perfezione, su Linux altrettanto.

PS: non sto pubblicizzando Java, e' soltanto che per applicazioni di questo tipo e' molto piu' comodo sviluppare in questo linguaggio. Personalmente preferisco il C/C++, ma in questo caso Java ha innumerevoli vantaggi... 

ho capito, semmai cerchero' di farmelo a scopo didattico, volevo usare il C semplicemente perchè lo sto facendo all università e a giugno ho l esame  quindi per studiare un altro linguaggio proprio non ho tempo. semmai se riesco a trasferire i dati in un DB MySql poi lo si userà nel linguaggio piu' utile.

bye

[meritil]

per il db valutate sqlite, per questa applicazione è d'obbligo, ci sono gli agganci per qualsiasi linguaggio scegliate...






ps: per il C che nn è multipiattaforma potrei disquisire ore del contrario diciamo che è il più scomodo

[Hades]

ps: per il C che nn è multipiattaforma potrei disquisire ore del contrario diciamo che è il più scomodo

Scusa Meritil, mi sono espresso malissimo... Il C e' il linguaggio multipiattaforma per eccellenza, dato che il 90% dei SO sono scritti in questo linguaggio...
Quello che intendevo dire e' che le applicazioni scritte in questo linguaggio sono difficilmente portabili da un sistema all'altro, soprattutto perche' spesso si usa il C quando c'e' bisogno di prestazioni e ottimizzazioni che solo un linguaggio strutturato di cosi' basso livello permette di raggiungere.
E comunque il compilatore ottimizza sempre il codice compilato per l'architettura di riferimento, per cui o scrivi un "Hello World" o devi comunque mettere mano al codice anche per le cavolate piu' insignificanti se vuoi portare un'app da un SO ad un altro.
Oggi come oggi per applicazioni semplici come quella che sto sviluppando ci sono tanti altri linguaggi validi, molto piu' semplici da gestire e portabili (vedi Java).

Sqlite e' validissimo e soprattutto leggerissimo, l'unico problema e' che necessita di una parte server che volevo evitare di fare installare utilizzando un database embedded.
Se vedo che mi incarto con Derby mi sa che passo direttamente a SQLite.

Per ora ho comunque ovviato all'esigenza di un DB, mi sono costruito varie classi per ogni tubo partendo da una classe astratta... Bella invenzione le classi astratte!!!