Arduo Memory Reminder Medicine

:wink: Ok!

Sospetto che ci sia un baco in Time.cpp: prova ad inserire queste righe prima di #include "Time.h":

Code:

#if ARDUINO >= 100
#include <Arduino.h>
#else
#include <WProgram.h>
#endif

Ma perchè accade questo ?
PS: Mi piacerebbe capire perchè. C' e un link dove viene spiegato ? O è un problema della libreria non aggiornata?

:slight_smile: Ciao Leo72,

Ho dato una scorsa al progetto.
Bravi ad entrambi smiley-razz

Volevo suggerire solo una risposta al problema del reset dell'Arduino.
Esso avviene sempre, a meno che:

  1. non interrompi la pista RES-EN, però poi devi resettare la scheda a mano ogni qual volta la devi riprogrammare
  2. non riflashi l'Atmega8U2: http://arduino.cc/forum/index.php/topic,130621.0.html

Grazie per l'info utile per poter implementare l'eventuale SW per gestire la visone/programmazione dei parametri.

Scusa per la domanda banale, ma basta il ponticello HD o bisogna inserire anche le parti del SW ?

Il ponticello funziona grazie alle modifiche SW :wink:
Va quindi modificata prima la scheda per saldare il connettore ICSP, poi va cambiato il firmware all'Atmega e poi si può utilizzare il ponticello.

Ma perchè accade questo

Le versioni di Arduino precedenti alla 1 includevano WProgram.h. E' un dettaglio tecnico dovuto al fatto che Arduino è basato un progetto precedente denominato Wiring. Nel passaggio alla 1.0 hanno rinominato il .h principale in Arduino.h. Le librerie non aggiornate per la 1 hanno un problema, perché WProgram.h è sparito. Grazie alla #define ARDUINO è possibile "capire" in che ambiente stiamo compilando, e comportarsi di conseguenza.

:wink:
Bene! Al momento dell' inserimento del SW per la gestione dal PC ne terrò presente.

Grazie.

Ma non basterebbe inserire una patch nella libreria per sistemare il problema ? :roll_eyes:

E' proprio quella che ti ho postato prima :wink:

Time.h, come molte altre, non è una libreria "core", mantenuta dal team di Arduino. L'aggiornamento ad Arduino 1 sta al buon cuore e alla vonlontà dellos viluppatore / manutentore della libreria...

tuxduino:

[quote author=Giuseppe G. link=topic=124000.msg995631#msg995631 date=1352890280]
Ma non basterebbe inserire una patch nella libreria per sistemare il problema ? :roll_eyes:

E' proprio quella che ti ho postato prima :wink:
[/quote]
Non è così semplice! :smiley:
Quel sistema regola solo l'include del core di Arduino in base alla versione dell'IDE. Ma non fa nient'altro.
Dall'IDE 002x sono cambiate tantissime cose a livello di librerie per cui non è detto che con quel semplice trucco tutto funzioni sempre.

leo72:

tuxduino:

[quote author=Giuseppe G. link=topic=124000.msg995631#msg995631 date=1352890280]
Ma non basterebbe inserire una patch nella libreria per sistemare il problema ? :roll_eyes:

E' proprio quella che ti ho postato prima :wink:

Non è così semplice! :smiley:
Quel sistema regola solo l'include del core di Arduino in base alla versione dell'IDE. Ma non fa nient'altro.
Dall'IDE 002x sono cambiate tantissime cose a livello di librerie per cui non è detto che con quel semplice trucco tutto funzioni sempre.
[/quote]

Lo so che in generale è così. Nel caso di Time.h mi è bastato fare quella modifica e la libreria ha funzionato... Ovvio che la cosa migliore da fare è contattare lo sviluppatore :slight_smile:

Nuova versione.

Il pulsante di ack è attivo basso e collegato al pin ACK_BTN_PIN (12).

Il led/buzzer attivo alto è collegato sul pin ALARM_LED_PIN.

Quando c'è un allarme attivo il pin ALARM_LED_PIN lampeggia con periodo 1s e duty cycle 50%. In pratica sta acceso per 500ms e spento per 500ms.
Appena si preme il plsante di "accettazione" allarme (ack) l'allarme termina e il lampeggio del led si ferma.

Vengono utilizzate due nuove librerie:
// Button http://www.arduino.cc/playground/Code/Button
// FancyLED GitHub - carlynorama/Arduino-Library-FancyLED: Arduino Library for working with LEDs. Includes non-delay blinking, toggling status and other features
Entrambe richiedono la "patch-wprogram" postat in precedenza per poter compilare sotto Arduino 1.0.

LCDDailyAlarmClock.ino (15.5 KB)

FreeRam.h (256 Bytes)

:sweat_smile:
Ciao tuxduino,
che fatica starti dietro!

Ho dato un'occhiata al nuovo codice e noto con stupore, che usi molto le librerie, cosa che dovrei fare anche io.
Spesso mi imbatto in soluzioni obsolete o con accrocchi sw per far funzionare le idee, quando basterebbe conoscere soluzioni già testate, come quella del led.
Il problema è, come e dove andarle a cercare.
Usare le librerie, però non comporta un ulteriore ampliamento del SW e quindi spazio in memoria flash?

Bando alle ciance, credo che non basti la soluzione che hai postato per la libreria "Time.h", mi vengono fuori altri errori.

Al di là di questo, sono un po antiquato sll' IDE, in quanto la versione 1.0.1 mi da diversi problemi sul PC che ho a casa con sitema Win XP Pro SP3 installato su un PC AMILO datato, e non posso testare il tuo codice a livello HD. Si può portare il tuo codice ad una versione ridotta dell' IDE, tipo 0022 dove non ho problemi?

Ho visto che la 0022 non apre i file .INO ma solo i .PDE, mentre viceversa funziona.

Hai consigli a riguardo? (non mi dire che devo cambiare il PC!!! =( )

Ciao.

:slight_smile:

Tra il reinventare la ruota ad ogni sketch ed utilizzare quasi soltanto librerie bisogna trovare un punto di equilibrio.
Dipende da molti fattori... In definitiva è una scelta personale, anche legata al particolare progetto o momento.
Talvolta trovo più semplice / veloce / divertente / formativo scrivere codice mio per fare una cosa comune piuttosto che andarmi a cercare una libreria già fatta e capire se fa al caso mio.
Altre volte è meglio o più conveniente affidarsi a codice già pronto, per evitare di perdere tempo in dettagli importanti ma non direttamente legati al progetto in corso.

C'è poi il discorso di base: l'uso di librerie (nel caso di Arduino parliamo di solito di classi C++) rende il codice dello sketch più pulito e leggibile (ovvero meno probabilità di bachi e maggior facilità di modifiche).

Esempio: scrivo un programma che fa lampeggiare un led. Il lampeggio può essere avviato o fermato premendo un pulsante. Posso mettere tutto nello sketch principale e la cosa rimane comprensibile, manoto che già in un esempio così semplice vado a "mescolare" nel sorgente variabili legate esclusivamente alla gestione dello stato del led e altre variabili che entrano solo nel calcolo dello stato del pulsante. Inoltre il codice del led deve rimanere separato da quello del pulsante, per evitare il caos.
Ecco che introduco allora delle funzioni per raggruppare pezzetti di logica dentro un'unica chiamata dal nome intuitivo. Tipo isButtonPressed(), oppure activateLedBlink().
Nel passo successivo noto che posso raggruppare questse funzioni e le variabili di stato su cui operano in una classe, portando il tutto in file separati. Ecco che nascono ad esempio la classe Button e la classe BlinkingLed. E nel contesto di Arduino queste sono già due librerie. Che posso mettere in sketchbook/libraries e riutilizzare in altri progetti più o meno semplici.
Non solo: posso ora utilizzare più led e più pulsanti indipendenti nello stesso programma in modo estremamente semplice (e in certa misura elegante), senza aggiungere per questo decine di righe di codice.

Discorso analogo vale ad esempio per la temporizzazione degli eventi: l'esempio blink without delay mostra la tecnica di base. Per sketch banali la si può anche usare nuda e cruda (con la variabile _prevMillis usata direttamente) ma all'aumentare dellal complessità diventa molto comodo (e talvolta indispensabile) usare librerie già pronte che la incorporano. Anche perché spesso hanno funzionalità aggiuntive che un'implementazione "nuda e cruda" porta a trascurare.

La risposta breve è: se una cosa la devi fare, il codice lo devi mettere. Che sia scritto direttamente nello sketch o già presente in una funzione di libreria, cosa cambia ?

Più in dettaglio...
In generale è vero il contrario. Usando le funzioni di una libreria al posto della ripetizione del codice "nudo e crudo" si risparmia sulla dimensione del programma. Inoltre il compilatore è abbastanza intelligente da includere nell'eseguibile finale solo le funzioni effettivamente utilizzate di una libreria. Può capitare tuttavia che il "peso" di una libreria sia maggiore rispetto ad un eventuale codice specifico scritto ad hoc, ad esempio perché la funzione di libreria tenta di risolvere il problema in termini più generali, quindi include codice che in quel particolare progetto a noi non serve.
Anche qui non esiste una ricetta valida per tutte le occasioni: bisogna valutare caso per caso, magari provare diverse librerie o, se necessario, (ri)scrivere alcune funzionalità da zero in modo dedicato al particolare problema.

Il mio consiglio è di passare alla 1.0.2, comunque proverò a compilare lo sketch anche sotto l'ultima versione pre-1.0 (mi pare sia la 0023).
Eventualmente ti mando un zip con il codice delle librerie che ho sul mio pc. Può essere che abbia fatto qualche modifica in più che non ricordo...
Dal punto di vista del PC non credo ci siano problemi nel passare dalla 22 alla 1.0.2. Le richieste di sistema sono circa uguali.

:sweat_smile:
Grazie tuxduino della gentile risposta. Un pò più chiaro ora il concetto sull'uso delle librerie, ma rimane il fatto che bisogna conoscerle e per conoscerle bisogna usarle ed in primis, sapere dove cercarle e come.
A riguardo sai se esiste un elenco dettagliato di tutte o quasi, a parte quelle licenziate da arduino?

Ora provo a scaricare la 1.0.2, la 0023 dovrei già averla scaricata e verifico la compilazione.

Ciao.

A riguardo sai se esiste un elenco dettagliato di tutte o quasi, a parte quelle licenziate da arduino?

Più che di librerie "licenziate" direi incluse insieme all'IDE.

Per quanto riguarda un elenco completo... Proprio qui sul sito di arduino trovi un bel po' di materiale scritto dagli utenti, organizzato per tipo di funzionalità, nella sezione Playground (ma forse lo sapevi già...).
Per il resto non credo esista un elenco aggiornato e affidabile, per il semplice motivo che ognuno può scrivere una classe(ttina) e pubblicarla.
Di solito i negozi online più rinomati pubblicano una libreria a corredo delle schede o degli shield che vendono.
Ad esempio ho appena acquistato un motor shield della adafruit: sul sito è ben pubblicizzata anche la relativa libreria, veramente facile da usare anche senza studiarla.
Altrimenti faccio una normale ricerca su google: arduino + la parola chiave della funzionalità che cerco porta quasi sempre a dei buoni risultati.

:slight_smile:

:stuck_out_tongue:
Ho portato avanti il codice iniziale R05d, inserendo i dati in eprom e creando un array di default che solo se si tiene premuto il tasto down all'accensione, il device carica i dati di default in ram, e sovrascrive la eprom.

Giusto per non restare fermo.

Ho preferito non toccare nulla del tuo, anche perchè il confronto parallelo, porta ad un upgrade più completo.
Mi spiego: se ci concentriamo tutti e due sullo stesso argomento, c'è il rischio di non venirne a capo.
Nel momento in cui uno dei due trova una soluzione, la si può condividere ed utilizzare per perfezionare il codice.
Che ne pensi ?

Io mi sto organizzando per recuperare l'RTC, perchè non vedo soluzioni, a parte il ponticello HD e la modifica SW per ovviare al reset collegando il device al PC.

Il discorso LCD e tastiera è al momento trascurabile. Quando avremo bisogno di pin ci penseremo.

Ciao, ti rispondo in ordine sparso...

L'uso di un RTC secondo me è imprescindibile per rendere veramente completo il tuo progetto :slight_smile:

Interessante l'idea del reset degli allarmi tenendo premuto il tasto all'avvio :slight_smile:
Appena ho un attimo do un'occhiata al tuo nuovo codice.

Nel frattempo ho compilato il mio sotto 0023: non compila per l'assenza della macro F(), utilizzata per spostare facilmente le stringhe in PROGMEM, ma assente nella 0023. Metto una #define per risolvere la cosa.

Credo anch'io che sia meglio portare avanti i due codici in parallelo, almeno per ora :slight_smile:

Infine, per quanto riguarda il consumo di pin... Nel caso serva, basta usare un lcd seriale: usa soltanto 1 pin per la ricezione dei caratteri; dal punto di vista software invece della LiquidCrystal si usa la SoftareSerial e si inviano semplicemente i caratteri da visualizzare (e giusto un paio di byte particolari per pulire il display e impostare la posizione del cursore...)
Per la tastiera non saprei... ma come hai detto tu non è prioritario per ora.

:wink:
Ho postato sul FABLAB la release R05F con gli aggiornamenti dell'array dei parametri di default ed il backup su eprom.

Nella prossima release "R05G" verranno aggiornate tutte le descrizioni delle funzioni, per rendere più comprensibile il codice.

Ricordo che il funzionamento esatto del device con tutte le funzioni ad oggi disponibili, sarà aggiornato non appena tuxduino avrà disponibile una release completa.

A giorni posterò il funzionamento completo fino alla release R05F/R05G con tanto di esempi.

Un saluto a tutti.
Giuseppe G.

Ciao Giuseppe,
leggendo la funzione verirow() c'è una cosa che non capisco: perché cambi la modalità dei pin da INPUT a OUTPUT e viceversa ?
Grazie!

(edit: forse è per mettere il pin in alta impedenza e impedire così l'accensione di entrambi i led ?)

Sempre a proposito della verirow(), ho ricavato la "tabella della verità", cioè la configurazione e i valori di uscita delle linee in base al numero del paziente e al numero della medicina.

Codificando queste informazioni sottoforma di array si potrebbe riscrivere la funzione in modo molto più conciso.
Si potrebbe arrivare ad una funzione utilizzabile così:

verirow(patientNum, medicineNum);

patient 1

mednum    line1 line2 line3    a0    a1    a2    a3    a4
   1       O,1   I     I       I     O,0   I     I     I
   2       I     O,1   I       I     O,0   I     I     I
   3       I     I     O,1     I     O,0   I     I     I
   4       I     I     I       O,1   O,0   I     I     I
   5       O,1   I     I       I     I     O,0   I     I
   6       I     O,1   I       I     I     O,0   I     I
   7       I     I     O,1     I     I     O,0   I     I
   8       I     I     I       O,1   I     O,0   I     I
   9       O,1   I     I       I     I     I     O,0   I
  10       I     O,1   I       I     I     I     O,0   I
  11       I     I     O,1     I     I     I     O,0   I
  12       I     I     I       O,1   I     I     O,0   I
  13       O,1   I     I       I     I     I     I     O,0
  14       I     O,1   I       I     I     I     I     O,0
  15       I     I     O,1     I     I     I     I     O,0
  16       I     I     I       O,1   I     I     I     O,0

patient 2

mednum    line1 line2 line3    a0    a1    a2    a3    a4
   1       O,0   I     I       I     O,1   I     I     I
   2       I     O,0   I       I     O,1   I     I     I
   3       I     I     O,0     I     O,1   I     I     I
   4       I     I     I       O,0   O,1   I     I     I
   5       O,0   I     I       I     I     O,1   I     I
   6       I     O,0   I       I     I     O,1   I     I
   7       I     I     O,0     I     I     O,1   I     I
   8       I     I     I       O,0   I     O,1   I     I
   9       O,0   I     I       I     I     I     O,1   I
  10       I     O,0   I       I     I     I     O,1   I
  11       I     I     O,0     I     I     I     O,1   I
  12       I     I     I       O,0   I     I     O,1   I
  13       O,0   I     I       I     I     I     I     O,1
  14       I     O,0   I       I     I     I     I     O,1
  15       I     I     O,0     I     I     I     I     O,1
  16       I     I     I       O,0   I     I     I     O,1

Dunque... ho studiato un po' lo schema elettrico. Mi sembra che la verirow() si possa semplificare...
Ho buttato giù una funzione generica per pilotare la matrice di led. Ecco il codice:

const byte NUM_ROWS = 4;
const byte NUM_COLS = 4;

byte rowPins[NUM_ROWS] = { A1, A2, A3, A4 };
byte colPins[NUM_ROWS] = {  8,  9, 10, A0 };

// tutti i pin che pilotano la matrice sono di OUTPUT
// quesat routine va chiamata in setup()
void pinSetup() {
    byte i;
    
    for (i = 0; i < NUM_COLS; i++) {
        pinMode(colPins[i], OUTPUT);
    }
    
    for (i = 0; i < NUM_ROWS; i++) {
        pinMode(rowPins[i], OUTPUT);
    }
}


// spegne tutti i led
void allOff() {
    byte i;
    
    for (i = 0; i < NUM_COLS; i++) {
        digitalWrite(colPins[i], LOW);
    }
    
    for (i = 0; i < NUM_ROWS; i++) {
        digitalWrite(rowPins[i], LOW);
    }
}


// accende tutti i led di un colore o dell'altro
void allOn(byte highOrLow) {
    byte i;
    
    for (i = 0; i < NUM_COLS; i++) {
        digitalWrite(colPins[i], highOrLow);
    }
    
    for (i = 0; i < NUM_ROWS; i++) {
        digitalWrite(rowPins[i], !highOrLow);
    }
}


// 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();

    digitalWrite(colPins[col], value);
    digitalWrite(rowPins[row], !value);
}

Il codice compila, ma ovviamente non l'ho provato sull'hardware... In allegato trovi questo codice unito a setup() e loop() a formare uno sketch di prova che dovrebbe semplicemente illuminare uno ad uno i led in sequenza, prima di un colore, poi dell'altro.

Penso che questo codice si possa già integrare nel tuo, sostituendo il corpo della verirow() con una roba tipo questa (tieni conto che nel mio codice l'indice della cella va da 0 a 15, non da 1 a 16):

if numero medicina == 0
allOff()
return

if numero medicina <= 16
writeCell(numero medicina - 1, 0)
else
writeCell(numero medicina - 16 - 1, 1);
endif

Ciao!

AMR_LedMatrixTest.ino (1.47 KB)

Ciao Giuseppe,
leggendo la funzione verirow() c'è una cosa che non capisco: perché cambi la modalità dei pin da INPUT a OUTPUT e viceversa ?
Grazie!

(edit: forse è per mettere il pin in alta impedenza e impedire così l'accensione di entrambi i led ?)

Ciao tuxduino, :wink:
è proprio così, se tengo a +5V o a 0V, quando la inea dei primi 4 led ad esempio viene portata a +5V, questa fà si che si accendano tutti e 4.

Buona l'idea quella della matrice, che potrebbe diventare un libreria per gestire fino a 162 led indipendenti con la UNO (dove ci saranno 9 linee per 9 righe, moltiplicato 2 "per la polarizzazione"), una buona soluzione per un gioco di luci!!! (visto che siamo sotto natale!)

Se puoi, verifica l'hardware, ma io non ho trovato altre soluzioni al di fuori che questa.