gioscarab:
Ciao ragazzi, a me quello a cui state pensado sembra veramente quello che fa Firmata.
Spezzo una lancia perché sto cercando di capire cosa è più utile per le mie personali necessità.
Inizialmente si, c'era "solo" il comando dei singoli pin, poi è arrivata la lettura/scrittura su array remoti (simil Modbus?), ed infine l'esecuzione di callback remote (simil Pjon?), che come giustamente fai notare, avvia sull'unità remota funzioni specifiche (lanciate da un array di puntatori a funzione, e quindi senza necessità di parsing).
Ogni libreria ha una sua filosofia ben specifica, che la rende adatta per determinati casi e un overkill per altri. Credo che non possa esistere alcuna libreria universale che possa andare bene per tutto e per tutti.
Il particolare la filosofia di questa è espressa nei primi due post, e mi sembra sintetizzabile in: non occuparsi mai (a livello di applicazione finale) dei messaggi scambiati (a cui si può aggiungere accidentalmente un occupazione risorse minima), e non dover mai scrivere/codificare messaggi espliciti (anche se poi il richiamo di una callback tramite un indice rende quell'indice un messaggio implicito, ma è solo un numero, non qualcosa da codificare in partenza e parsare all'arrivo).
Detto ciò capisco che, essendo ogni comunicazione è un'operazione atomica specifica, gli utilissimi messaggi broadcast trovano difficile (se non impossibile) implementazione . Non ci possono essere "messaggi raw" che solo gli interessati prendono in considerazione, a meno di snaturare la filosofia detta prima, introducendo appunto i messaggi raw.
Un altro limite attuale (sto pensando all'aggiornamento di valori negli array remoti) è poter trattare un solo byte per trasmissione. Se, come nel Modbus, si potessero trasmettere/leggere N byte al colpo (vale anche per le callback), le potenzialità aumenterebbero di molto, e, credo, non si toccherebbe la filosofia iniziale.
Un'ultima cosa, che devo trovare il tempo di approfondire tra un impegno e l'altro, è vedere se il loop resta sempre libero anche durante le transazioni, questo per me sarebbe importante.
Infine, già che ci sono, il carattere di controllo lo renderei appena appena un po' più sicuro (limitando gli effetti negativi della proprietà commutativa della somma):
char remotocontrollo(char messaggio[])
{
// restituisce il carattere di controllo per il messaggio in ingresso
// una cosa semplice, non troppo elaborata
byte appoggio = 0;
byte index = 0;
while (messaggio[index])
{
appoggio = ((appoggio >> 1) | (appoggio << 7)) ^ messaggio[index++];
}
return (char)(appoggio % 93) + 33;
}
Io su un canale potenzialmente disturbato non mi fiderei neppure di un CRC8. Ma un checksum volgare era proprio andarsi a cercare guai.