Arduo Memory Reminder Medicine

la variabile v è una variabile interna alla funzione freeRam, non potresti utilizzarla così…
Ecco uno sketch di esempio:

void setup()
{
Serial.begin(9600);
}

void loop()
{
int ramLibera = freeRam();
Serial.println(ramLibera);

}


int freeRam () {
  extern int __heap_start, *__brkval; 
  int v; 
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval); 
  }

Questo mi stamperà su seriale il numero di byte liberi della ram.

Ciao

Nicola

Una cosa che dimenticavo, naturalmente è importate anche il punto in cui si utilizza freeRam(), per debug sarebbe opportuno metterlo in più punti: in fondo al loop(), oppure all'interno di altre funzioni, così da tenere sott'occhio l'utilizzo di ram..

;) Grazie Nicola.

Ora è tutto più chiaro, praticamente il listato completo !!

Grazie ancora.

Ciao. Giuseppe G.

:grin: Come promesso, ho postato sul blog il filmato dimostrativo il circuito del progetto ed una guida veloce per la programmazione di ArduoMemoryReminder.

Un saluto a tutti.
Giuseppe G.

:grin: Dopo il test definitivo di 1 week delle implementazioni al codice, Vi presento le versione definitiva R05d del progetto base, che seguirà una seconda fase di evoluzione sul sito del FABLAB Torino.

Chi volesse partecipare a tale progetto, è libero di farlo, semplicemente postando qui le proprie impressioni o idee, o più serimente contattandomi o iscrivendosi al FABLAB.

All'inizio, sinceramente ero titubante sul fatto di postare il tutto rendendolo pubblico, poi, pensando all'utilizzo ed alla possibilità di aiutare chiunque ne abbia bisogno, ho deciso di pubblicarlo e renderlo aperto a tutti.

OPEN SOURCE ? .....Certo !

http://www.arduomemory.blogspot.it (versione base)

http://www.fablabtorino.org/portfolios/arduomemoryreminder/ (upgrade project)

Mi picerebbe condividere il progetto con chiunque abbia voglia di migliorarlo o autocostruirlselo per aiutare i propri cari qualora ne avessero bisogno.

Un saluto a tutti. Giuseppe G. ;)

Sono contento che tu abbia trovato utile il mio consiglio sugli scomparti. Ora un'altro consiglio.

Esistono tre tipi di daltonismo che creano problemi a distinguere il colore verde (deuteranopia), rosso (protanopia) e blu (tritanopia).

I LED di segnalazione, perciò, dovrebbero essere tutti gialli od ambra, a mio avviso.

Ricordati anche che mettere l'intera confezione di una stessa medicina nello scomparto, parte dal presupposto che il paziente riesca a prendere la medicina ed a ricordare la dose necessaria, cose non necessariamente vere nel caso di artrite alle mani e demenza senile: meglio dunque tanti piccoli scomparti [u]removibili/u e nella quantità già calcolata. Il vantaggio è che possono essere presenti nello scomparto più tipi di farmaci. Punterei, cioè, più che sulla [u]differenza[/u] delle medicine, sulla [u]dose[/u] da prendere in un dato momento.

Ciao, progetto molto interessante! Non fosse che ormai non mi serve più :( avrei provato ad implementarlo anch'io... Mentre leggevo questo topic e osservavo le foto sul tuo sito, mi chiedevo se esiste un modo per un non-programmatore di verificare che le indicazioni scritte nel dispositivo corrispondono ad una determinata serie di prescrizioni mediche. Mi spiego meglio: un familiare, il medico di famiglia o un'infermiere/a possono facilmente controllare, foglio alla mano, che quanto programmato sia corretto ? Probabilmente la combinazione LCD+tastiera+Menu è sufficientemente chiara, ma pensavo anche a qualcosa tipo un programma su PC che legge dal dispositivo la programmazione tramite la porta seriale e produce un report "human-readable" ;)

Sono contento che tu abbia trovato utile il mio consiglio sugli scomparti. Ora un'altro consiglio.

Esistono tre tipi di daltonismo che creano problemi a distinguere il colore verde (deuteranopia), rosso (protanopia) e blu (tritanopia).

I LED di segnalazione, perciò, dovrebbero essere tutti gialli od ambra, a mio avviso.

Ricordati anche che mettere l'intera confezione di una stessa medicina nello scomparto, parte dal presupposto che il paziente riesca a prendere la medicina ed a ricordare la dose necessaria, cose non necessariamente vere nel caso di artrite alle mani e demenza senile: meglio dunque tanti piccoli scomparti removibili (per portare più facilmente la dose alla bocca) e nella quantità già calcolata. Il vantaggio è che possono essere presenti nello scomparto più tipi di farmaci. Punterei, cioè, più che sulla differenza delle medicine, sulla dose da prendere in un dato momento.

Ciao cyberhs ;)

Osservazione corretta, ma il problema è precaricare la dose nello scomparto, hai visitato questo sito? http://www.instructables.com/id/The-Automatic-Medication-Dispencer/ potrebbe essere la soluzione.

Il progetto effettivamente al momento è indicato a quelle persone che hanno problemi di memoria ed ancora autodipendenti, ma per la dose, basterebbe indicarla sullo scomparto con un biglietto che ricordi ad esempio "Due pastiglie" o "Una capsula" etc.. o addirittura sul display. Come hai notato, all'interno degli scomparti, ho inserito un bigliettino con il nome della medicina e l'orario per facilitarne il riposizionamento dopo l'assunzione.

Per i led effettivamente, ho usato due colori "rosso e giallo" e potrebbero diventare tutti gialli, purchè in due distinte bacheche.

PS.: Perchè non partecipi anche tu al progetto, ho bisogno di consigli come questi per cercare di accontentare più persone possibili.

Grazie ancora cyberhs.

Ciao tuxduino,

Ciao, progetto molto interessante! Non fosse che ormai non mi serve più avrei provato ad implementarlo anch'io... Mentre leggevo questo topic e osservavo le foto sul tuo sito, mi chiedevo se esiste un modo per un non-programmatore di verificare che le indicazioni scritte nel dispositivo corrispondono ad una determinata serie di prescrizioni mediche. Mi spiego meglio: un familiare, il medico di famiglia o un'infermiere/a possono facilmente controllare, foglio alla mano, che quanto programmato sia corretto ? Probabilmente la combinazione LCD+tastiera+Menu è sufficientemente chiara, ma pensavo anche a qualcosa tipo un programma su PC che legge dal dispositivo la programmazione tramite la porta seriale e produce un report "human-readable"

Un suggerimento interessante, pensandoci, si potrebbe effettivamente, con un piccolo software, allacciarsi eventualmente anche telefonicamente con codice cliente "esempio codice fiscale" e password al device ed impostare direttamente, ad esempio dall'ufficio del dottore, lo stesso, e permettergli di cambiare le dosi e gli orari delle assunzioni. Un upgrade eventuale da tener presente anche per chi amministra il device, esempio figli, parenti o badanti.

PS.: Vale anche per te, ti piacerebbe partecipare al progetto, anche se non ne hai più bisogno? Ricorda che ci sono molte persone che al contrario ne hanno ancora. Un semplice gesto altruista ma di notevole importanza. Pensaci.

Grazie. Giuseppe G.

:astonished: L'idea di tuxduino, è interessante: poter vedere come è programmato il device dal PC.

Ho provato subito, semplicemente attivando la seriale ed inserendo una funzione che se si premono contemporaneamente i due tasti up e down, il device invia i dati via seriale in sequenza.

Ma se si attiva la seriale sull' IDE, al momento della connessione con il serial monitor, arduino si resetta cancellando i dati inseriti e non invia nulla, al secondo tentativo invia i dati di default.

Qualcuno sà indicarmi come eventualmente gestire questo problema e se è possibile ovviarlo?

PS.: Ho usato l' IDE 0022 per il test.

Grazie. :stuck_out_tongue_closed_eyes:

Vedo che rispetto alla mia idea sei già andato avanti qualche anno luce :-)

Forse dovrei dare un'occhiata al codice, ma non memorizzi tutto in eeprom ?

=( Eprom? No, uso la ram per memorizzare i parametri. Forse non basta la eprom, perche devo memorizzare ben 4 parametri per 32 allarmi + i parametri di sistema, però posso provarci. Rimane comunque il problema del reset di arduino che cancellerebbe l'ora e la data corrente.

PS.: La release del software R05d lo trovi sul sito del FABLABTorino al fondo del progetto.

Sul 2009/UNO c’è 1K di eeprom, a occhio direi che ci stai, ma cercherò di fare un paio di conti per bene…

Da ciò che scrivi mi pare tu ritenga RAM ed EEPROM alternative: no, semplicemente leggi i parametri dalla eeprom all’avvio del programma, e scrivi su eeprom i valori quando vengono modificati dall’utente. Se arduino viene spento, alla successiva accensione ricarica gli ultimi valori salvati.
(Ti chiedo scusa se tutto ciò è ovvio per te…)

Per quanto riguarda l’ora, lì non c’è pezza: o metti un rtc con batteria tampone, oppure ad ogni reset bisogna re-impostare l’ora. La libreria Time accopiata con un orologio i2c ha funzionato a meraviglia per me, in un progettino che ho fatto uno o due anni fa (ora non ricordo bene…).

Sì, ho trovato il link :wink:

:roll_eyes:

(Ti chiedo scusa se tutto ciò è ovvio per te...)

Non è proprio così. I consigli si possono condividere, anche se hanno poca rilevanza. Quando ho iniziato a progettare il device, non mi sembrava necessario usare anche la eprom, visto il fatto che prevedendo che lo stesso fosse sempre alimentato e tenuto attivo da una batteria tampone. Quindi non ne ho semplicemente tenuto conto. L'opzione di utilizzarla, potrebbe risolvere il problema in parte, mentre per il circuito RTC, anche questo preso in considerazione con il progetto base, ò stato scartato per mancanza di pin disponibili con Arduino Uno. L'implementazione del RTC sarà tenuta in considerazione eventualmente con l'upgrade del progetto, passando o all'utilizzo di un display seriale liberando almeno 3 pin su Arduino UNO, o utilizzando un Arduino più potente come il Mega o il DUE.

L'idea, era quella di utilizzare Arduino UNO, nudo e crudo, senza aggiunta di device esterni, a parte il display ed i componenti discreti come led, resistenze e pulsanti, indispensabili per il funzionamento.

Ciao.

Io non scomodei una Mega o un Due, visto che basta un chip da 50 Cents per liberare un po' di porte. Se inserisci ad esempio un PCF8574, usi il display in I2C e cosi' colleghi anche l'RTC, che secondo me e' indispensabile. Cosi' come la scrittura degli allrmi su EEPROM.

Una cosa mi pare brutta brutta, quella che chiami batteria tampone. Se lo schema e' quello postato, non e' in tampone e dubito fortemente che faccia funzionare il sistema. Forse riesce a mantenere i dati ( per un tempo limitato ), ma certamente il sistema non sara' operativo. Quindi tanto vale eliminarla e metterci l'RTC

Ciao, stavo leggendo il codice e mi sono venute in mente alcune osservazioni. Te le sottopongo sperando di rendermi utile :)

Ho notato che gli array alm_h e compagnia vengono inizializzati a partire dall'indice 1, fino all'indice 32. In C gli array sono 0-based, quindi se hai 32 allarmi gli indici dovrebbero andare da 0 a 31 (sì, ho notato che nelle dichiarazioni usi correttamente il numero 33). Oppure l'indice 0 ha un significato speciale ? (*)

Il numero 33 andrebbe sostituito con una costante simbolica, ad esempio const byte MAX_NUM_ALLARMI = 32. In questo modo risulterebbe più semplice modificare il programma per supportare un numero diverso di allarmi e comunque renderebbe il codice più "auto-documentante".

Mi pare che un allarme (correggimi se sbaglio) sia composto da 4 campi: - ora - minuto - paziente - medicina Qui una struct o una classe ci starebbe proprio bene...

Esempio:

struct Allarme {
    byte ora;
    byte minuto;
    byte idPaziente;
    byte idMedicina;
};

const int MAX_NUM_ALLARMI = 32;

struct Allarme allarmi[MAX_NUM_ALLARMI];

// valori di default per gli allarmi:
allarmi[0] = { 8,  0,  1, 1 };
allarmi[1] = { 8, 30, 1, 2 };

Avere la programmazione in un unico array faciliterebbe anche la lettura/scrittura su eeprom.

(*) edit: mi pare di capire che l'allarme in posizinone 0 è quello attualmente in corso.

Un'ultima cosa (per ora :-P ) mi pare poco sensato inserire nel codice una programmazione di default, almeno nell'ottica di pubblicazione del progetto. Se viene introdotto l'uso della eeprom si potrebbero lasciare giusto un paio di allarmi di esempio.

(se invece di usare nomi di variabili abbreviate usi nomi completi aiuti IMHO chi è intenzionato a contribuire al codice, rendendolo più chiaro e leggibile).

My 2 cents, come al solito :)

Ho anche scritto una libreria per la localizzazione.

Qui: http://arduino.cc/forum/index.php/topic,131966.msg992566.html

:) Ciao brunello !

Io non scomodei una Mega o un Due, visto che basta un chip da 50 Cents per liberare un po' di porte. Se inserisci ad esempio un PCF8574, usi il display in I2C e cosi' colleghi anche l'RTC, che secondo me e' indispensabile. Cosi' come la scrittura degli allrmi su EEPROM.

Una cosa mi pare brutta brutta, quella che chiami batteria tampone. Se lo schema e' quello postato, non e' in tampone e dubito fortemente che faccia funzionare il sistema. Forse riesce a mantenere i dati ( per un tempo limitato ), ma certamente il sistema non sara' operativo. Quindi tanto vale eliminarla e metterci l'RTC

Se ho ben capito, tutto con una I2C per tutte e tre le interfacce LCD, RTC ed EEPROM su di una unica seriale?

PS.: Effettivamente la cosa brutta brutta, è prevista solo per tamponare la mancanza di alimentazione, durante la quale non viene visualizzato nulla sul display LCD perchè il 5v scende a circa 3,9v che bastano a tener su il micro.

:D Vedi tuxduino che i consigli non bastano mai? :D

Ciao, stavo leggendo il codice e mi sono venute in mente alcune osservazioni. Te le sottopongo sperando di rendermi utile smiley

Ho notato che gli array alm_h e compagnia vengono inizializzati a partire dall'indice 1, fino all'indice 32. In C gli array sono 0-based, quindi se hai 32 allarmi gli indici dovrebbero andare da 0 a 31 (sì, ho notato che nelle dichiarazioni usi correttamente il numero 33). Oppure l'indice 0 ha un significato speciale ?

Il numero 33 andrebbe sostituito con una costante simbolica, ad esempio const byte MAX_NUM_ALLARMI = 32. In questo modo risulterebbe più semplice modificare il programma per supportare un numero diverso di allarmi e comunque renderebbe il codice più "auto-documentante".

Mi pare che un allarme (correggimi se sbaglio) sia composto da 4 campi: - ora - minuto - paziente - medicina Qui una struct o una classe ci starebbe proprio bene...

La struct effettivamente sarebbe la più corretta, anche per sistemare l'indice da 0 a 31. Per quanto riguarda i parametri di defaul non sono necessariamente indispensabili, io li ho inseriti per comodità, evitando così di programmare tutte le volte il device ad ogni upgrade, visto che lo stanno usando i miei genitori.

Quanto prima cerco di provvere alla sistemazione ed all' upgrade del codice per la struct dell'array parametri.

PS.: Cosa intendi per

Ho anche scritto una libreria per la localizzazione.

Qui: http://arduino.cc/forum/index.php/topic,131966.msg992566.html

intendi per il linguaggio del device?