Newsgroup: it.comp.os.linux.development
Titolo: Software piccola automazione partire con il piede giusto

Gentili Utenti,
Dovrei sviluppare un programma che funzioni 24h su 24 che monitori dei
sensori e occasionalmente, faccia scattare dei relè.
Semplificando un po' la cosa, dovrei avere dei sensori di livello ed
al raggiungimento di un dato livello dovrei far scattare un'allarme.
Ho qualche esperienza di programmazione Java, ma ho avuto problemi di
affidabilità, il programma si bloccava per un utilizzo della memoria,
che non riuscivo a gestire, ed altri problemi di windows che ogni
tanto bloccava tutto.
Avendo come unico scopo l'affidabilità del programma, quale linguaggio
dovrei usare?
Pensavo ad uno scambio dei dati via porta seriale con un programma
sviluppato in C (anche sotto DOS), ma che mi dite dell'ambiente
Linux?
Per tutti ovviamente ci dovrebbe essere un ambiente di sviluppo open
source, per non dover essere costretto a "comprare" costose licenze.
Aspetto fiducioso consigli
Saluti
Sal

 
Linux è un sistema operativo, C è un linguaggio. Non confondere le cose.
Non dai molti elementi per suggerimenti appronfonditi, ma personalmente parto 
sempre con l'accoppiata python + editorditestoqualsiasi e, se le performance 
non sono sufficienti, c++. Finora, non ho mai avuto bisogno di passare al c++, 
YMMV.
-- 
SF
I was alone, I took the phone,
I needed time to think the number I saw on tv
Who did I hear! can I believe
A pack of horny lesbians howling back at me

 source, per non dover essere costretto a "comprare" costose licenze.
io programmerei in c e una versione embedded tipo uclinux, che se
ricordo bene prevede anche i386 come architettura.
ovvio che devi sapere programmare in modo affidabile.

 Non dai molti elementi per suggerimenti appronfonditi,
che tipo di informazione vorresti avere per un suggerimento più
approfondito?
Grazie
Sal

 source, per non dover essere costretto a "comprare" costose licenze.
Praticamente tutto sotto Linux e` Open Source, ma devi stare attento alle 
librerie che usi, che potrebbero avere licenze doppie (tipo le Qt, ma non 
rientra nel tuo caso, a meno che non ti serva un'interfaccia grafica).
Bye.

 [...]
Manlio Perillo

 Sal
-- 
Ciao.
Alessandro 
"Ubuntu" - an African word, meaning "Slackware is too hard for me".

 strumenti vecchi, anche perchè un 486 dove lo trovi?
http://www.soekris.com/net4501.htm
 :)
Enrico

 dovrei usare?
C, Pascal, forse D. Python in questo caso lo eviterei in quanto, da
 quello che so, l'interprete in alcuni casi e` soggetto a crash (qualche
tempo fa passo` un thread sull'argomento su it.comp.lang.python, ma
sinceramente non ricordo ne a quale versione si riferiva, ne se i
problemi riscontrati erano applicabili alle ultime versioni)
Enrico


wrote:

Henryx, anche F :-).
Consigliare un linguaggio senza valutare i benefici che il suo
ambiente di sviluppo ti offre per il
singolo caso, lo trovo azzardato.
Direi che a te serve un elf, non userei linguaggi interpretati se mi
servissero prestazioni
elevate in termini di velocità di esecuzione, ma sicuramente non sarà
il tuo caso.
Il C va benissimo,linux ti offre una bella libreria (parapin) per
l'utilizzo della parallela, e
trovi tonnellate di codice googlando un pò.
Salut.
root@aspinall-laptop:/home/aspinall# time python py.py
prova
real    0m0.069s
user    0m0.008s
sys     0m0.008s
root@aspinall-laptop:/home/aspinall# time perl p.perl
prova
real    0m0.009s
user    0m0.008s
sys     0m0.004s
root@aspinall-laptop:/home/aspinall# time ./c.out
prova
real    0m0.001s
user    0m0.000s
sys     0m0.000s

 
deve avere qualche interazione con l'utente? se sì, console o GUI? Gli allarmi 
di cui parli, cosa sono? segnalazioni a video o devi comunicare con qualche 
altro sistema? e poi tu, a programmazione, come stai messo? e il programma, è 
per uso personale oppure professionale?
cose così insomma :-)


 per uso personale oppure professionale?
L'utente non dovrebbe interagire con l'applicazione, potrebbe magari
spegnere l'allarme in caso di falsi allarmi (l'allarme potrebbe essere
sia interno al PC con un suono emesso dalle casse, ma anche una sirena
tradizionale comandata da un relè)
L'interfaccia grafica dovrebbe essere ridotta all'osso, mostrando solo
lo stato dei sensori (anche 1/0), ma volendo si potrebbe fare una cosa
più carina, magari simulando il riempimento di una barra per indicare
lo stato del livello della vasca.
per la programmazione, non sono certo un professionista navigato, ma
ho sviluppato un sistema java che prende dei dati dalla porta seriale
e dopo averli elaborati li mette in un DB Mysql, ma ho avuto i
problemi di affidabilità che vi dicevo, risolti in maniera brutale con
un riavvio giornaliero del PC, ma ogni tanto Windows si blocca lo
stesso.
Il programma è per uso professionale ma sarà sviluppato su misura, non
credo che a breve riuscirò a trovare altre commesse di questo tipo.
Per la velocità dell'esecuzione non ci sono problemi, i tempi di
risposta del sistema sensori-allarme potrebbe essere anche moooooolto
lungo, considerando che il livello della vasca che dovrei monitorare
dovrebbe variare soprattutto con la
pioggia.
Saluti
Sal

 
con gli ultimi due punti mi sentirei di escludere c/c++: se la velocità di 
esecuzione non è un problema, molto meglio poter sviluppare con un linguaggio 
rapido e avere un feedback altrettanto rapido. Cosa intendo per feedback? il 
sistema che stai sviluppando mi sembra facilmente simulabile, quindi con 
moduli per le verifica del codice come unittest (incluso già in python) puoi 
procedere nello sviluppo molto speditamente avendo anche la quasi certezza che 
il tuo codice funzionerà.
Se poi avessi bisogno di una GUI, non avresti problemi (qt, tck, etc.)


Ciao Sal,
mi occupo di sviluppo di sistemi di suprevisione e controllo
da diversi anni .... senza scrivere un papiro ti dico che
un sistema che tu vuoi realizzare deve avere delle caratteristiche
specifiche (intrinseche dei sistemi di suprevisione ... ) quindi
se vuoi il pieno controllo e la piena affidabilità ti consiglio
di scrivere il core in c o c++ poi magari puoi scrivere un modulo a
parte che si interfaccia con questo driver (passatemi il termine ....)
che si occupa della GUI e li puoi sbizzarrirti. Per il SO linux va
benissimo, dico anche però che win non dovrebbe dar problemi se le cose
sono scritte bene; Ho scritto un paio di cose x win (2000) che girano
da tempo senza problemi.
Se poi hai problemi specifici posta che ne parliamo.
Saluti.
Sal ha scritto:


 singolo caso, lo trovo azzardato.
Beh, direi che e` quello che ho fatto, altrimenti avrei nominato anche
Java e C# :)
Da cio` che dice l'OP, gli unici due requisiti che influenzano la scelta
del lingauggio sono l'affidabilita` (e quindi un linguaggio interpretato
e` piu` o meno escluso, in quanto potresti incappare in errori della
VM) e l'accesso a basso livello. In questo caso, un qualsiasi linguaggio
compilato e` ottimo, tutto sta a trovare quello che piu` si adatta alle
proprie esigenze (personalmente tra i tre che ho citato sceglierei
Pascal). Poi, ovviamente, molto dipende anche dalle imposizioni che ti
vengono date, ma questo e` un altro discorso
Enrico

 stesso.
Senza offesa, ma questo mi sa di programmazione ad minchiam.
Personalmente ho sviluppato un sistema piu` o meno simile in Java (un
raccoglitore di dati che li prende e li spara ai client degli
operatori), ed e` in produzione da mesi senza problemi di sorta (fino
ad ora ho dovuto rilasciare una sola patch)
Enrico

 
pensa che da quello che dice l'OP, io sono giunto a conclusioni opposte alle 
tue :)



Scusa in che senso?
Saluti
Sal

Sal wrote:

nel senso che lui, Enrico, ti suggerisce un linguaggio compilato, io uno 
interpretato.


 tue :)
Come si dice, punti di vista :)
Enrico