Domotica con Arduino

Forum 2005-2010 (read only) International Italiano
381

Ho parlato con il mio collega ingegnere condividendo con lui il discorso shift-register realizzato con PIC.

Pur condividendo il motivo, mi ha detto di stare in campana...e in effetti non c'avevo pensato!

Uno shift-register hardware (es. 74hc595) è moooooooooolto + veloce di un microprocessore. Il rischio di usare un uC per fare da shift è che non sia sufficientemente veloce da ricevere i dati ed essere in sync con il uC mittente! Tra l'altro l'ATMega328 è a 16 Mhz, mentre il PIC di solito è 4 Mhz...valuterò meglio il discorso!

Resta valido invece il discorso watchdog fatto con il PIC xkè tanto i tempi sono mooolto + dilatati per quel frangente!

Sempre che decidiamo di fare questa modifica...riflettiamo!

382

Scusate ragazzi, mi spiegate meglio a cosa serve il watchdog ? Grazie

383

Il watchdog è un dispositivo che serve a verificare che il processo svolto dal microprocessore non sia impallato o in un loop infinito.

Sostanzialmente è un contatore che autonomamente si decrementa e che, se arriva a 0, provoca un reset del microprocessore. Quindi è espressamente un compito del software quello di resettare con una cadenza inferiore a quella che ci impiega il watchdog ad arrivare a 0 di resettare tale contatore per farlo ripartire da capo.

Tutti i uC hanno un watchdog interno, ma ho letto che il watchdog di arduino ha dei limiti imposti dal bootloader e, comunque, non provoca un vero e proprio reset (Es. non resetta anche lo shield connesso).

Quindi abbiamo ipotizzato di gestire un watchdog hardware! In questo modo se il software eseguito da arduino si impalla esso viene resettato e, se invece ad impallarsi è solo lo shield (arduino continua a lavorare correttamente) si invia un reset solo allo shield separatamente.

384

Che ne dite del PIC18F43K20?

Potrebbe fare entrambi i lavori, non costa tanto ed è veloce.

per il controllo ingressi/uscite si potrebbe collegare tramite i2c

Per quanto riguarda il discorso bus di campo (per ora rs485) da affiancare al progetto,
siccome già ci sto lavorando e non mi dispiacerebbe una mano,
c'è qualcuno che è interessato e vuole aiutarmi?
Grazie

385

@ Astroz: Grazie x la delucidazione sul watchdog !
@ Luke: Io ho già realizzato un protocollo custom che lavora su RS485. Non so nemmeno se definirlo protocollo, ma per ora funziona bene sulla mia configurazione. Ti spiego brevemente come funziona, poi se vi interessa vi mando i sorgenti:

Tutti i nodi normalmente stanno in ascolto, quando devono inviare qualcosa a qualcuno alzano il bit di direzione e inviano 10 BYTE rispettivamente:

BYTE 0: Rapresenta l'inizio del messaggio ed è fisso, nel mio caso a B11110000 (0xF0)

BYTE 1: E' l'indirizzo del mittente, nel mio caso il nodo "luci" e il B00000000 (0x00), il nodo ricevitore infrarossi e il B00000001 (0x01) ... ecc

BYTE 2: E' l'indirizzo del destinatario del messaggio, dice quale nodo deve eseguire il comando (si potrebbe eventualmente prevedere un indirizzo di broadcast per far eseguire il comando a tutti i nodi)

Byte 3: E' il comando da eseguire. Per esempio 0x02 significa "messaggio ricevuto correttamente" 0x03 significa "setta uscita", 0x04 "resetta uscita", 0x05 "inverti uscita", 0x06 "Esegui una determinata funzione", 0x07 "richiedi lo stato di un ingresso digitale" ecc ...

BYTE 4: E' il puntatore e dipende da quale comando inviamo. Per esempio se invio il comando "setta uscita" "10000000 00000001" con il puntatore che vale 0x00 io setterò l'uscita numero 0 e la numero 15, invece con il puntatore che vale 0x01 io setterò l'uscita 16 e 31, con il puntatore che vale 0x02 io setterò l'uscita 32 e 47 ... in poche parole dividendo le uscite in gruppi da 16, il puntatore mi diche a quale gruppo mi riferisco. Lo so non è chiarissimo ma magari poi faccio degli esempi.

BYTE 5 e BYTE 6: Rappresentano il valore del comando. Sempre con l'esempio del "setta uscita" impostando il puntatore a 0x00 se il BYTE 5 e il BYTE 6 valgono rispettivamente B01010101 e B01010101 io setterò le uscite n° 0, 2, 4, 6, 8, 10, 12 e 14. Praticamente faccio una maschera: dove ho un "1" setto l'uscita corrispondente, dove ho "0" non la setto.

BYTE 7 e BYTE 8: Sono 2 byte che vengono calcolati in base al valore di tutti gli altri 8 byte (magari piò avanti vi spiego come) servono per vedere se il messaggio arriva integro o se c'è stato un errore sulla trasmissione. Praticamente prima di inviare il messaggio calcolo questi 2 byte e li inserisco. Chi riceve il messaggio fa la stessa operazione e se ottiene come risultato proprio i byte 7 e 8 significa che il messaggio è integro.

BYTE 9: Rapresenta la fine del messaggio ed è fisso, nel mio caso a B11110001 (0xF1)

Praticamente tutti i nodi ricevono il messaggio, ma solo il destinatario eseguirà il comando.

Ora un piccolo esempio di comunicazione:

Il nodo ricevitore infrarossi invia:

0xF0 0x01 0x00 0x03 0x00 0x01 0x02 0x82 0xF4 0xF1 che significa

0xF0 Inizio messaggio
0x01 Sono il nodo ricevitore IR
0x00 il seguente comando è destinato al nodo "luci"
0x03 setta i relè
0x00 del gruppo "0"
0x01 (B00000001) n°15 no, n°14 no, n°13 no, n°12 no, n°11 no, n°10 no, n°9 no, n°8 si
0x02 (B00000010) n°7 no, n°6 no, n°5 no, n°4 no, n°3 no, n°2 no, n°1 si, n°8 no
0x82 Primo byte del controllo integrità
0xF4 Secondo byte del controllo integrità
0xF1 Fine del messaggio

e il nodo "luci" esegue il comando e risponde:

0xF0 0x00 0x01 0x02 0x00 0x00 0x00 0x48 0x20 0xF1 che significa

0xF0 Inizio messaggio
0x00 Sono il nodo luci
0x01 il seguente comando è destinato al nodo "ricevitore IR"
0x02 ti informo che il messaggio che mi hai appena inviato aveva i 2 byte di verifica corretti, quindi la trasmissione è avvenuta corretamente
0x00 // In questo comando non serve
0x00 // In questo comando non serve
0x00 // In questo comando non serve
0x82 Primo byte del controllo integrità
0xF4 Secondo byte del controllo integrità
0xF1 Fine del messaggio

386

@lukeskycopper: l'ho detto la storia del pic come controller degli input e output era buttata là così...se diventa un problema di difficile implementazione o un point of failure lascerei stare...

Ieri sera mi sono messo a giocare con il pickit2 e a parte la complessità dell'ambiente di sviluppo, sono riuscito a fare un programma che facesse più o meno ciò che volevo, ma ci sono delle cose che davvero ignoro!

Ma direi che se serve a gestire il watchdog alla fine il programma sarà piuttosto semplice...e anche il 12f629 dovrebbe bastare...è un 4+4 e ha 6 general purpose i/o:
1 - interfaccia con atmega
2 - interfaccia con atmega
3 - reset atmega
4 - reset shield
5 - gestione output enable shiftout
6 - led di stato

387

L'idea del PIC come gestore degli input e output sostanzialmente avrebbe aggiunto delle potenzialità in quanto anche essi, potendo essere programmati, avrebbero potuto effettuare gestioni lievemente più complesse...esempio: lo shift di input avrebbe potuto campionare autonomamente gli ingressi e registrare in locale il verificarsi di un evento e, quando l'atmega andava a fare lo "scarico dei dati" avrebbe trovato anche un evento non occorso in quel momento! Non sò se mi sono spiegato bene...

...in ogni caso è troppo difficile la realizzazione e rischiosa. Inoltre un PIC con 8 in/out costa almeno 1 euro, forse di più (anche un paio) contro 0.20 euro di uno shift register. Quindi tornerei all'opzione shift register!

388

Giorno a tutti!
Se non mi sentite è perchè sono influenzato, ma in ascolto!
Non riesco ad accedere al forum domoduino.org: non mi è mai arrivata la conferma di registrazione nè mi abilita l'accesso con UID e PWD!
Ma le discussioni ora dove sono? Su questo forum, su domoduino e poi dove?

Ma quindi adesso la topologia è:

  • un PCB arduino con PIC e shift vari per relè a bordo;
  • schedine sensori (al momento non discusse);
    dal PCB in scatola di derivazione si diramano tutti i cavi 220 per gli attuatori; giusto? Quindi in buona sostanza una rete a stella?
389

Ho alcune domande/osservazioni da porre in merito all'architettura scelta:
1)Secondo me l'idea di usare pic per wDog e ShiftReg è geniale anche se va leggermente a complicare il tutto. Ma, come si dice, chi non risika non rosika!!
Al di là di questo, qualcuno ha pensato ai consumi della scheda? Essendo una scheda che sta sempre accesa, anche se apparentemente assorbe poco, in un mese potrebbe andare a pesare sulla bolletta. Non ho assolutamente idea dell'ordine di grandezza ma immagino che alimentare qualche controllore in più comporti un assorbimento maggiore che realizzare il tutto in HW.
Cmq, al di là che si decida di usare i pic o meno, si potrebbe pensare ad un sistema HW che realizzi lo stand-by automatico tale per cui quando non ci sono uscite attivate, la scheda si porta in una modalità di funzionamento minimale e resta in attesa di un qualsiasi segnale di ingresso che la svegli. Ripeto, sembra una precauzione inutile, ma nessuno vorrebbe una casa che, anche non facendo nulla, consuma energia. L'ho buttata l'ha ma se c'è qualcuno che è in grado di implementare questa funzionalità e il tutto non pesi enormemente sui costi e sulle dimensioni credo sia una cosa utile.

  1. Sarebbe possibile avere sulla scheda un qualche tipo di display (anche minimale) in modo da poter visualizzare informazioni sullo stato generale dell'impianto? So che in ogni momento ci si può collegare col pc e implementare qualsiasi tipo di monitoring si voglia, ma secondo me sarebbe comodo, se non è troppo dispendioso, avere un feedback visuale direttamente sulla scheda. Il display potrebbe anche visualizzare eventuali informazioni di diagnostica relativa all'impianto complessivo e alla scheda stessa.

  2. Qualcuno ha pensato a come gestire i flussi multimediali?? Si pensa di integrare tutto all'interno di arduino o, come credo, utilizzare qualcos'altro?

390

Replico a TEX:

  1. riguardo l'usare un PIC come wDog l'idea sembra resistere, riguardo l'usare un PIC come ShiftRegister, direi che è tramontata per complicazione nella realizzazione. Riguardo lo standby, assolutamente non credo sia un problema! Ciò che assorbe non è il uC, se mai led (che oltre a uno/due di stato non metterei)...e l'assorbimento dell'uC rispetto a componenti discreti non è granchè differente. Se mai si dovrebbe riflettere sull'utilizzo di relè meccanici che assorbono "parecchia" corrente per eccitare la bobina. Bisognerebbe assolutamente pensare a schede di relè a stato solido (Triac) che richiederebbero pochi microampere. Ma il non mettere il dispositivo a bordo di questo PCB ci consente di usare oggi relè meccanici, domani sostituirli con relè a stato solido senza nessuna ulteriore implementazione. Inoltre lo stand-by automatico non può essere gestito...il uC deve essere sempre in ascolto sulle porte di ingresso, o se quando uno vuole accendere una luce esso è in stand-by la luce non si accende!

  2. se vogliamo risparmiare sull'alimentazione, di certo non metterei un display. Inoltre non ci sono sufficienti pin disponibili dell'ATMega per metterlo (ci avevo pensato pure io). Poi: occupa spazio, sarebbe di scarsa utilità (in fondo ci serve cmq un software per interrogare lo stato di salute dell'impianto e dare informazioni dettagliate), i nodi non sono sempre accessibili, anche in tal caso il display sarebbe inutile!

  3. i flussi multimediali condividono lo stesso bus nel caso si sceglie l'ethernet, chi deve gestire tali flussi è l'utilizzatore (o interfaccia utente) i nodi non hanno nessun motivo di interfacciarsi con flussi multimediali. Ma, qualora un domani si integrano nell'impianto delle telecamere IP, si può sempre fare un'interfaccia utente che le visualizzi e contemporaneamente gestisca lo stato dei relè collegati ai nodi...un sistema eterogeneo e integrato.

Rispondo a stefano72:
...sì mi sà che stai parecchio influenzato! :slight_smile: :slight_smile: :slight_smile:
Riguardo domoduino non ti sò aiutare...anzi colgo l'occasione per ricordare che io non potrò frequentare quel forum...non sò perchè il proxy me lo filtra...devo provare a reverse-proxarlo tramite il server di casa, magari cambiando l'url riesco a vederlo...vi farò sapere!

Riguardo il PCB, ti riepilogo, ma sei un po' fuori strada:

  • ATMega328 come uC principale
  • EEPROM I2C esterna per espandere la capacità di memorizzazione della configurazione
  • ATMega168 o PIC come watchdog e gestore reset/output enable
  • 3 shift register serial-in/parallel-out per espandere a 24 uscite con l'impiego di soli 3 pin arduino
  • 3 shift register parallel-in/serial-out per espandere a 24 ingressi con l'impiego di soli 3 pin arduino
  • 3 ULN2803a (array di 8 transistor darlington con 500mA di corrente per ogni uscita in configurazione open-collector) come driver per le bobine dei relè che saranno off-board...esterni...con un connettore probabilmente DB25 per il cablaggio da questa PCB ai relè (ognuno sceglierà i suoi relè, se meccanici o stato solido o una soluzione promiscua)
  • circuito di adattamento per gli input, eventualmente di isolamento o cmq per filtrare eventuali disturbi sul cavo (da studiare e valutare)
  • zoccoli pin strip femmina per garantire compatibilità con gli shield arduino (e quindi inserire l'ethernet shield piuttosto che un qualsiasi adattatore di bus)
  • non ci sarà l'interfaccia FTDI o 8U2, ma una fila di pin strip sulla quale inserire una scheda di interfaccia USB-Serial per la sola programmazione dell'ATMel

...non sò se dimentico dell'altro!

391

Stavo pensando: un RTC non serve ?

392

Io non scrivo nulla ma sono in ascolto anche io!
Secondo me un RTC per ora è inutile a meno che non si vogliano anche azioni programmate, al massimo si possono lasciare dei pin per l'i2c e al massimo aggiungere dopo la schedina

A questo punto un "preventivo" per il costo della scheda?

393

Incredibile...mi è venuto lo stesso dubbio ora che ero al bagno...manco a farlo apposta!

In ogni caso può servire...ma solo se si vuole gestire internamente un orologio. Nel mio caso non serve, perchè la logica "orologio" la gestisco sul supervisore.

Per conoscere quando si è verificato un evento sincronizzo il runtime dell'uC del nodo con il clock dell'orologio e per sapere quando si è verificato un evento faccio la differenza di runtime attuale - runtime precedente e aggiungo la differenza all'offset che c'è tra clock reale e runtime della CPU...forse mi sono spiegato male!

In ogni caso, nel mio nodo non c'è bisogno di sapere l'ora! Invece posso gestire nel nodo funzioni di timer inteso come conto alla rovescia...cioè es. se io voglio una luce accesa per un ora lo posso fare...se io volessi accendere la luce alle 20.00 no, ma semplicemente perchè ci penserebbe il supervisore.

Non ho molta esperienza sugli RTC...di solito sono su bus I2C...si potrebbe anche pensare di inserirlo in parallelo alla EEPROM I2C.

Tra l'altro m'era venuta in mente pure un'altra cosa...ma mi stanno a massacare in ufficio e mi è passata di mente...azzzzzzzz

394

Secondo me converrebbe metterlo l'RTC, o per lo meno predisporlo, così se voglio fare delle luci temporizzate con tempi piuttosto lunghi posso farlo senza usare millis visto che non è molto preciso per applicazioni di questo tipo. Poi se voglio gestire un termostato come faccio senza RTC ? Non posso nemmeno accendere/spegnere la luce esterna ad un certo orario.

395

No ma infatti...come ti dicevo...io gli eventi temporizzati (cioè gestiti proprio dall'ora/minuti/secondi) li faccio gestire al supervisore, perchè non mi andava di implementare la gestione nel firmware del nodo, invece implemento dei comandi temporizzati...es: irriga x 3 minuti (non mi serve di sapere che ore sono, ma solo che devo fare un qualcosaltro tra 3 minuti...e mi è sufficiente appoggiarmi al millis)

396

Buone notizie: schema elettrico quasi ultimato. Lunedi ore 9.15 su skype: vi illustro un po la filosofia e i componenti. Invito aperto a tutti

397

bè a questo punto l'RTC si può installare sulla board principale, che invierà poi i comandi alle periferiche (che quindi non necessitano di RTC)

398

Dunque...

1° ho ricevuto il nuovo ethernet shield. Bisogna assolutamente lasciare libero il pin 4 oltre al 10-11-12-13

2° arduino mini è una figata 20 Euro e hai una schedina veramente piccola standalone

3° stasera ci sarò, ma attenzione a dire "il circuito è quasi finito"...non corriamo, la gatta frettolosa fà i figli ciechi!!! Bisogna assolutamente studiare bene l'interfaccia elettrica di input...se indurire con delle resistenze di pull-up specifiche o isolare galvanicamente con opto-isolatori

4° ovviamente prima di mandare in stampa il tutto, deve essere provato ogni singolo componente del sistema su proto-board! Io ho provato a combattere con il pic12f675 regolarmente ricevuto da robot-italy...ma non è così semplice programmarlo!

5° io sono sempre per l'output enable gestito dal PIC con una resistenza di pull-up/down (non ricordo) per garantire la disabilitazione degli ingressi in fase di start-up

6° dobbiamo pure studiare come fare l'alimentazione del tutto...cioè io metterei un regolatore a bordo (tipo 7805 o qualcosa del genere)...sostanzialmente io metterei come input la 12v (o 13,8 come nel mio caso)...insomma una tensione da 7 a 20v (come Arduino) e di conseguenza gestirei la doppia alimentazione on-board. Quindi, a blocchi sarebbe: alimentatore -> nostra PCB; nostra PCB -> relè! Forse non mi riesco a spiegare benissimo! :slight_smile:

7° dobbiamo ricordarci di:

  • condenstori elettrolitico 100uF e poliestere 100.000pF di filtraggio alimentazione sono FONDAMENTALI e vanno messi nei pressi dei chip TTL
  • condensatore elettrolitico 1uF tra il latch degli shift register di output e massa
  • resistenza da 10kohm tra il pin reset dell'ATMel e positivo e microswitch tra reset e massa (oltre che il reset deve ovviamente andare verso un pin del PIC)
399

2° arduino mini è una figata 20 Euro e hai una schedina veramente piccola standalone

mini o pro mini?
Le Pro Mini costano un pochino meno (15 eur).
Ho visto svariati progettini basate su board con la Pro Mini (invece del solo ATMega); da questo punto di vista sto facendo degli esperimenti.

Non ho avuto modo di seguire nè il forum nuovo costituito nè le conference call su Skype, quindi son male informato, ma nelle board che si stanno delineando c'è il solo ATMega o la soluzione è "ibrida" e quindi c'è una Arduino (Pro) Mini?

400

Solo l'ATMega ma con compatibilità shield arduino...