Ciao a tutti.
Colgo l'occasione di fare gli auguri a tutti per presentare un progettino ancora decisamente embrionale, ma che sembra essere compatibile con quanto ho letto finora in questo thread.
Al momento sto lavorando su uno shield per la domotica che contiene:
- 2 AT24C1024 (sono troppe, ma le avevo ... e volevo sperimentare un po' I2C)
- 1 RTC, al momento è un DS1307 con batteria ma preferirei usare un PCF8563 per via dell'interrupt e dei timer
- 1 sottosistema CANBUS (MCP2515+MCP2551)
- 1 termostato DS1621
L'idea dovrebbe essere quella, almeno in prima approssimazione, di avere un Arduino come centrale e dei nodi remoti basati su MCP25050 (CANBUS EXTENDER 8 GPIO, 4 Input Analogici, 2 uscite PWM) e relativo transceiver MC2551 per la gestione di sensori e attuatori (al momento la questione "nodi remoti" è ancora molto in fase TBD perché da una prima analisi il MCP25050 non pare sia programmabile in modo non volatile per cui potrebbe richiedere un suo MICRO, il che aprirebbe a sistemi ad intelligenza distribuita).
Comunque il mio "sogno" rimane comunque di avere un sistema che abbatta al massimo i cablaggi consentendo di viaggiare ove possibile con solo un quadripolare e i due cavi della 220V, installando i nodi sul fondo di comuni cassette da incasso e preparando dei nodi adattabili alle varie esigenze (sei pulsanti e un relay, quattro relay, otto pulsanti, ..., nella maniera più modulare possibile).
La parte più complessa è il software da installare su Arduino per gestire il tutto. L'idea sarebbe quella di implementare un interprete di comandi che permettesse di programmare l'AVR una sola volta, indipendentemente da quali siano le programmazioni dell'impianto domotico che verremmo ad installare.
Partiamo dal protocollo di comunicazione: va benissimo quello definito da Ambrogio a lunghezza fissa di 10 Byte (la lunghezza fissa mi è molto utile in programmazione).
A dire il vero avrei preferito tentare di usarne uno esistente magari open (ad esempio Velbus) che ci apriva all'utilizzo di componentistica esistente di terze parti, garantendo al progetto maggiori probabilità di successo, ma, visti i costi, direi che vada benone anche così.
Il protocollo di Ambrogio andrebbe espanso considerandolo un linguaggio di programmazione più che un protocollo di comunicazione.
Ammettiamo che il primo byte del protocollo di Ambrogio non sia fisso a 0xF0, ma che 0xF0 sia il comando "invia messaggio", alla ricezione di un messaggio Arduino dovrebbe passarlo ad una funzione che lo confronta con una tabella di accettazione (stile firewall Iptables, se qualcuno ci ha lavorato) e ritorna un intero che è l'indirizzo del comando da eseguire. La tabella di accettazione andrebbe salvata sulla EEPROM, diciamo nei primi 100 Byte.
I comandi risiedono anch'essi nella EEPROM e sono tutti di 10 Byte, per cui se la funzione ritorna, a titolo di esempio, 42, e la tabella comandi segue nella EEPROM la tabella di accettazione, AVR leggerà i 10 Byte che partono dall'indirizzo 520 (100+42*10) poi eseguirà quanto indicato, leggendo poi (ed eseguendo) i comandi presenti agli indirizzi 530, 540, 550, ... fino al raggiungimento di un comando di "STOP".
A questo punto abbiamo 255 possibili comandi (ricordando che "0xF0", potrebbe essere "invia messaggio"), tra cui dovremo decidere "GET MESSAGE", "STORE MESSAGE", "STOP", "BRANCH", "ACCEPT MESSAGE" (con le wildcard per la creazione della tabella di accettazione), ecc.
La parte che vedo più critica al momento è la gestione delle interruzioni soprattutto nelle operazioni lunghe (ad esempio la gestione di un cancello: se debbo attendere un minuto per chiudere non posso bloccare il tutto in attesa che sia passato il minuto, nè penso facile programmare "in concorrenza" su AVR).
Si dovrà definire o uno stack di comandi o delle interruzioni basate su timer AVR o (anche) su RTC (per questo preferivo il PCF8563 che ha un proprio interrupt).
Come dicevo più che un progetto sono "idee in libertà".
Mi piacerebbe avere la vostra opinione.
Ancora un augurio di un felicissimo Natale e un fantastico Anno Nuovo.
TT: