Ciao,

certo, essendo un aspetto di dettaglio ti invito a spostarti sul forum del progetto (il nuovo su g group) in modo da vedere quale possa essere il problema.

Saluti,
Dario.

Ciao,

per partire fatti un giro sul wiki di Souliss (domani esce la nuova versione) per iniziare a capire cosa puoi realizzare e come, se hai domande generali puoi farle direttamente qui, se sono di dettaglio è meglio inserirle sul forum di Souliss.

In relazione alla tua domanda, la risposta è NI. La DINo supporta la connessione in RS485, puoi quindi utilizzare i moduli a relé di KMTronic per espandere il numero di relé, KMTronic dovrebbe aver diffuso degli esempi di utilizzo, perché in Souliss non è attualmente supportata l'estensione via RS485 dei relé, ma dovrebbe essere semplice realizzarla.

Sul sito trovi tutto l'hardware supportato, così puoi decidere come muoverti.

Saluti,
Dario.

Non riesco a trovarlo, ma è da qualche parte sul forum italiano.

Vanno bene I2C o la seriale, ma I2C è master/slave quindi va bene solo se uno solo dei due nodi deve effettuare la richiesta dati (altrimenti diventa leggermente più complessa la gestione), la seriale è punto-punto (ma solo tra due punti) quindi i nodi sono equivalenti.

Saluti,
Dario.

Grazie a tutti per le risposte.
@veseo, sicuramente opterò per la soluzione cablata, vivere in un ambiente pieno di radiazioni non mi piace per nulla.
Pensa che a casa non ho neanche il wifi(lo attivo solo se mi serve veramente). Lo so che vivamo in un mondo pieno di radiazioni, ma se riesco a limitarle è meglio. Sai com'è non è vero ma ci credo. 

Fai bene

English isn't mine

First step is to have a look to the official SPI drivers and port your code using that drivers instead of the one included in Ethercard (or any other that you are using), then look if you have still compilation errors and move forward.

Regards,
Dario.

Le scelte sono diverse per tali distanze e possono essere sia cablate, sia senza fili. Tra quelle cablate ci sono due macro possibilità:
- Seriale basata su RS-485
- Seriale basata su Ethernet

La prima ha come vantaggio intrinseco la possibilità di realizzare un bus di comunicazione, riducendo la lunghezza complessiva del cablaggio. Lo svantaggio è che richiede un protocollo master/slave o la gestione delle collisioni in software se serve un peer-to-peer.

La seconda ha come vantaggio la gestione in hardware delle collisioni, ma richiede generalmente una maggiore lunghezza del cablaggio perché l'architettura è una stella (con centro l'hub o lo switch).

Le soluzioni senza filo sono diverse, anche qui ci sono due famiglie da dividere per frequenze:
- Transceiver a 2.4 GHz
- Transceiver a 900 MHz

I primi sono più economici e diffusi (anche in termini di librerie) ma hanno una portata minore, in linea generale possono rientrare nei 30 metri, ma dipende molto dalla disposizione.

I secondi hanno una portata maggiore, ma sono attualmente meno usati in ambito DIY e quindi c'è minore disponibilità di librerie software.

Esistono anche radio a 433 MHz, ma il discorso è un poco più complesso, normalmente sono delle trasmittenti e riceventi pure ed in termini astratti sono una sorta di RS-485 senza fili, c'è da considerare il duty massimo di trasmissione e sopratutto non essendo un tranceiver vero rende le cose leggermente più complesse nella gestione (ad esempio la gestione della modulazione in trasmissione va fatta in software). Qualche libreria anche per questi c'è.

Se l'obiettivo è la domotica nel senso classico (relé ed ingressi) e ti interessano le soluzioni senza fili, puoi dare un occhio ai prodotti di AirQ Networks. Sono delle schede con transceiver 433 MHz (quindi è tutto gestito in hardware) con relé ed ingressi optoisolati, raggiungibili con una shield.
In questo caso puoi realizzare un nodo centrale da cui controllare tutte queste periferiche remote.

Se ti interessano soluzioni più flessibili, puoi dare un occhio ai prodotti Olimex, dove trovi transceiver per Ethernet, 2.4 GHz e 900 MHz ed anche RS-485.

Saluti,
Dario.

Basically only official sketches that runs over Arduino UNO can run directly (or with few effort) on Arduino DUE, this because the Arduino core (the libraries) was migrated for the ARM CPU used in the DUE. Every other Arduino sketch won't run without a porting.

Some non-official Arduino sketches that runs UNO may run also on DUE, it depends if they are based on custom libraries or if are based only on the Arduino core, in the latter case it should run. The EtherCard library has an its own SPI driver (doesn't use the Arduino ones) and this is creating your problems.

I've never been in detail with ARM, so I don't know if there are others to be considered. As minimum you need to review all pins assignment and all direct access to register and interrupts, it should be not so hard, because the library doesn't use a lot of those.

I can try to help if you want.

Regards,
Dario.

Se non ricordo male, circa un anno fa venne rilasciata una semplice liberia per condividere le variabili tra due schede. Utilizzava la comunicazione seriale, che vista la comunicazione tra due estemi di una bici, dovrebbe andare bene.

Era molto semplice, partiva dal presupposto di dichiarare le variabili in due sketch in modo da avere gli stessi indirizzi assoluti e poi sincronizzava i valori da un master verso uno slave. Se trovo il link (era sul forum) lo inserisco, però per funzionare serve che ci sia lo stesso microcontrollore da entrambi i lati.

Saluti,
Dario.

Per riuscire prova ad astrarre il concetto di comando, in pratica, fai in modo che qualsiasi comando (da pulsante, BT, ...) venga tradotto in un valore assegnato ad una variabile, ad esempio impostandola ad 1. Se la variabile assume valore 1, accendi il LED, se assume valore 2 lo spegni.

Ci sono soluzioni più eleganti, ma questa è sufficientemente semplice per aggirare l'ostacolo.

Saluti,
Dario.

Ciao,

i controller IR non sono adatti per seguire il ritmo della musica per due motivi: il primo è nel numero ridotto di colori disponibili; il secondo è il tempo necessario ad inviare un comando.

Per far andare i led a ritmo di musica la strada è quella di analizzare il flusso audio (FFT) ricavando le ampiezze associate alle frequenze che compongono la canzone ascoltata, da li quelle informazioni vanno tradotte in colore. Una strada semplice è quella di raggruppare le frequenze in tre insiemi (bassi, medi, alti) ottenendo tre indici da normalizzare, con questi si può guidare il PWM delle tre componenti R, G e B.
Se i led sono monocolore, si ci può concentrare su uno dei gruppi, in base alla canzone ascoltata può avere senso concentrarsi sui bassi o sugli alti.

Di seguito un paio i video in cui abbiamo realizzato quanto descritto sopra, la FFT viene fatta direttamente dall'applicazione Android, che poi invia un flusso dai UDP verso la scheda che controlla i LED.

https://www.youtube.com/watch?v=3b95QNQGBcM

https://www.youtube.com/watch?v=92A-zQTPEXc

https://www.youtube.com/watch?v=h4rplJ4agp4

https://www.youtube.com/watch?v=dmJi2kUsDF0

In uno di questi video viene utilizzato il controller MOD-RGB di Olimex, che ha come funzionalità (ma non l'ho mai usata) la cattura audio da attraverso un connettore presente sulla scheda. E' limitata ai soli bassi, ma non richiede alcun software lato PC, Tablet o Smartphone.

Saluti,
Dario.

Il lavoro per l'integrazione dell'hardware prodotto da Olimex è praticamente terminato, nella nuove versione verranno aggiunti i driver per MOD-RGB e MOD-IO. Di seguito alcuni video che mostrano brevemente alcune funzionalità implementate con queste schede.

A Relay WiFi node controlled via Android application and/or Modbus TCP
https://www.youtube.com/watch?v=04xzJ3MDz3k

A simple network of two nodes, a relay one and an RGB LED controller with p2p interaction
https://www.youtube.com/watch?v=92A-zQTPEXc

The same RGB LED controller driven by the music played by the smartphone via FFT
https://www.youtube.com/watch?v=3b95QNQGBcM

Saluti,
Dario.

The project is ongoing, here some videos of the integration with Olimex's hardware

A Relay WiFi node controlled via Android application and/or Modbus TCP
https://www.youtube.com/watch?v=04xzJ3MDz3k

A simple network of two nodes, a relay one and an RGB LED controller with p2p interaction
https://www.youtube.com/watch?v=92A-zQTPEXc

The same RGB LED controller driven by the music played by the smartphone via FFT
https://www.youtube.com/watch?v=3b95QNQGBcM

Enjoy,
Dario.

QUETSO!  -----> Fixed malloc bug  <------ è il vero bug fix della versione

Opinione personale, usare la malloc su un sistemino basato su una modesta mcu 8 bit con 2k di ram è come pestarsi le dita con una mazza da 5 kg 

Non si può non condividere

Dipende tutto da come vengono gestite le socket, cioé a cosa viene fatto nella libreria Ethernet di Arduino. Nel caso a cui faccio riferimento, le socket sono gestite in modo diretto e non abbiamo riscontrato problemi, c'è un installazione h24 da più di 6 mesi basata su Freakduino Chibi ed Arduino Ethernet.

Non ho messo un link diretto alla libreria Souliss solo perché ne ho parlato anche altre volte, però il sito internet da cui poter effettuare i download è nella mia firma o può essere raggiunto su SourceForge.

Saluti,
Dario.