MECCANICA e DINTORNI

Cari amici, è da troppo tempo che ho in sospeso un progetto e con l'arrivo dell'anno nuovo mi sono ripromesso di portarlo a compimento (imparare a programmare in assembler), per soddisfazione personale e perchè quest'estate mi piacerebbe poter varare il marchingegno per sperimentarlo in acque basse!!
Arrivando al dunque si tratta di un sistema a circuito chiuso per il recupero della miscela respirata durante l'immersione, più conosciuti come rebreather; l'elettronica si occupa di gestire diversi sensori di cui tre dedicati all'analisi della pressione parziale dell'ossigeno (PpO2, ovvero il prodotto della percentuale di ossigeno presente all'interno della miscela moltiplicato per la pressione in atmosfere alla quale viene respirata), uno alla profondità. Dovrebbe poter comandare un'elettrovalvola a solenoide, poter gestire due o più pulsanti e uno schermo lcd da 20x4.
Chiedo dunque un aiuto agli esperti di elettronica del forum per lo sviluppo dell'elettronica stessa e consigli in merito sulla programmazione in assembly, ovvero verso quali programmatori conviene orientarsi e quali microcontollori utilizzare.
Non mi do un limite di budget e vorrei poter realizzare un oggetto valido sotto tutti i punti di vista!!

anche perchè lo dovrai collaudare te

Se fatto in acque basse, entro i 10 metri di profondità non ci sarà alcun rischio, l'importante è fare le cose gradualmente e bene!!
Come dicevo avevo già ottenuto buoni risultati con il basic, ma purtroppo mi sono dovuto arrendere per i limiti che questo linguaggio ha e sopratutto poichè l'elettronica era quella che era... XD
Pensavo di utilizzare un pic16F84, chi ha esperienza in merito coa ne pensa? C'è di meglio e più versatile in giro? Mi piacerebbe avere a disposizione tanta tanta memoria e la possibilità di implementare senza avere problemi di limite di linee programma e entrate uscite.

Luigi, se hai giá fatto qualcosa in basic, quindi la logica di programmazione la conosci, sono sicuro che non avrai nessuna difficoltá a programmare un microcontrollore, magari dopo aver ricevuto qualche dritta.

Secondo me invece, la parte difficile sará la gestione analogica delle sonde.
Nel senso che, una volta ottenuto il segnale dalle sonde e convertito in digitale dal micro, gli algoritmi di calcolo per comandare il tuo solenoide li saprai fare sicuramente.

Rimane la gestione dei segnali sonde che dovrá essere affidabile, lineare, veritiera ecc...

Spero di averti trasmesso il mio pensiero e mi scuso se dovessi aver smorzato il tuo entusiasmo, magari a torto.

Ciao
giuliano

Ciao
Se posso esprimere un'opinione una delle soluzioni più semplici ora è Arduino, con le sue librerie in C permette una codifica molto rapida senza doversi preoccupare di fuses interrupt etc., equipaggiata con micro AVR.
Arduino mega è un po più robusta ed ha un maggior numero di bus, PWR, analog etc. dell'arduino uno, ha un atmega2560, con tutto quello che serve per comunicare etc.

Saluti

Giorgio

Ciao Giuliano!!!!! =)
Intanto grazie mille per l'intervento e i suggerimenti sempre utili e graditi!!
Ho ben valutato la cosa e sono arrivato alla conclusione che volendo sviluppare il tutto per l'estate, mi converrà darmi da fare col basic e rivedere tutto il programma in assembly più avanti con più calma e cognizione di causa!!
Ho già sviluppato il programma che però sarà bene riguardare e dividere, magari utilizzando più micro assegnando ad ogn'uno di loro un compito (leggere i sensori e gestire le informazioni), in modo da non aver problemi di bug o eccessivo carico di lavoro per un solo controllore.
Vorrei continuare ad utilizzare questi per gestire menu e acquisire le informazioni:
Micro 24pin
e uno di questi per rilevarle:
BS2E
e una Eeprom di questo tipo:
Eeprom
Ho già tutto per sviluppare e provare il programma, compresi dei moduli già assemblati:
BS2P 40pin
Appena torno a Venezia mi rimetto al lavoro, qualcuno potrebbe suggerirmi se sto assemblando qualche orrore a livello di elettronica??!

Perché non usi uno dei moduli direttamente?
Non vedo comunque ingressi analogici, ne hanno quei moduli BS2P ?

Penso comunque che con un PIC avresti tutto, anche molte routine che troveresti giá fatte in rete come la gestione del display LCD, gestione dei tasti ecc...

Ma se giá conosci lo Stamp sarebbe sufficiente che avesse degli ingressi analogici.

Non credo gestisca ingressi analogici, infatti per i sensori avevo utilizzato convertitori analogico/digitali!!
Appena ho novità comincio a postare!! ;)

In linea generale Arduino è un buon sistema anche se personalmente ne ho una conoscienza abbastanza limitata...
Più che assembler o basic io resterei più ad alto livello ed userei il C. È il linguaggio più utilizzato a questo livello e sicuramente è quello che si presta meglio a fare da "scuola".
Per quanto riguarda l'elettronica non c'è problema, conta pire su di me. Inizia col dirmi quanti e quali ingressi e uscite ti servono, magari con uno schema a blocchi e poi vediamo su che processore orientarci.

Magari è un po' troppo schematico, ma grossomodo il controller dovrebbe funzionare così!!
Dite che sia un azzardo dividere i compiti di rilevamento dati e gestione facendo "interloquire" i due micro??!
L'ho già fatto, ma dite sia sicuro e scevro da possibili crash?
Gli stamp si alimentano da 5 a 15 volt e le elettrovalvole necessitano di 6 volt per essere azionate.
Come dicevo mi piacerebbe poter utilizzare i componenti precedentemente illustrati ed evitare i moduli (li utilizzerei solo per prototipare il tutto) che richiederebbero troppo spazio e schede troppo grandi da poter essere alloggiate in contenitori pratici!

C'è una ragione specifica per utilizzare due micro? Quali sono le operazioni che il sistema deve fare ? Se la potenza di calcolo non è esagerata non vedo l'utilità di avere due micro se non quella di complicare il firmware ed inserire possibili punti di guasto: nei sistemi elettonici o più in generale in tutti i sistemi più componenti ci sono e meno diventa affidabile il sistema....

I sensori che uscita hanno e come vanno alimentati?
Immagino che siano sensori analogici ed in quel caso il front end analogico potrebbe non essere banale. Se riesci linkami o allegami il datasheet dei sensori.

Io nei limiti del possibile farei tutto con un micro solo eventualmente semplificando con ciruiteria esterna.... Le cose più sono semplici e più è difficile che si guastino...

Max l'idea di utilizzare due micro era dovuto al fatto che utilizzandone uno avevo esaurito lo spazio in eeprom destinato alla programmazione, inoltre il programma era diventato talmente grande per cui suddividere la lettura dalla gestione dei dati si era reso indispensabile!!
Il funzionamento sostanzialmente si riduce alla lettura dei tre sensori, confronto delle letture e media fra i due valori più vicini; confronto fra la PpO2 rilevata e quella di riferimento e eventuale aggiunta di ossigeno tramite elettrovalvola a solenoide. Il tutto poi si complica per il fatto che essendo i sensori delle celle a ossigeno (circa 10mv in aria), non hanno sempre la stessa uscita che diminuisce con l'andare del tempo e quindi richiedono una calibrazione ogni volta che si utilizza il sistema.
Come ti dicevo i sensori hanno un'uscita di circa 10mv in aria, che aumentano in modo lineare all'aumentare della PpO2 della miscela e non vanno alimentati essendo delle semplici celle ad ossigeno.
Se c'è la possibilità di semplificare ben venga nei limiti del possibile, ciò che non c'è non si può rompere!!!!
Ps: il sensore che utilizzo è il PSR-11-39-MD
A valle dei sensori ho utilizzato precedentemente degli Operational Amplifier LM324 e dei convertitori analogico/digitali LTC1298.

Ripeto: meglio un micro solo con più eeprom che 2 micro separati.
Per quanto riguarda la catena analogica di acquisizione non vedo l'utilità di utilizzare un ADC a 12 bit con un errore lineare di +/-2LSB max. abbinato ad un LM324 quando puoi benissimo usare on opamp un pelino più carino e utilizzare l'ADC del micro.
Esiste un datasheet degno di chiamarsi tale per questi sensori o c'è solo quello che mi hai allegato? Non si capisce se hanno un offset o cosa. La calibrazione non è un problema al limite se abbiamo poca dinamica possiamo usare un ADC sigma-delta che per queste applicazioni è la morte sua.
Ora sono in giro ma appena ho un attimo mi metto li e ti trovo qualcosa di più carino...

Max sei troppo gentile!!!
Ok per l'unico micro allora se si può utilizzare più eeprom (poi mi spiegherai come fare) e sopratutto esiste un componente apposito per effettuare la calibrazione, mi risparmio fior fior di linee di programmazione e sopratutto ho la certezza del funzionamento!!
Ogni consiglio è per me oro colato in quanto non ho alcuna esperienza in merito se non quella che ho fatto provando e riprovando!
Tu indica che io provvedo a procurarmi tutto!!
Sono riuscito a trovare solamente i seguenti Pdf:

Gigi sti sensori sono un delirio. Ho guardato il sito della Teledyne ma questi fanno prevalentemente sistemi di analisi finiti e i sensori li supportano molto marginalmente (leggi col CUxO). Io non so cosa tu sia riuscito a fare finora ma con le specifiche che mi hai inviato io non sono in grado di disegnarci attorno un front-end analogico come si deve.
Non dicono nulla !!! Io non so come diavolo si possa pretendere di mettere in vendita questi prodotti senza adeguata documentazione !!!
Dallo schema R22 che mi hai inviato vedo due pin: POSITIVE e NEGATIVE.... ma in che senso ??? Diamine son senori li dovrò alimentare in qualche modo. Non pretendo un grafico con la cirva lineare (non sia mai!!!) ma almeno uno straccio di circuito equivalente del sensore...
Ma tu, per ora, come li hai interfacciati ? Sai qual'è il loro schema equivalente ??? Non penso siano strain gauge altrimenti avrebbero almeno 4 pin e questi ne hanno solo due....