next topic »

[Reply #30 on:]

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 ?

[Reply #31 on:]

 
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.

[Reply #32 on:]

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

[Reply #33 on:]

 

(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.

[Reply #34 on:]

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

[Reply #35 on:]

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:

Code:

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.

[Reply #36 on:]

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

[Reply #37 on:]

Ho anche scritto una libreria per la localizzazione.

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

[Reply #38 on:]

 
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.

[Reply #39 on:]

  Vedi tuxduino che i consigli non bastano mai?  

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?

[Reply #40 on:]

intendi per il linguaggio del device?

Intendo per sostituire tutte quelle if (lang == 0) print (in inglese) else print (in italiano) con un'unica chiamata del tipo print(string_id) con selezione automatica della stringa appropriata basata sulla lingua attualmente selezionata.

[Reply #41 on:]

La struct effettivamente sarebbe la più corretta, anche per sistemare l'indice da 0 a 31.

Per il discorso dell'indice è sufficiente evitare di usare la posizione 0 per memorizzare i parametri dell'allarme attivo, e memorizzare soltanto il suo indice.

Pensavo che un altro upgrade del codice potrebbe essere aggiungere un flag "attivo" ad ogni allarme.

(ok, sono in modaltà branstorming :-P )

[Reply #42 on:]

  ok tuxduino, anche se mi porterà via un pò di tempo, credo che in questo modo il codice possa snellirsi.
Occorre tener conto anche che questo progetto fino alla R05d rimarrà progetto base e tutte le evoluzioni avranno una release diversa.

Per il discorso dell'indice è sufficiente evitare di usare la posizione 0 per memorizzare i parametri dell'allarme attivo, e memorizzare soltanto il suo indice.

Pensavo che un altro upgrade del codice potrebbe essere aggiungere un flag "attivo" ad ogni allarme.

(ok, sono in modaltà branstorming :-P )

Per la gestione dell' allarme, basta selezionare medicina = 0, così da non essere preso in considerazione.

[Reply #43 on:]

Chiarisco che le mie osservazioni sono soltanto suggerimenti non richiesti su come _secondo me_ si potrebbe migliorare il codice. Resta assodato che l'ottimo è nemico del buono e che ciò che funziona di solito si tiene com'è ;-)

Poi ognuno ha il suo stile di programmazione, ecc.... insomma le solite ovvietà.

Comunque oltre a dire vorrei anche fare, se posso permettermi, quindi spero di riuscire a postare un po' di codice per aiutarti a mettere l'rtc e soprattutto ad inserire la eeprom nella mischia.

Ciao

[Reply #44 on:]

 
Non ti preoccupare, come ti dicevo, i consigli sono sempre ben accetti, basta siano creativi.

Se hai qualche idea anche su come collegare il device al PC via USB senza resettarlo necessariamente, sarebbe molto utile poi, per implementare il SW, lo posso realizzare in VB il quale servirà eventualmente a leggere e programmare i parametri.

Ciao.