Qualcuno sperimenta con Arduino?

[faustog_2]

ciao romoloman

se ti riferisci alle applet, concordo pienamente.. altrimenti il discorso VM, va detto che queste devono essere aggiornate.. se prendo un sistema configurato con una Java Virtual Machie di 10 anni fa è logico che non posso sfruttare le nuove caratteristiche.. poi non credo che alla Oracle siano così pazzi da utilizzare una soluzione scarsa! anzii c'è da dire che la Oracle è al vertice delle software-house ..tieni conto che Open Office è fatto in java così come gli IDE di Arduino e delle schede KK basate su ATMega 168 ecc..

va be chiudiamo qui, rispetto la tua opinione, perchè vedo che siamo entrati in loop!!
fausto

Originalmente inviato da romoloman

Scusa ma credo di aver programmato in java per 10 anni e proprio non va...
Incompatibilità fra macchine virtuali, fra diverse versioni dello stesso produttore, tempi di loading pazzeschi, utilizzo di risorse spropositato, ogni volta era una lotta: Era nato per essere portabile e invece non ti puoi neanche permettere di fare upgrade di sicurezza che ti si pianta l'applicazione che funzionava correttamente due versioni prima.

Tutte le caratteristiche che hai elencato del java i C++ ce le ha.

Comparison of Java and C++ - Wikipedia, the free encyclopedia

e ne ha anche qualcuna in più tipo l'aritmetica unsigned.
Tutti gli esempi che trovi di arduino sono in C/C++

Scusa la franchezza ma quando dici che i tecnici di arduino si sono orientati su java, si lo hanno fatto sull'interfaccia, ma tutto il resto è programmato in C.
Che le QT siano obsolete, bah contento tu.... mai vista tanta sicumera.
Saluti

[romoloman]

Originalmente inviato da faustog_2

ciao romoloman

se ti riferisci alle applet, concordo pienamente.. altrimenti il discorso VM, va detto che queste devono essere aggiornate.. se prendo un sistema configurato con una Java Virtual Machie di 10 anni fa è logico che non posso sfruttare le nuove caratteristiche.. poi non credo che alla Oracle siano così pazzi da utilizzare una soluzione scarsa! anzii c'è da dire che la Oracle è al vertice delle software-house ..tieni conto che Open Office è fatto in java così come gli IDE di Arduino e delle schede KK basate su ATMega 168 ecc..

va be chiudiamo qui, rispetto la tua opinione, perchè vedo che siamo entrati in loop!!
fausto

Il problema non è aggiornare la VM è dover aggiornare le applicazioni che hai sviluppato per i clienti e che non funzionano più dopo l'aggiornamento della VM.
LibreOffice/OpenOffice hanno una minima parte scritta in Java ed è principalmente la parte legata al JDBC/OfficeBasic che è più portabile dispetto all'ODBC il resto è sacrosanto C++ come puoi facilmente verificare guardando i sorgenti e controllando le librerie linkate:

ldd /usr/lib64/libreoffice/program/soffice.bin
        linux-vdso.so.1 =>  (0x00007fffd05ff000)
        libuno_sal.so.3 => /usr/lib64/libreoffice/program/../basis-link/ure-link/lib/libuno_sal.so.3 (0x00007f9fd5c08000)
        libsofficeapp.so => /usr/lib64/libreoffice/program/../basis-link/program/libsofficeapp.so (0x00007f9fd5999000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f9fd568f000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f9fd5438000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9fd5222000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f9fd4e92000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f9fd4c8e000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9fd4a71000)
        libcomphelpgcc3.so => /usr/lib64/libreoffice/program/../basis-link/program/libcomphelpgcc3.so (0x00007f9fd46fd000)
        libuno_cppuhelpergcc3.so.3 => /usr/lib64/libreoffice/program/../basis-link/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 (0x00007f9fd4430000)
        libuno_cppu.so.3 => /usr/lib64/libreoffice/program/../basis-link/program/../ure-link/lib/libuno_cppu.so.3 (0x00007f9fd41f4000)
        libdeploymentmisclx.so => /usr/lib64/libreoffice/program/../basis-link/program/libdeploymentmisclx.so (0x00007f9fd3fcf000)
        libi18nisolang1gcc3.so => /usr/lib64/libreoffice/program/../basis-link/program/libi18nisolang1gcc3.so (0x00007f9fd3dc8000)
        libsfxlx.so => /usr/lib64/libreoffice/program/../basis-link/program/libsfxlx.so (0x00007f9fd3780000)
        libsvllx.so => /usr/lib64/libreoffice/program/../basis-link/program/libsvllx.so (0x00007f9fd3469000)
        libsvtlx.so => /usr/lib64/libreoffice/program/../basis-link/program/libsvtlx.so (0x00007f9fd2df2000)
        libtklx.so => /usr/lib64/libreoffice/program/../basis-link/program/libtklx.so (0x00007f9fd2771000)
        libtllx.so => /usr/lib64/libreoffice/program/../basis-link/program/libtllx.so (0x00007f9fd24bb000)
        libucbhelper4gcc3.so => /usr/lib64/libreoffice/program/../basis-link/program/libucbhelper4gcc3.so (0x00007f9fd2242000)
        libutllx.so => /usr/lib64/libreoffice/program/../basis-link/program/libutllx.so (0x00007f9fd1ef8000)
        libvcllx.so => /usr/lib64/libreoffice/program/../basis-link/program/libvcllx.so (0x00007f9fd182d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9fd5e68000)
        libuno_salhelpergcc3.so.3 => /usr/lib64/libreoffice/program/../basis-link/program/../ure-link/lib/libuno_salhelpergcc3.so.3 (0x00007f9fd1626000)
        libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x00007f9fd12aa000)
        libxcrlx.so => /usr/lib64/libreoffice/program/../basis-link/program/libxcrlx.so (0x00007f9fd0ffd000)
        libfwelx.so => /usr/lib64/libreoffice/program/../basis-link/program/libfwelx.so (0x00007f9fd0d56000)
        libsaxlx.so => /usr/lib64/libreoffice/program/../basis-link/program/libsaxlx.so (0x00007f9fd0b3c000)
        libsblx.so => /usr/lib64/libreoffice/program/../basis-link/program/libsblx.so (0x00007f9fd0753000)
        libsotlx.so => /usr/lib64/libreoffice/program/../basis-link/program/libsotlx.so (0x00007f9fd04f3000)
        libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f9fd0195000)
        libbasegfxlx.so => /usr/lib64/libreoffice/program/../basis-link/program/libbasegfxlx.so (0x00007f9fcfec9000)
        libicuuc.so.46 => /usr/lib64/libicuuc.so.46 (0x00007f9fcfb7a000)
        libjvmfwk.so.3 => /usr/lib64/libreoffice/program/../basis-link/program/../ure-link/lib/libjvmfwk.so.3 (0x00007f9fcf95d000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007f9fcf711000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f9fcf4f9000)
        libi18npaperlx.so => /usr/lib64/libreoffice/program/../basis-link/program/libi18npaperlx.so (0x00007f9fcf2f3000)
        libi18nutilgcc3.so => /usr/lib64/libreoffice/program/../basis-link/program/libi18nutilgcc3.so (0x00007f9fcf0df000)
        libicule.so.46 => /usr/lib64/libicule.so.46 (0x00007f9fceeaa000)
        libjvmaccessgcc3.so.3 => /usr/lib64/libreoffice/program/../basis-link/program/../ure-link/lib/libjvmaccessgcc3.so.3 (0x00007f9fceca4000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f9fcea18000)
        libfwilx.so => /usr/lib64/libreoffice/program/../basis-link/program/libfwilx.so (0x00007f9fce7e6000)
        libicudata.so.46 => /usr/lib64/libicudata.so.46 (0x00007f9fcd768000)

Rispetto la tua opinione, ma non la condivido, non posso condividerla avendone fatto un uso professionale e avendoci smadonnato dietro per anni.

[Davide B.]

tieni conto che Open Office è fatto in java così come gli IDE di Arduino e delle schede KK basate su ATMega 168

faustog_2, visto che tu sai tutto spiegami come mai l'Atmel Studio 6, che sarebbe l'IDE rilasciato da Atmel per gli AVR e per gli ARM, insomma, quello ufficiale (che comunque ha come base compilatore il GCC) è stato sicuramente scritto in .NET, anzi, gira nella Visual Studio 2010 shell... Quelli di atmel vanno a letto con bill gates stesso?
Ho ricevuto uno sfottò gratuito sul fatto che fossi il figlio di Bill Gates mentre volevo solo portare quella che è la mia esperienza, continui ad asfaltare i cabasisi con Java... manco fossi pagato dalla Oracle o dalla Apple.
Se IO ho provato Java e l'ho trovato IMPRODUTTIVO in confronto ad altri linguaggi di programmazione tipo il VBNET (ammesso che si possa ancora chiamare tale quello che uso io), credo che con qualche migliaio di software installati in 5 lingue ed in 7 paesi posso anche avere le mie ragioni, visto che all'anno spendo quasi 7000 euro in licenze, anche per avere un supporto pagato che risponda IN ORE e non scrivendo su forum dove il primo che si crede di sapere tutto mi spara la sua str... inutile.
Ieri sera ho installato su un PC di un mio cliente una demo di un programma che sto scrivendo... 55 mega... compresi aggiornamenti automatici, teleassistenza, sistema di diagnosi remota, logging, insomma un ecosistema enterprise di quelli seri.
Quanto ci avrei messo a farlo in JAVA? Ammesso che certi sistemi esistano in JAVA (di questo non sono sicuro)
Se romoloman ha lottato 10 anni con il java per poi abbandonarlo certamente avrà avuto le sue buone ragioni. Non ho motivo di dubitare che non sia un cantinaro, ma un professionista (ed anche di quelli bravi).
Se uno mi dice che lavoro in java, certamente non lo sfotto, se si trova bene sono contento per lui.
Peraltro mi sembra che questa discussione stia andando fuori tema per cui non replicherò ulteriormente. Non intendo perdere tempo.
Ritornando in tema.

nel mio caso specifico trasmetto da un pc un insieme di pacchetti ad arduino, che si occuperà poi di convertire le mie istruzioni in segnali PPM.
Si tratta quindi di inviare i dati legati a diversi canali.
La comunicazione è a senso unico, arduino non ha nulla da dirmi di "interessante" se non darmi l'ack della ricezione del pacchetto.
e qui sorgono le prime domande:
ma come strutturo l'informazione?
devo specificare un id canale e un valore da convertire.
e che valore scelgo?
in che formato?
e la regolazione dei trim? la includo in maniera trasparente?
e preventivo un id univoco per i pacchetti?
e cosa faccio con i pacchetti non sincronizzati? li reinvio o li ignoro?

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.

[romoloman]

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.

[faustog_2]

ciao davide.. non io volevo sfotterti, hai scambiato un espressione scherzosa, leggera, in una pesante accusa. Se a me mi dicessero che sono figlio di Bil Gates, mi farei una risata.. Mi dispiace che tu sia così suscettibile. Chiudo anch'io questo ping pong

E comunque non siamo fuori discussione, perchè L'IDE di Arduino è realizzato in Java.

Per il protocollo PPM tra PC e Micro, ho realizzato un sistema che prevede l'invio dei dati per ordine di poszione, per sicurezza dall'applicazione tra un dato e l'altro passano 20 mS... il firmware posizionerà in un buffer i dati secondo l'ordine d'arrivo, piuttosto che [posizione, valore] questo ha senso soprattuto se i canali sono pochi , 4 per esempio.

Originalmente inviato da Davide B.

faustog_2, visto che tu sai tutto spiegami come mai l'Atmel Studio 6, che sarebbe l'IDE rilasciato da Atmel per gli AVR e per gli ARM, insomma, quello ufficiale (che comunque ha come base compilatore il GCC) è stato sicuramente scritto in .NET, anzi, gira nella Visual Studio 2010 shell... Quelli di atmel vanno a letto con bill gates stesso?
Ho ricevuto uno sfottò gratuito sul fatto che fossi il figlio di Bill Gates mentre volevo solo portare quella che è la mia esperienza, continui ad asfaltare i cabasisi con Java... manco fossi pagato dalla Oracle o dalla Apple.
Se IO ho provato Java e l'ho trovato IMPRODUTTIVO in confronto ad altri linguaggi di programmazione tipo il VBNET (ammesso che si possa ancora chiamare tale quello che uso io), credo che con qualche migliaio di software installati in 5 lingue ed in 7 paesi posso anche avere le mie ragioni, visto che all'anno spendo quasi 7000 euro in licenze, anche per avere un supporto pagato che risponda IN ORE e non scrivendo su forum dove il primo che si crede di sapere tutto mi spara la sua str... inutile.
Ieri sera ho installato su un PC di un mio cliente una demo di un programma che sto scrivendo... 55 mega... compresi aggiornamenti automatici, teleassistenza, sistema di diagnosi remota, logging, insomma un ecosistema enterprise di quelli seri.
Quanto ci avrei messo a farlo in JAVA? Ammesso che certi sistemi esistano in JAVA (di questo non sono sicuro)
Se romoloman ha lottato 10 anni con il java per poi abbandonarlo certamente avrà avuto le sue buone ragioni. Non ho motivo di dubitare che non sia un cantinaro, ma un professionista (ed anche di quelli bravi).
Se uno mi dice che lavoro in java, certamente non lo sfotto, se si trova bene sono contento per lui.
Peraltro mi sembra che questa discussione stia andando fuori tema per cui non replicherò ulteriormente. Non intendo perdere tempo.
Ritornando in tema.

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.

[Davide B.]

hai scambiato un espressione scherzosa, leggera, in una pesante accusa.

Ok. Lasciamo perdere.
Riguardo alla comunicazione, se non ci sono problemi di velocità preferisco andare "a palla" anche perchè le latenze del bus usb non sono mica tanto da ridere (pensa che nel mio stack usb la seriale virtuale viene impostata "di default" a 115200... Ed è da ridere quando, lato micro, il PC tenta di aprirla a 9600 e lo stack gli risponde... OK, io mi apro a 115200), per cui normalmente, lato pc winzozz utilizzo alcuni accorgimenti particolari per bypassare i limiti dello scheduler.
Questo perchè anche se l'arduino non è mostruosamente lento come le netduino non è che sia poi un fulmine (almeno per il mio metro di paragone)

[riki1681]

la soluzione con ponte frksy/ppm (quindi un modulo frsky che trasmette a una rx frsky, prendendo un input di segnali ppm generati da arduino che a sua volta prende dal pc i valori e li converte) è una scelta di velocità ed economia.

il software richiede al massimo qualche oretta per lo sviluppo (lato arduino e lato pc), e ho un range di 1,5km spendendo meno di 40 sterline.

ed effettivamente funziona tutto e bene.

sparo una stringa con valori separati da punto e virgola e fine riga con il carattere ascii 10 (\n o vblf o linefeed, o come lo volete chiamare)

arduino attende il fine riga,
legge la stringa e memorizza i valori

ogni 22ms un interrupt richiama una funzione che genera il treno di impulsi ppm, nulla più di una serie di high e low sul pin che va alla tx frsky, di durata variabile in base a quello che invio dalla seriale del pc.

questo richiede una 50ina di righe di codice lato arduino e altrettante lato pc (compresa la lettura dei valori da un joystick collegato al pc)

sinceramente non so quanto invece cubi in termini di tempo implementare uno dei protocolli "seri" che vengono utilizzati da marche che fanno tx/rx.

per quello pensavo di fare un protocollo "light"
e che, magari in futuro, mi permetta, lato pc, di pilotare più tx, tramite le varie uscite di arduino.

poi le mie erano esempi di considerazioni sul perché dare attenzione al messaggio più che a come si invia, non tanto quesiti su come fare un protocollo.
ad ora una stringa di testo svolge egregiamente questa funzione mentre le logiche sono gestite dal pc.
arduino si occupa solo di tenere sotto controllo i valori massimi dei comandi che riceve, in modo da non inviare segnali malformati in caso di comunicazione seriale problematica.

quando tutto sarà più consolidato spero invece di poter implementare una comunicazione più efficace.

Originalmente inviato da romoloman

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.

[romoloman]

Originalmente inviato da riki1681

la soluzione con ponte frksy/ppm (quindi un modulo frsky che trasmette a una rx frsky, prendendo un input di segnali ppm generati da arduino che a sua volta prende dal pc i valori e li converte) è una scelta di velocità ed economia.

il software richiede al massimo qualche oretta per lo sviluppo (lato arduino e lato pc), e ho un range di 1,5km spendendo meno di 40 sterline.

ed effettivamente funziona tutto e bene.

sparo una stringa con valori separati da punto e virgola e fine riga con il carattere ascii 10 (\n o vblf o linefeed, o come lo volete chiamare)

arduino attende il fine riga,
legge la stringa e memorizza i valori

ogni 22ms un interrupt richiama una funzione che genera il treno di impulsi ppm, nulla più di una serie di high e low sul pin che va alla tx frsky, di durata variabile in base a quello che invio dalla seriale del pc.

questo richiede una 50ina di righe di codice lato arduino e altrettante lato pc (compresa la lettura dei valori da un joystick collegato al pc)

sinceramente non so quanto invece cubi in termini di tempo implementare uno dei protocolli "seri" che vengono utilizzati da marche che fanno tx/rx.

per quello pensavo di fare un protocollo "light"
e che, magari in futuro, mi permetta, lato pc, di pilotare più tx, tramite le varie uscite di arduino.

poi le mie erano esempi di considerazioni sul perché dare attenzione al messaggio più che a come si invia, non tanto quesiti su come fare un protocollo.
ad ora una stringa di testo svolge egregiamente questa funzione mentre le logiche sono gestite dal pc.
arduino si occupa solo di tenere sotto controllo i valori massimi dei comandi che riceve, in modo da non inviare segnali malformati in caso di comunicazione seriale problematica.

quando tutto sarà più consolidato spero invece di poter implementare una comunicazione più efficace.

FrskyPXX e DSM2 sono protocolli digitali seriali, specialmente il dsm2.
Un modulo dsm2 lo cannibalizzi facile facile da una dx4/dx5 che trovi sul mercato dell'usato a 40€ , considerando che risparmi su arduino tutto sommato mi sembra ragionevole..

[faustog_2]

ciao allora

ecco qui poche righe ma potenti, in ASSEMBLER, fatte per un Pic 16F876 gestisce un Robot dotato di due motori solamente quindi gestisce un segnale PPM di soli due controlli, il terzo gestisce la direzione.. comunque con lo stesso criterio ho progettato un firmware che gestisce 6 servo... il risultato è uguale.. funziona.

; __________________________________________________ ________
;
; MAIN LOOP
; ------------------------------------
;
LOOP btfss INTCON,T0IF ; Controlla che non siano scaduti i 20 mS
GOTO XX ; se TMR0 < 20 mS allora vai XX
CALL MOVE_ALL ; altrimenti vai in MOVE_ALL

XX BTFSS READ_IR_1 ; Se nn legge l infrarosso salta e legge la seriale
call IR_SEND ; altrimenti chiama IR_SEND

btfss PIR1,RCIF ; Receive data from Serial Port
GOTO LOOP ; se non riceve dati vai in LOOP

MOVWF INDF ; carica in INDF il valore

INCFSZ FSR,F ; incrementa l'indirizzo di INDF = FSR

GOTO LOOP ; se FSR < 256 allora vai LOOP

RESET MOVLW 253 ; Nel caso in cui FSR ha raggiunto il 256
MOVWF FSR ; Allora riponi il valore iniziale di 251
GOTO LOOP ; infine torna in LOOP

lo stesso codice si può implementare su Arduino.. la tecnica è sempre la stessa in base all'ordine d'arrivo.. ogni byte sarà dedicato al canale desiderato.. assolutamente sconsigliato inviare posizione valore.. per esempio immaginate che contemporaneamente cambino tre canali su 5 per esempio.. allora dovremmo inviare 2 x 3 = 6 byte.. invece nela caso mio 5 ! se cambiano 5 canali nella prima ipostesi 2 x 5 = 10 byte.. invece la pesantezza della mia soluzione è costante.. vero è che se cambia solo un canale anzichèe 2 bute ne trasferiamo 5 ma alla fine stiamo parlando di un sistema che da un punto di vista pratico è solido.

[romoloman]

Originalmente inviato da faustog_2

ciao allora

ecco qui poche righe ma potenti, in ASSEMBLER, fatte per un Pic 16F876 gestisce un Robot dotato di due motori solamente quindi gestisce un segnale PPM di soli due controlli, il terzo gestisce la direzione.. comunque con lo stesso criterio ho progettato un firmware che gestisce 6 servo... il risultato è uguale.. funziona.

; __________________________________________________ ________
;
; MAIN LOOP
; ------------------------------------
;
LOOP btfss INTCON,T0IF ; Controlla che non siano scaduti i 20 mS
GOTO XX ; se TMR0 < 20 mS allora vai XX
CALL MOVE_ALL ; altrimenti vai in MOVE_ALL

XX BTFSS READ_IR_1 ; Se nn legge l infrarosso salta e legge la seriale
call IR_SEND ; altrimenti chiama IR_SEND

btfss PIR1,RCIF ; Receive data from Serial Port
GOTO LOOP ; se non riceve dati vai in LOOP

MOVWF INDF ; carica in INDF il valore

INCFSZ FSR,F ; incrementa l'indirizzo di INDF = FSR

GOTO LOOP ; se FSR < 256 allora vai LOOP

RESET MOVLW 253 ; Nel caso in cui FSR ha raggiunto il 256
MOVWF FSR ; Allora riponi il valore iniziale di 251
GOTO LOOP ; infine torna in LOOP

lo stesso codice si può implementare su Arduino.. la tecnica è sempre la stessa in base all'ordine d'arrivo.. ogni byte sarà dedicato al canale desiderato.. assolutamente sconsigliato inviare posizione valore.. per esempio immaginate che contemporaneamente cambino tre canali su 5 per esempio.. allora dovremmo inviare 2 x 3 = 6 byte.. invece nela caso mio 5 ! se cambiano 5 canali nella prima ipostesi 2 x 5 = 10 byte.. invece la pesantezza della mia soluzione è costante.. vero è che se cambia solo un canale anzichèe 2 bute ne trasferiamo 5 ma alla fine stiamo parlando di un sistema che da un punto di vista pratico è solido.

La seriale del atmega 328 gestisce senza rogne comunicazioni a 115200.
considerando 2 byte di header 1.5 byte per canale (1024 passi) uno di crc per trasmettere 8 canali trasmettiamo 15 byte ovvero 120bit.
anche trasmettendoli 50 volte al secondo (in realtà un po' meno visto che la lunghezza del frame ppm è 22.5ms) ci ritroviamo a 6000 bit/sec
onestamente abbiamo tutto il margine di sicurezza per riceverli preparare il frame ppm per la routine che nell'interrupt genererà i pulse e ritornare indietro...
Trasmettere le differenze non è salutare, se il micro dovesse perdersi dei pezzi per strada, soprattutto perchè il PC dovrebbe sempre ragionare nella logica che tutto sia sempre stato ricevuto e che non ci sia stato un reset magari dovuto al watchdog del micro.