next topic »

[Reply #90 on:]

Ah, già, naturalmente era necessario inserire un delay alla fine di loop()

Quindi se ho ben capito senza modificare il pinmode ci sono delle accensioni "spurie" nel passaggio da un led all'altro ?

Per quanto riguarda la libreria, il codice della matrice è già scritto in quell'ottica 

[Reply #91 on:]

In allegato lo sketch modificato in modo che utilizzi il pinMode come faceva la tua funzione verirow().
Compilato, non provato...

[Reply #92 on:]

...e infine ecco il codice convertito in una classe (in allegato).

Ho un dubbio: nella funzione allOff() tutti i pin vengono messi in modalità INPUT. E' necessario anche scrivere un valore LOW ? (purtroppo non ho una matrice di led come la tua sotto mano. Spero di avere il tempo di costruirne una, magari anche solo 2x2...    )


Per quanto riguarda come scrivere una libreria per Arduino:

http://www.arduino.cc/playground/Code/Library

http://arduino.cc/en/Hacking/LibraryTutorial

E' necessario (IMVHO) conoscere almeno le basi della programmazione ad oggetti.

[Reply #93 on:]

  Fantastico !!
Ora si che funziona !!!!

Accensione del primo gruppo di led, poi del secondo e a ciclo continuo, un led alla volta per tutti e 32.

Bene provvedo all'upgrade del codice base R05G e lo posto sul FABLAB, così dovrei snellire non di poco lo sketch.

Per la libreria, credo mi tocchi aspettare ancora un pò per capire il meccanismo.

Grazie.
Ciao.

[Reply #94 on:]

[Reply #95 on:]

 
Un saluto a tutta la comunità.

Ho postato sul sito del FABLABTorino (http://www.fablabtorino.org/portfolios/arduomemoryreminder/) la nuova versione R05G con gli aggiornamenti legati alla selezione della lingua in eprom, completamento descrizione delle funzioni ed inserimento della matrice per la gestione dei led, consigliata da tuxduino (con piccoli ritocchi per il codice) che permette allo sketch di snellirsi guadagnando circa 3K in compilazione.

PS.: C'è qualcuno che ha provato a realizzare il progetto?

Ciao.

[Reply #96 on:]

Ciao, osservando l'integrazione di writeCell() mi ha colpito l'uso misto che fai delle variabili globali e degli argomenti di funzione.

Cerco di spiegarmi meglio con un esempio "stupido".
Supponiamo di avere una funzione somma() che appunto ritorna il risultato della somma di due interi:

Code:

int somma(int a, int b) {
    return a + b;
}

Questa funzione è in un certo senso "autocontenuta", cioè
1) se ne può spiegare il funzionamento senza far riferimento ad altro codice
2) può essere utilizzata così com'è in qualunque sketch senza alcuna modifica.

Ora immaginiamo di usare questa funzione in un programma complesso, in cui ad esempio abbiamo due variabili livello1 e livello2, e una terza variabile livelloTotale che rappresenta la somma dei due livelli. Potremmo integrare la funzione somma in questo modo:

Code:

int livello1;
int livello2;
int livelloTotale;

void sommaLivelli() {
    livelloTotale = livello1 + livello2;
}

Utilizzo:

Code:

// leggi livelli attuali
livello1 = readLevelSensor(...);
livello2 = readLevelSensor(...);
// calcola nuovo livello totale
sommaLivelli();
// visualizza il nuovo livello totale
lcd.print(livelloTotale);

Nota che la funzione sommaLivelli(), a differenza di somma(), non è generale. Per comprenderla è necessario fare riferimento a variabili definite al di fuori di essa. Inoltre non è possibile copiarla così com'è in altri programmi, a meno di non introdurre anche in essi le varaibili livelloTotale, livello1 e livello2, che probabilmente non avrebbero senso al di fuori del loro contesto originale.

Il modo corretto di utilizzare somma() è invece:

Code:

// leggi livelli attuali
livello1 = readLevelSensor(...);
livello2 = readLevelSensor(...);
// calcola nuovo livello totale
livelloTotale = somma(livello1, livello2);
// visualizza il nuovo livello totale
lcd.print(livelloTotale);

Quindi la morale è:
- non utilizzare variabili globali per passare argomenti ad una funzione né per ritornare il valore calcolato al programma principale
- le funzioni debbono essere il più possibile indipendenti dal programma in cui sono inserite
(naturalmente si tratta di princìpi guida che vanno poi interpretati caso per caso...)


Per concludere, tornando all'integrazione di writeCell(), nella prospettiva di utilizzare box medicine con diverso numero di righe e colonne è meglio lasciare la writeCell() così come l'ho scritta io, e invece di "fonderla" con verirow(), _utilizzarla_ all'interno di verirow() in questo modo:

verirow()  {
    calcola il numero della cella e il numero del paziente in base al numero di medicina
    writeCell(numero cella, numero paziente)
}

Così la writeCell() rimane legata soltanto al modo in cui la matrice di led è costruita e collegata all'arduino, mentre la verirow() è legata ai dati e alle convenzioni del programma (ad esempio il fatto che le medicine sono numerate da 1 a 33, le 1-16 son di un paziente e le 17-33 di un altro), e interfaccia i due "mondi" convertendo il numero di medicina selezionato in valori "digeribili" dalla writeCell(), cioè a partire dal numero di medicina calcola il numero della cella e quale dei due led accendere.

[Reply #97 on:]

 
Untarrabbià!!!! tuxduino!!!!

Ripristinata in originale la matrice WriteCell con gli aggiustamenti del caso su verirow.

Ieri ho fatto le cose un pò di fretta ! Sorry  

void verirow() {
  // select patient 1 or 2 and adj number of medicine
  if(med[0] >16){cnt=med[0]-17; value=0;} else {cnt=med[0]-1; value=1;}
  writeCell(cnt,value);
}


// function by tuxduino
// cellNumber: 0..ROW*COLS
// value: HIGH or LOW
void writeCell(byte cellNum, byte value) {
    byte row;
    byte col;
    
    row = cellNum / NUM_COLS;
    col = cellNum % NUM_COLS;
    
    allOff();

    pinMode(colPins[col], OUTPUT);
    digitalWrite(colPins[col], value);

    pinMode(rowPins[row], OUTPUT);
    digitalWrite(rowPins[row], !value);
}

PS.: Verificata con l'hardware ed aggiornata con la versione R05G1  

[Reply #98 on:]

eheh, vedi com'è tutto più elegante ?

Cmq il problema è che certe volte mi prende il raptus del maestrino... scusasse dotto' 

PS: update: ho raggruppato la parte dei comandi seriali in un'altra libreria, così da togliere un po' di "roba" dal mio primo sketch; ho raccattato un po' di led per fare una matrice almeno 2x2 e ho collegato l'altoparlante su una breadboard. Appena ho capito bene il discorso lampeggio / avviso sonoro lo inserisco nel codice che gira quando è instato di allarme...

Anzi, ne approfitto per farti una domanda: il tono di avviso cambia in base al paziente, alla medicina, ad una combinazione di entrambi ? Grazie!

[Reply #99 on:]

 
L' idea era quella! Al momento esiste un solo tono che non è neanche dei più belli, ma sicuramente fastidioso.
Si potrebbero inserire n. tonalità da selezionare in configurazione a secondo del paziente.
Esempio: Tono paziente 1 (da 0 a 9)

Che ne pensi?

Ciao.

[Reply #100 on:]

L' idea era quella! Al momento esiste un solo tono che non è neanche dei più belli, ma sicuramente fastidioso.
Si potrebbero inserire n. tonalità da selezionare in configurazione a secondo del paziente.
Esempio: Tono paziente 1 (da 0 a 9)

Che ne pensi?

Ciao.

Mi piace.

"Lampeggio" tipo sirena ? Cioè, 500ms di silenzio, 500ms del tono selezionato (l'esatta durata sarà da valutare tramite prove empiriche).

Ho provato il circuito dell'altoparlante. Modificando il valore del condensatore si ottiene un sono più o meno "duro"...

[Reply #101 on:]

L' idea era quella! Al momento esiste un solo tono che non è neanche dei più belli, ma sicuramente fastidioso.
Si potrebbero inserire n. tonalità da selezionare in configurazione a secondo del paziente.
Esempio: Tono paziente 1 (da 0 a 9)

Che ne pensi?

Ciao.

Siccome state facendo un oggetto per persone non del tutto autosufficienti, spesso (ma non sempre, certamente) la non autosufficienza fa rima con anzianità.
Ed una persona anziana ha un udito diverso da un giovane, con un timpano più sordo a determinate frequenze (generalmente quelle alte). Fare 9 toni non ha molto senso, secondo me, perché c'è il rischio che: qualcuno non senta il "suo" tono; in diversi confondano il tono di un altro con il proprio; ecc...

[Reply #102 on:]

 
Giusta osservazione Leo72!
Però le 9 segnalazioni sonore potrebbero essere 9 diversi segnali con frequenze specifiche, indicate proprio per quelle persone con problemi di udito, quindi selezionabili per verificarne l'efficenza paziente per paziente.

Qualcuno sà consigliarmi quali potrebbero essere esattamente, cosi da creare 9 diverse tonalità efficaci?

[Reply #103 on:]

Giusta osservazione Leo72!
Però le 9 segnalazioni sonore potrebbero essere 9 diversi segnali con frequenze specifiche, indicate proprio per quelle persone con problemi di udito, quindi selezionabili per verificarne l'efficenza paziente per paziente.

Qualcuno sà consigliarmi quali potrebbero essere esattamente, cosi da creare 9 diverse tonalità efficaci?

Normalmente un orecchio umano giovane sente suoni fino a 20 kHz. Con l'invecchiare tale soglia cala più in là che si va con gli anni. Alcuni hanno una soglia massima molto bassa, anche 5 kHz.
Capirai che se hai dei tali soggetti insieme la forbice di frequenze gestibili è ristretta, es: da 1 kHz a 5 kHz sono 4 kHz di forbice che, per 9 differenti tonalità, fanno toni con intervalli da 444 kHz. Troppo pochi, secondo me: sfido uno a riconoscere un tono a 4 kHz da un tono a 4,444 kHz 

Potresti però usare la tecnica dei rintocchi dei campanili!
Un suono prolungato seguito da una sequenza di toni brevi il cui numero corrisponde al paziente chiamato in causa, così come i campanili battono i rintocchi contando le ore.
Esempio:
suono lungo - pausa - tono breve - pausa - tono breve
2 toni brevi = paziente n° 2

Ecc..

[Reply #104 on:]

 
Non è per forza così, io intendo creare 9 seglazioni composte da più tonalità, utilizzando frequenze audio e pause differenti, in maniera che al momento dell' installazione, si possa scegliere il suono più udibile dal paziente.
Se vogliamo, si possono chiamare suonerie, anzi le chiamerò proprio così.
Quello di cui ho bisogno però, è che qualcuno della comunità, esperto di udito, mi indichi quali possono essere le frequenze migliori da utilizzare, visto che per il mio orecchio, ci sono delle frequenze che effettivamente mi danno quasi fastidio e sento molto di più, ed altre no, le quali invece potrebbero essere udibili dai pazienti.