Newsgroup: it.comp.programmare
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

 source, per non dover essere costretto a "comprare" costose licenze.
Questo conclude la questione.
Prendi una macchina solida, ci installi una distribuzione di linux 
stabile, e poi hai gia' tutti gli ambienti di sviluppo incorporati.
Scegli quello che piu' ti aggrada tra gli infiniti disponibili.
Se fornisci ulteriori specifiche sul modo di dialogare con questi 
sensori posso fornirti eventualmente altri suggerimenti.

imprescindibile.
Sebbene anch'io ritenga la coppia C++/Linux la soluzione migliore, non
è una scelta "imprescindibile". Si può sviluppare senza problemi anche
sotto Windows. 

 sotto Windows. 
Si puo' sviluppare benissimo anche sotto Windows, ma poi l'affidabilita' 
di funzionamento 24H/24H?
Dove lavoro io tutti i server windows che gestiscono la rete aziendale 
vengono regolarmente resettati ogni domenica notte per evitare che si 
impallino improvvisamente sul piu' bello.
E l'altra domenica, che c'e' stato il cambio dell'ora, li hanno tenuti 
spenti per un'ora per evitare che la retrodatazione di un'ora 
incasinasse qualcosa.
Inoltre abbiamo un processo di una consociata microsoft che utilizza un 
svchost che deve venire killato quando l'occupazione di memoria dello 
stesso supera i 200M (soluzione fornitaci ufficialmente dall'assistenza 
microsoft!!! con un batch che ogni 5 secondi monitora quel processo e se 
cresce troppo la memoria killa e restarta. Quando ho visto quella 
procedura ho vomitato!).

stesso supera i 200M 
Non capisco che c'entra questo col sistema operativo. Il problema è
delle applicazioni che girano nel contesto di quel container.

 (evidentemente scritto coi piedi), non di certo del sistema operativo.
Beh dalla mia piccola esperienza, anche io non nutro tanta fiducia
sull'affidabilità di Windows, comunque lo continuo ovviamente ad usare
su tutti i miei PC, anche se da poco, ho fatto una partizione ed ho
installato Kubuntu, chissa...
per il linguaggio che mi dite?
Che criterio devo usare per sceglierlo?
Ancora Grazie
Sal

 Che criterio devo usare per sceglierlo?
Mi pare, per quelle poche cose che ci hai raccontato, che l'aspetto piu'
critico di quello che devi fare e' il colloquio con questa periferica
esterna.
Hai detto che ci devi colloquiare tramite porta seriale.
Poi che altro devi fare?
Senza sapere ne' leggere ne' scrivere, io farei un processino unicamente
dedicato al dialogo con la porta seriale, in C, il quale a sua volta
dialoga con un programma di interfaccia, mediante pipe, ipcs, sockets,
quello che piu' ti aggrada. E l'interfaccia la puoi fare con gli strumenti
che preferisci.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 sull'affidabilità di Windows,
Boh, ho visto ormai centinaia di PC su svariate decine di 
installazione, in posti ostili tra l'altro come le fabbriche. Il 
problema dell'instabilità di windows dipende molto dalla cacca che ci 
viene installata sopra, e dai gestori dei progetti che non assumono 
programmatori all'altezza per motivi economici.
Per quanto mi riguarda non ho problemi windows su sistemi critici, e ho 
una esperienza ormai quasi ventennale.
Le differenze reali tra Linux e Windows su sistemi critici dubito siano 
note. Un conto è una cacca di PC come quello che ho casa o in ufficio*, 
e un conto un PC configurato e mantenuto da professionisti con 
l'obiettivo di farne un PC "critico".
* Per motivi economici in ditta continuiamo a compare HD di qualità 
cacca, e non abbiamo uno stabilizzatore della corrente. Poi il capo si 
meraviglia della mortalità dei PC.

 Che criterio devo usare per sceglierlo?
Quale linguaggio conosci? è adatto a fare ciò che vuoi fare? hai strumenti
di contorno (sdk, librerie, ecc...) già pronte?
I parametri sono tanti, ma bisognerebbe conoscere perfettamente ciò che
vuoi realizzare per giudicare.


 vuoi realizzare per giudicare.
Ho n sensori (non so ancora di che tipo, ma immagino che abbiano un
segnale in tensione di uscita) che si attivano in base a delle
condizioni esterne, qualora alcuni sensori vengono eccitati allora
devo far scattare un allarme sonoro (nel PC o tramite un relè), dovrei
tenere traccia degli allarmi avvenuti da qualche parte (Carta, DB,
File).
grazie e saluti
Sal

 File).
se sei su linux puoi usare la fork, N figli per N sensori ognuno in
ascolto su una seriale e buonanotte al secchio .

 allora io lo rifarei.
E mi sta bene, ma in questo caso non punti il dito sul sistema operativo.
Sei cosciente, invece, d'aver scritto codice ingestibile. E' diverso.


Dal punto di vista la realizzazione di sistemi critici sotto Windows
hai qualche documento/link da postarmi per approfondire la questione?
Non si finisce mai di imparare
grazie
Sal

 hai qualche documento/link da postarmi per approfondire la questione?
Non c'è una documentazione specifica in proposito, perché "critico" può
voler dire tante cose, lo spettro è ampissimo e si modula in base alle
esigenze del cliente. Per esempio, quale deve essere la frequenza di
lettura delle tue informazioni? Che criticità ha la memorizzazione di
queste informazioni?
Sei sicuro di non dover scrivere un sistema real-time? perché in questo
caso né Linux, né Windows, per loro stessa natura, vanno bene.ù
Ci sono molti aspetti da considerare.


 caso né Linux, né Windows, per loro stessa natura, vanno bene.
perchè no?
ai tempi ho usato con soddisfazione questo:
https://www.rtai.org/

 perchè no?
Perché né l'uno, né l'altro, è un sistema real-time, di suo. In generale,
mi fido più di un vero rtos.


 Sei cosciente, invece, d'aver scritto codice ingestibile. E' diverso.
Non voglio fomentare ulteriori polemiche, ma il caso in questione 
prevede nel suo punto critico delle chiamate a basso livello al sistema 
operativo, eseguite con un compilatore Microsoft, in base a specifiche 
Microsoft.
Non e' l'applicazione in difetto, ma quella parte di sistema operativo.
Io sono stato abituato a risolvermi i problemi da solo, andando a 
debuggare le cose anche a basso livello.
Ma quando non ti danno i sorgenti, non ti danno documentazione, e 
arrivano perfino a proibirti per legge di andare a mettere il naso in 
cose che devi usare a scatola chiusa, e che poi salta fuori che non si 
comportano come devono, e manifestano effetti collaterali, allora 
finisce che uno ci mette una bella X sopra tutto quello che e' marchiato 
Microsoft e cerca di usare ogni possibile alternativa.
Salvo quando non si viene costretti per lavoro a sviluppare in quegli 
ambienti e con quegli strumenti.
Allora ci si tappa il naso e le cose si fanno lo stesso, consapevoli che 
quando capiteranno le immancabili rogne, in prima istanza la colpa sara' 
tua, e dovrai perdere tempo a dimostrare il contrario.

Microsoft e cerca di usare ogni possibile alternativa.
Se fosse come dici tu, i problemmi tuoi ce li avrebbero tutti e cosě
non č. Prima di tapparti il naso, rifletti.

 wrote in
news:1194361398.9...@o3g2000hsb.googlegroups.com
: 

Puoi considerare diverse soluzioni, soprattutto se parliamo di un 
sistema industriale e non a livello hobbystico.
Come devi inviare l'allarme? Che esigenze ha il sistema (grafica, 
connettività di rete)?
Linux, come già suggerito e discusso, può essere un'ottima 
soluzione.
Mi permetto di suggerire anche Windows CE che è open-source 
(perlomeno per quanto riguarda il kernel), ha strumenti di sviluppo 
a costi accessibili per un'azienda (meno di mille euro, con incluso 
Visual Studio 2005) ed è, per quella che è la mia esperienza (dalla 
versione 2.12) molto affidabile.
Inoltre è molto customizzabile e questo ti consentirà di costruire 
un'immagine del S.O. molto compatta (4-8 mega senza grafica, 8-16 
con la grafica e il Compact Framework) che gira su hardware 
relativamente poco potente (x86, ma anche ARM, SuperH, MIPS, se devi 
produrre parecchi pezzi e puoi realizzare hardware custom).
Al tempo stesso ti fornisce un'interfaccia grafica completa (ma 
completamente "asportabile", se la grafica non ti serve) e molte 
delle funzioni di connettività comuni a XP e altri S.O.
Realizzare un driver su CE che gestisca un'interrupt (per la 
gestione degli allarmi) o controlli un hardware è molto semplice 
rispetto a XP e ad altri sistemi operativi.
Dal sito ms puoi scaricare o ordinare un DVD con la versione di 
valutazione che è completa e limitata a 120 gg.
Se invece non ti interessa la grafica (se non un display 
alfanumerico), non devi inviare allarmi in modo complesso (e-mail 
etc.), ma con un semplice SMS o un cicalino e non ti spaventa l'idea 
di utilizzare il saldatore e un po' di elettronica, puoi pensare a 
una soluzione basata su microcontrollore che è più economica e 
stabile di soluzioni basate su hardware e sistemi operativi 
complessi.
Per provare (o realizzare un sistema se lo devi realizzare a livello 
"hobbystico"), puoi dare un'occhiata ad arduino (
www.arduino.cc
) che 
ha costi estremamente ridotti per l'hardware e strumenti di sviluppo 
gratuiti.
Buon lavoro!
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 che preferisci.
1. se trova programmatori capaci, io mi sto sempre piů convincendo che
scrivere sw parecchio affidabile in C++ sia piů 'semplice'.
2. se non trova programmatori veramente capaci in c++, allora tanto vale
C. Per usare C++ come un 'C con classi', allora tanto vale.
3. Se deve fare solo io su seriale, in effetti anche un linguaggio quale
Python va benissimo: dopo tutto sotto chiama le stesse syscall,
semplicemente c'č un po' di gestione (memoria, allocazioni) che č
gestita dalla vm invece che dal programmatore.

 non è. Prima di tapparti il naso, rifletti.
Dipende dalle applicazioni. Per me Windows e' un ottimo sistema office
magari anche una buona piattaforma per applicazioni gestionali ... ma non
di piu', mentre Linux, essendo completamente noto, flessibile e *molto*
ritagliabile si presta ad applicazioni piu' varie, dal sistemino semplice 
senza
grafica che gira su un MPC5200 come server embedded  ad una stazione
office completa... Windows non l'ho acora visto girare su niente altro.
Vero che Microsoft propone i suoi mille altri sistemini (Windows mobile e 
CE),
ma ben lontani dall' elegenza e sicurezza di un *unico* sistema quale 
Linux...
e quindi *ogni* sistema e' diverso, con problemi diversi, presationi diverse 
etc...
brix

di piu'
Windows è un ottimo sistema anche per lo sviluppo di applicazioni
mission-critical. Bisogna conoscerlo.

 mission-critical. Bisogna conoscerlo.
ROTFL e RITOFL.
Su QNX e' possibile utilizzare sporadic scheduling per recuperare anche
da guasti hardware su linee di IRQ piantare, riconoscere il problema
e disattivare la periferica quasta o comenque continuare a funziuonare.
Con Windows no. Con buona paced del mission critical.
Con QNX posso installare a caldo o sostituire un driver al volo senza
stop macchina, con windows no.
brix

 sistema windows e' mai sopravvisuto alla prima scarica elettrostatica,
Se è per questo windows non sopravvive al crash del disco di sistema. 
Ma allora? Non è pensato per quello. Paragonare QNX a Windows è 
ridicolo, e pensare che Linux normale sia comparabile a QNX lo è 
altrettanto. Gia sul fatto che Linux RT sia comparabile a QNX avrei dei 
dubbi, ma qui sono su un campo non mio.
Ho meglio un datacenter o un cluster linux può sovravvivere al crollo 
di un nodo, ma è un'altra cosa che serve per cose diverse.
Definisci mission critical. Io scrivo software (anche) sotto windows. A 
me che una macchina vada in crash non me ne importa una pippa, tanto 
ormai il mio software è un cluster con i calcoli distribuiti tra 
svariate macchine. Il crollo di un nodo non mi preoccupa di per se. Io 
di QNX non saprei assolutamente cosa farmene. Il mio concetto di 
mission critical è diverso dal tuo, per esempio. Per me è critico 
portare a termine un batch di elaborazione.
Dalla mia esperienza non sento la necessità di passare sotto linux, 
anche se poi è sempre il cliente che decide il s.o. delle nostre cose.


Vero ;-)

 QNX comunque e' cluster-nativo su rete distribuita,
Oh bella, questa mi mancava. Però mi autoscuso. Da un poco di tempo ho 
deciso di spendere il mio tempo residuo non per documentarmi su S.O. e 
mondi di programmazione, ma su minimoto e similari. Anche il mio 
software ne ha guadagnato dalla mia nuova impostazione mentale :-)

 presationi diverse etc...
Il kernel di linux che gira su PPC o ARM è lo stesso che gira su x86 
ed ha pure le stesse prestazioni?
Ed è pure real-time?
I "sistemini" di cui parli (Windows CE, da cui deriva Mobile) vengono 
usati proprio per sistemi mission critical e real-time. Sono 
flessibili e molto ritagliabili e consentono di accedere all'hardware 
(cosa che tipicamente su un sistema embedded fa abbastanza comodo) in 
modo molto semplice.
Non so se sono "eleganti", ma sicuramente possono gestire situazioni 
come quelle descritte dal nostro amico.
Non voglio fare l'avvocato pro o contro questo o quel sistema 
operativo, ma credo che prima di parlare di qualcosa in un contesto 
tecnico sia necessario avere almeno una vaga idea di quello di cui si 
sta parlando.


   
Appunto, io non ne volevo parlare, ma visto quanto scritto.........
Fare una applicazione usando CE non *e'* semplice, se non si ha neppure una
base di embedded, farne una per Linux e' invece piu' semplice, perche' 
e' molto
piu' noto e  c'e' molto piu' supporto in giro, al contrario di CE.
Comunque ho usato WinCE5.0 e NON e' affatto semplice ne' facile fare un 
driver
hardware (che non sia una gestione banale) decente, ne' e' tanto facile 
debuggarlo,
specie se ha a che fare con timing stretti o segnali di controllo 
particolari.
Win CE6.0 non l' ho ancora usato, a parte fare un BSP preconfezionato
per una scheda x86, operazione che comunque porta via una enormita' di tempo
risptetto ad uno scopo analoghi usando QNX, ad esempio (5 minuti, 
perdendo anche tempo..)
Se PROPRIO ti necessita un hard real time, vxWorks e QNX sono 
DECISAMENTE piu'
semplici, performanti e FACILI da questo punto di vista, se POI deve 
fare un porting su HW
NON x86 , siamo decisamente fuori strada, usando i sistemi MS ci si 
mette il quadruplo del
tempo...
Poi ci sono RTEMS (free), OS/9, LynxOS, OSEK etc...............e 
vogliamo parlare
dei sistemi ITRON o uC/OS ?????????? Senza contare quelli home-made 
...............
Visto che ne ho scritto un paio e  li ho usati  piu' o meno tutti, credo 
di sapere di cosa si sta
parlando, tu invece di cosa parli ??? ;-)
comp.realtime
-------------------
Brix

 parlando, tu invece di cosa parli ??? ;-)
Di quelli che tu hai liquidato come sistemini. 
Tanto di cappello a cotanta esperienza, lungi da me l'idea di 
misurarmi con un guru dell'informatica, volevo solo precisare meglio 
cosa sono i "sistemini" di cui parlavi. 


   
Mai liquidato niente come "sistemino", specie i real time, e' una parola 
capitata li', ma
visto che sei cosi irascibile , la prossima volta passero il tutto a un 
politically-corrector, contento?
PS: I guru stanno solo in india, io semplicemente lavoro in ambienti 
real-time e *industriali*.
da quando e' un problema avere una esperienza? Invece bisognerebbe 
evitare di fare certe
affermazioni a *priori*.
Bye

 affermazioni a *priori*.
Scusa per il tono della risposta, ma la tua affermazione mi sembrava 
decisamente sommaria. Prendo atto del fatto che tu hai parecchia 
esperienza (lungi da me l'idea di fartene una colpa!), spero che tu 
capisca perchè ci tenevo a "correggere il tiro" della tua 
definizione.


   
si, grazie comunque per la correzione, capita a tutti  ;-)
Brix

 certi micro
Ok. Ho usato JTag, ma non avevo mai sentito questo acronimo.



RTAI è un VERO sistema real-time, è un linux patchato + ADEOS ed ha
prestazioni paragonabili a sistemi commerciali (QNX, vxworks etc)