sto cercando di realizzare una comunicazione wireless tra due xbee e Arduino.
L'xbee remota (quella mobile) legge 3 ingressi analogici e periodicamente li invia ad arduino.
Vorrei cambiare questo "periodicamente".. per risparmiare batteria , vorrei usare il pin SLEEP REQ della Xbee per farla risvegliare l'xbee solo quando necessario, cioè quando
UNO QUALUNQUE dei 3 sensori è > di GND (0).
Ho pensato ad una logica che dovrebbe funzionare, ve la allego qui in una immagine (logica1.png).
L'uscita della porta NOR (chiamiamola Y) è collegata al pin 9 dell'Xbee.
In pratica con 3 comparatori di tensione trovo le tensioni > GND e poi una logica NOR mi abbassa il pin sleep della xbee ogni volta che almeno una uscita di un comparatore è > GND.
Questo dovrebbe funzionare, tuttavia ho un problema: quando i sensori tornano tutti a zero l'uscita della logica NOR va instantanemente a 1 e l'xbee torna a dormire
Per i requisiti della mia applicazione vorrei che l'xbee campionasse ancora per un po, circa 1 secondo. Quindi mi servirebbe per esempio una rete RC che ritarda il fronte di salita del pin sleep (Y di prima). Ma il fronte di discesa deve essere immediato!!
Sapete come potrei fare questa rete RC?? Ci vuole un diodo anche il fronte di discesa immediato??
Oppure avete delle altre idee? Tenete conto che non ho molto spazio sulla scheda, quindi mi serve qualcosa di più piccolo e semplice possibile!
Ho già valutato altri modi di configurazione dell'xbee, ma o non sono adatti o consumano troppa batteria (l'xbee è quasi sempre sveglia.. cyclic sleep..).
Se non mi sono spiegato bene non esitate a chiedere.
Grazie mille per il vostro tempo!
Sicuro che vale la pena utilizzare tutte queste logiche discrete ??? Ti sei fatto un conto degli assorbimenti ?
Perché magari ... alla fine ti semplifichi la vita e consumi più o meno uguale mettendoci un ATtiny ...
Sono piccolissimi (6 o 8 pin quelli più piccoli), assorbono poco, hanno ADC a bordo e ... te li programmi come ti pare XD
Cacchio non sapevo neanche dell'esistenza di mcu atmel cosi piccole!
E in effetti si possono programmare anche con il programmatore di Arduino da quanto ho visto.
Sul datasheet c'è scritto 300 ua di corrente in idle per il modello più piccolo (da 1.8 v!!) e 1 ua quando in sleep!!
Non credo che la logica CMOS che avevo in mente di fare consumi di meno: infatti solo gli op-amp consumano 0.8 ma l'uno da quanto ho capito dal datasheet!!
Adesso che ci penso, dovrei anche monitorare il voltaggio della batteria, c'è un modo semplice? E' sufficiente leggerlo da un ingresso del micro?
Considera che hai a bordo un ADC come quello che hai su Arduino ... più o meno, quello che misuri con uno, misuri con l'altro e quindi ...
Se fai un po' di ricerche qui sul forum, troverai svariati esempi ed informazioni relative al ATtiny85 (il più grandicello della famiglia a 8 pin disponibile in DIP) ... che molti di noi hanno usato e tutt'ora usano XD
Grazie!
Ho guardato un po su forum e i datasheet, conviene quindi prendere un 85 che ha più memoria per il programma e SRAM giusto?
Comunque me ne serve uno piccolo quindi sicuramente 8 pin DIP.
Il 13 mi sembra un po limitato, con solo 1kb di flash..
Ok, grazie per i link.
Ma a cosa serve un "core"? Devo fare l'upload sulla mcu prima di programmarla?
O sono librerie che servono appunto per la programmazione??
Quando tu scrivi una funzione di quelle che sei abituato a richiamare dal IDE ... o chiami elementi base del C o chiami delle funzioni che qualcuno ha scritto per te per semplificarti la vita ... ovvero funzioni del "core".
Per spiegarmi ... quando tu scrivi una banale pinMode(pin, OUTPUT) ... in realtà vai a chiamare questa funzione :
void pinMode(uint8_t pin, uint8_t mode)
{
uint8_t bit = digitalPinToBitMask(pin);
uint8_t port = digitalPinToPort(pin);
volatile uint8_t *reg, *out;
if (port == NOT_A_PIN) return;
// JWS: can I let the optimizer do this?
reg = portModeRegister(port);
out = portOutputRegister(port);
if (mode == INPUT) {
uint8_t oldSREG = SREG;
cli();
*reg &= ~bit;
*out &= ~bit;
SREG = oldSREG;
} else if (mode == INPUT_PULLUP) {
uint8_t oldSREG = SREG;
cli();
*reg &= ~bit;
*out |= bit;
SREG = oldSREG;
} else {
uint8_t oldSREG = SREG;
cli();
*reg |= bit;
SREG = oldSREG;
}
}
... che qualcuno ha scritto per te per nasconderti tutto quello che c'è realmente dietro e semplificarti la vita.
Ora, ovviamente l'IDE di Arduino include i "core" per le MCU usate sulle schede Arduino (328P, 32U4, MEGA2560, ...) ma non per il ATtiny85 ...
Dato che è molto usato ... qualcuno si è preso la briga di ..."prepararti la pappa" ovvero scrivere il "core" anche per quella MCU !
Ok, grazie per la spiegazione molto "maccheronica"
Adesso infatti mi è venuto in mente che anche con Arduino ho sempre usato la libcore.
Quindi, nel caso qualcun altro legga questa thread si tratta di librerie che contengono il codice dipendente dalla piattaforma (MCU) che sono usate nell'applicazione e cambiano in base alla MCU utilizza.
Attualmente sto linkando la core di arduino 1.0.5 per l'applicazione di Arduino, e dovrò usare quella per il Tiny85 https://code.google.com/p/arduino-tiny/downloads/detail?name=arduino-tiny-0100-0018.zip&can=2&q=
quando programmerò quella MCU.
Non vorrei abusare della tua pazienza Guglielmo, ma diciamo che me la cavo meglio con il sw rispetto all'hw...e quindi ho un'altra domanda: siccome vorrei alimentare l'xbee (e ATtiny) con 2 batterie alkaline da 1.5 v ad alto amperaggio, è necessario mettere un regolatore di tensione e relativi condensatori? Oppure nel caso di alimentazione a batterie non servono??
Grazie mille ancora!
Le batterie per definizione danno corrente continua che resta abbastanza costante fino a quando ... non ti avvicini alla loro scarica quindi ...
Il regolatore non ti serve ... magari tieni d'occhio la tensione della batteria e quando inizia a scendere dai un allarme.
certamente non ti servono condensatori di stabilizzazione (quelli da centinaia di ?F) ... se tu avessi carichi induttivi, allora quelli da qualche centinaio di nF potrebbero abbattere i disturbi ... ma nella tua configurazione (un XBee e un ATtiny85) non ne vedo troppo la necessità.
Per il "core" ... dovrai semplicemente copiare la cartella "arduino-tiny-0100-0018" dentro una cartella "hardware" che deve trovarsi nella stessa cartella di base dove hai anche quella delle librerie ("libraries"). Al lancio l'IDE (1.0.5) la vedrà e ti appariranno le nuove MCU che potrai selezionare come ora selezioni i vari Arduino.
ok, allora risparmio sul regolatore, magari metterò due condensatori per sicurezza, come da manuale per l'xbee.
Infatti c'è scritto che durante le trasmissioni RF l'xbee ha dei picchi di corrente in cui un condensatore da 1uF potrebbe far comodo.
Per quanto riguarda la libreria core, io non mai usato l'ide di arduino..
Non mi piace...
Ho configurato dei progetti in Eclipse (che è molto meglio) e riesco anche ad usare librerie esterne..
In particolare linko la libreria libcore.a (sotto Linux) e includo gli header che mi servono.
Quindi presumo che dovrò compilare la libreria core per le Tiny e linkare quella, ma questo lo verificherò quando avrò la MCU in mano!
gion86:
Per quanto riguarda la libreria core, io non mai usato l'ide di arduino..
Il "core" più che una libreria è un insieme di .c e .h che vengono automaticamente inclusi dall'IDE
Comunque ... se è solo una questione "estetica/pratica", ma comunque compili usando le facilitazioni Arduino (il "core" scritto da loro), allora prefrisco usare "Sublime Text" con il plugin-manager e l'ottimo plugin per Arduino.
Se invece non si usa il "core" (... ovvero ci si scrive tutto a manina in C con il datasheet della MCU in mano) allora preferisco usare "MikroC Pro for AVR" ... XD
Giusto, due ottimi tool.
Però uno non è gratuito, e neanche open source a quanto vedo.
E l'altro costa un botto! :~
Alla fine è solo una questione di gusti personali, io Eclipse lo sapevo già usare ed è molto comodo con il plugin C/C++ e compilando con le core, per semplificarmi la vita.
Sapresti anche consigliarmi un servizio per commissionare dei PCB?? Molto semplici, potrei anche farmeli in casa, ma se costa poco....
Cavolo che prezzi!!
Va be ci penserò, intanto se hai tempo potresti dare una occhiata alla scheda che ho fatto?? Ti mando i file di eagle, poi se non riesci niente. Le letture dei tre sensori analogici mi arrivano da un'altra scheda, che ho già fatta e non posso cambiare ovviamente.
Salderò dei cavetti per collegare le due schede, non saprei come fare altrimenti.
Avrei qualche dubbio sulla scheda che sto "creando", tipo:
Come Xbee quali usi ? Quelli con l'antennina a filo ? Metticelo il piano di terra ... migliora anche la parte RF
Unico dubbio ... vedo che hai usato anche il pin 1 del Tiny ...
... immagino tu sappia che una volta che metti i fuse per usarlo non come reset ma come pin di I/O, poi ... per riprogrammarlo devi azzerare i fuse con un programmatore HV !
Per il resto, mi sembra ok ...
Guglielmo
P.S. : Visto che prezzi in Italia ??? ... con il costo di due pezzi, quelli di Itead Studio te ne fanno 20 !!!
Uso l'xbee serie 1, una con l'antenna a filo (quella remota sui sensori) e uno con connettore rpsma, (quella su arduino) e ho preso una bella antenna da 8db!! (Arduino è dentro ad un tabellone segnapunti.. protetto da una gabbia metallica per le pallonate, quindi credevo che l'xbee potesse avere problemi, e ho preso l'antenna esterna..)
Aspetta aspetta.. cos'è questa storia del pin 1??????????????
Mi serve un programmatore per riprogrammare la MCU se lo uso come IO?? Puoi spiegarti meglio??
Oppure è solo il pin che devo riprogrammare come reset??
Su alcune MCU della Atmel il pin 1, che normalmente è il pin RESET, può essere programmato, modificando i fuse, come normale pin di I/O (... e quindi non più come pin di reset) MA ... c'è un problema, se elimini il pin di RESET, che è usato dai programmatori ISP, non puoi più riprogrammare il chip !
Devi avere allora non un normale programmatore via ISP, ma un programmatore HV, tipo QUESTO, per poter resettare la situazione e ripristinare il pin di RESET.
Tu che programmatore hai per programmare questi chip ???
:~
