Citazione:
Originalmente inviato da Davide B.  Io dell'ACK di ritorno me ne fregherei bellamente prevedendo un'istruzione di "polling" che, chiamata periodicamente, mi dica se l'arduino è vivo o meno, eventualmente inserendo un byte di crc, che risponda picche quando il crc fallisce.
Credo che per strutturare decentemente la comunicazione sia necessario avere un elenco delle informazioni da trasmettere, ad esempio l'indicatore di canale ed informazione di posizione(?)
E poi è necessario avere idea di quante volte devono essere rinfrescate ogni secondo queste informazioni, nonchè del jitter massimo accettabile... ad esempio in windows puoi schedulare delle operazioni fino al millisecondo, anche se con tecniche piuttosto particolari (se hai bisogno chiedi pure), come pure bisogna prevedere di lavorare su più thread per non tenere le varie interfacce utente occupate (idem come sopra se hai bisogno di aiuto)
Avute queste informazioni un primo abbozzo di protocollo credo verrà da se. |
Riguardo al protocolo, perche no prevedi di implementare in arduino un protocollo documentato tipo il DSM2 o il PXX frsky ?
La logica che ti vorrei suggerire è la seguente:
partendo dall'assunto che tu voglia generare un treno di impulsi PPM per comandare un modulo tu vuoi comandare in seriale un'arduino per fargli generare il PPM.
Se tu usassi come protocollo arduino/pc un protocollo standard seriale tipo il DSM/DSMX dei moduli della DX4/DX5 o il PXX frsky, potresti pensare di evitare, in un futuro, arduino, utilizzandolo solo come interfaccia di compatibilità per altri tipi di moduli.
A volte reinventare la ruota non conviene.
La regolazione dei trim non la farei calcolare ad arduino ma la includerei in modo trasparente.
Se hai bisogno di documentazione su quei protocolli chiedi pure.