Go Down

Topic: Domotica con Arduino (Read 76 times) previous topic - next topic

amedeo

la soluzione del pic al posto del secondo atmel anche secondo me risulta più pulita, per la questione dello shift register si potrebbe sentire la voce della comunità... qualcuno riesce ad illustrare vantaggi svantaggi delle soluzioni proposte?

astroz78

#376
Nov 10, 2010, 02:23 pm Last Edit: Nov 10, 2010, 02:23 pm by astroz78 Reason: 1
ragazzi io l'ho buttata là è...non ho assolutamente le idee chiare...anzi! Dovremmo cmq fare delle prove su breadboard e studiare bene gli "stati certi"...cioè che in fase di start-up non ci siano situazioni non definite con certezza!

Ragioniamo...pensiamo...intanto io ho ordinato un 12F675...lo avrò tra un paio di giorni...se ho la capoccia che funziona nel week-end ci butto dentro un occhio!

Tra l'altro devo assolutamente mettere in piedi la gestione della caldaia...qui inizia a fà freddo! :)
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

Simo89

se ci basta anche il PIC come WD benvenga, risparmiando qui poi abbiamo budget in caso di complicazioni non previste ;)

per quanto riguada il PIC come SHIFT, passo perchè non sono all'altezza ;)

astroz78

Dunque come software da buttare su un PIC per fargli fare la stessa funzione di uno shift register non ci vuole nulla...forse è + complicato fargli fare da watchdog...

...però bisogna verificare alcune questioni: es. lo stato dei pin di uscita in fase di startup fin quando il sistema non è "online"...
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

astroz78

Per il watchdog ci basterebbe pure il pic12f629 che costa 0,78 iva inculsa! :D
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

astroz78

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!
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

Ambrogio

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

astroz78

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.
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

LukeSkyChopper

#383
Nov 10, 2010, 06:58 pm Last Edit: Nov 10, 2010, 07:02 pm by lucariello Reason: 1
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


Ambrogio

@ 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

astroz78

@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
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

astroz78

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!
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

stefano72

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?

Tex

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.

2) 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.

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

astroz78

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! :) :) :)
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!
OpenDomotica ...la domotica con Arduino - www.opendomotica.it

Go Up