Qualcuno sperimenta con Arduino?

[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.