Qualcuno sperimenta con Arduino?

[riki1681]

Originalmente inviato da romoloman

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

ok, questo è parlare.
la cosa si fa interessante.
però non voglio intasare la discussione andando OT.
ti scrivo un pm.

[faustog_2]

allora..

c' è da dire che il sistema che ho realizzato funziona su Ethernet! quindi una portante sarebbe improponibile ..se guardi l'immagine ti fa capire meglio il progetto.. il tutto è rivolto verso la Domotica.. per cui in ufficio o in un parco in remoto devo poter pilotare un Robot.. o un sistema che attrverso il PPM controlla posizione servo, regolazioni motore , relè, pulsanti, avere indietro dati di sensori, allarmi ecc..

comunque nel nostro caso come modello uso un semplice robot che si muove attraverso due motori ricavati da avvitatori, e un radar infrarosso che legge ostacoli, poi aggiungo, dei sensori di pressione in caso di ostacoli bassi ecc..

bene il sistem in rete Ethernet deve ridurre il piu possibile il trafico, la quantità di dati.. per cui prende per buono gli ultimi comandi inviati.. salvo variazioni che appunto richiede la trasmissione del treno di byte completo, ovviamente se vogliamo 10 bit per segnale PPM allora i byte diventano 16, ovvero 2 per ogni onda quadra.. di cui sappiamo che il secondo byte usa solo 2 bit.. a meno che si prepara un firmware che compatta le informazioni, per cui il tutto nel caso di 8 canali diventa 10 byte ! per ogni variazione. che verrà inviata solo dopo ogni 16 mS ! per evitare problemi di mancato coordinamento il watchdog si può disattivare.. e non creare problemi in ogni caso se esso viene impostato su tempi oltre i 30 mS nn può interferire con i 16 mS

la discussione mi sta cominciando a piacere
a presto
fausto

Originalmente inviato da romoloman

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.

[romoloman]

Originalmente inviato da faustog_2

allora..
richiede la trasmissione del treno di byte completo, ovviamente se vogliamo 10 bit per segnale PPM allora i byte diventano 16, ovvero 2 per ogni onda quadra.. di cui sappiamo che il secondo byte usa solo 2 bit.. a meno che si prepara un firmware che

no bastano 1.5fino a 4096
supponi di avere in

uint8_t buffer[12] i 12 byte corrispondenti ai canali letti dalla seriale

uint16_t val[]={0,0,0,0,0,0,0,0};
for (int i=0; i<4; i++){
  val[i*2]= buffer[i*3]<<4;
  val[i*2]|= buffer[i*3+1]>>4;
  val[i*2+i]=buffer[i*3+1]<<8;
  val[i*2+i]|=buffer[i*3+2];
}

nessuna compressione e elaborazione veloce visto che si va di shift a nibble.

Quanto a disabilitare i watchdog... de gustibus... ma io li lascio abilitati per sanità di funzionamento, se il micro si pianta deve ripartire. Ci manca più che una radio si inchiodi con un bello schermo di blocco...

[romoloman]

Originalmente inviato da romoloman

no bastano 1.5fino a 4096
supponi di avere in

uint8_t buffer[12] i 12 byte corrispondenti ai canali letti dalla seriale

uint16_t val[]={0,0,0,0,0,0,0,0};
for (int i=0; i<4; i++){
  val[i*2]= buffer[i*3]<<4;
  val[i*2]|= buffer[i*3+1]>>4;
  val[i*2+i]=buffer[i*3+1]<<8;
  val[i*2+i]|=buffer[i*3+2];
}

codice corretto...

uint8_t buffer[12] i 12 byte corrispondenti ai canali letti dalla seriale

uint16_t val[]={0,0,0,0,0,0,0,0};
for (int i=0; i<4; i++){
  val[i*2]= buffer[i*3]<<4;
  val[i*2]|= buffer[i*3+1]>>4;
  val[i*2+1]=buffer[i*3+1]<<8;
  val[i*2+1|=buffer[i*3+2];
}

[faustog_2]

salve.. una osservazione.. premetto che mi trovo in vacanza.. però con me PC e Internet.. ..dunque tra i miei vecchi lavori trovo un'applicazione java che usa la classe HTTPUrlconnection... in sostanza una qualunque applicazione java può comunicare con un web server.. magari dietro c'è un'applicazione in PHP, non importa.. con questo se dotiamo la nostra applicazione di controllo seriale e di HTTPUrlConnection abbiamo tutto per dialogare direttamente con applicazioni fatte con Easy php, Joomla ecc.. !!!! Non è fantastico? vero che in futuro si dovrà sviluppare su Android.. ma al momento volgio percorrere questa vecchia strada.. a dopo

[faustog_2]

ecco un discorso equivalente per Microchip:

***** MICROST TUTORIAL:TRIP & TRICKS sul CCP dei PIC ***

molto interessante a voi

Originalmente inviato da faustog_2

...si concordo.. ..sicuramente la lettura ai datasheet rimane cosa fondamentale, irrinunciabile, ho appena letto sul datasheet dell' ATmega-328 i moduli Capture e Compare.. ...giusto per realizzare degli appunti personali:

Fino a questo momento con i Pic ho creato segnali digitali per svariate destinazioni, per esempio un segnale digitale PWM tipico per il controllo dei motori elettrici, caratterizzato dal Duty Cycle, ho creato via software un segnale digitale per la comunicazione seriale, segnali digitali per per pilotare dei servo, anche il viceversa leggere il segnale di una Ricevente in modo software ecc.
Sono riuscito a mettere in ascolto via software un pin che se legge un valore alto, inizia a contare finchè lo stesso non raggiunge nuovamente il valore basso. In questa maniera abbiamo grossomodo un idea dell’onda quadra che è entrata in INPUT nel nostro Pic. Realizzando un ascoltatore via software, creiamo continuamente delle inevitabili latenze dovute al ritado software delle istruzioni .
Il nostro Pic ha un potenziale da offrirci, ovvero i moduli Capture e Compare. Questi moduli esistono quasi per tutti i Micro della famiglia Microchip, ma in questa sessione studierò quelli dell’ ATmega328 di Arduino. Rispettivamente il modulo Capture, legge un segnale digitale in ingresso mentre il Compare scrive un segnale digitale in uscita. Il modulo Capture per funzionare ha bisogno degli Interrupt, ovvero sono dei sistemi di interruzione programma che il Processore riesce a mettere in atto e gestire, per risolvere problemi di lettura e scrittura di periferiche. Questo ci fa capire che non dobbiamo più occuparci via software di leggere da un pin, ma deleghiamo al modulo hardware del compito, riducendo al minimo le latenze, ottenendo una lettura precisa del segnale. Il registro a 16 bit incaricato per il modulo Capture è ICR1, esso è composto da due registri esattamente: ICR1H : ICR1L , ma il linguaggio C di Arduino lo tratta come se fosse un unico registro, daltronte, passando ad ATmega328 è come se fossimo passati a un Pic della famiglia 18FXXX per cui non è più consigliabile programmare in Assembler, troppo dispendioso. Quindi quando il bit ICF1 del registro TIFR1 assume valore logico 1 (alto) allora il valore di timer1 TCNT1H : TCNT1L viene copiato in ICR1H:ICR1L in pratica viene catturato, infatti il modulo si chiama Capture.

Quindi dobbiamo impostare il nostro pin 14 come Input, inoltre dobbiamo impostare correttamente il bit ICES1 del registro TCCR1B registro di controllo del Timer/Counter1 per stabilire quando deve occorrere l’evento per far scattare l’interrupt, ovvero quando vi è un fronte di salita o un fronte di discesa. Per quello che ricordo nei Pic anche altre alternative, per esempio ogni 4 fronte di salita oppure ogni 16 fronte di salita, tutte opzioni che possono essere gestite attraverso bit dei registri preposti. Basta leggere il datasheet, il discorso si ripete, cambiano i nomi dei registri ma il concetto è lo stesso, altrettanto dicasi per i linguaggi di programmazione, non importa se ASSEMBLER o linguaggio C.

Allora riprendendo il tema Capture se il bit ICF1 viene settato attraverso il registro WGW allora esso verrà settato a 1 quando TCNT1 raggiunge 65.535 quindi il TOP.
Il bit ICF1 bit viene azzerato quando l’Interrupt Vector è in esecuzione. In generale dopo che avviene un interrupt il processore mette nello stack il PC (process counter), come dire metto da parte il lavoro che sto facendo, per occuparmi temporaneamente di qualcosa’altro, automaticamente il processore va ad eseguire I’interrupt Vector che si occupa di bloccare temporaneamente gli altri interrupt, cerca di capire quale Interrupt ha bloccato il normale flusso e cosi esegue le operazioni definite nel modulo hardware in causa, nel nostro caso il modulo Capture.


Passiamo adesso al modulo Compare ovvero ad un modulo che permette di generare su due linee di output un segnale digitale. Questo modulo esegue la comparazione tra il registro OCR1A con TCNT1 , per il pin OC1A mentre la comparazione tra OCR1B con TCNT1 gestisce l'uscita del pin OC1B.
Ovviamente quelli appena visti sono solo la sintesi dei due, in realtà la comparazione riguarda OCR1AH : OCR1AL con TCNT1H : TCNT1L quindi registri a 16 bit, e lo stesso vale fra OCR1BH : OCR1BL e TCNT1H : TCNT1L.

Quando occorre l’uguaglianza tra i due registri visti prima il bit OCF1B del registro TIFR1 viene posto a 1 (alto). Questo vale solo se il bit di posto 7 corrispondente all' I-flag del registro SREG è posto a 1 (alto).

[faustog_2]

ecco per la realizzazione della funzione pulseIn(pin, Hight) oppure pulseIn(pin, Low)

sotto viene utilizzato il modulo Capture, se scriviamo Hight vuol dire che vogliamo rilevare un fronte di salita, se invece mettiamo Low il fronte di discesa.

mentre digitalWrite( . utilizza il modulo Compare..

a dopo

Originalmente inviato da faustog_2

...se vai sugli esempi di arduino, esattamente l'argomento che tratta i sensori, bene per esempio prendi Ping
trovi

pinMode(pingPin,INPUT);
duration = pulseIn(pingPin, HIGH);

ecco pulseIn è la funzione che cerchi, converte la durata dell'onda quadra in un numero long , ad intuito credo che è ciò che cerchi !!
. adesso sono fuori sicilia.. non posso fare prove.. ma se attacchi il segnale che esce dalla ricevente.. ecc..

se vuoi attraverso l'oggeto map( duration, range del valore, range desiderato)

puoi traslare i valori prelevati verso un intervallo che desideri.

a dopo

[faustog_2]

scusate se insisto sul tema,, ma credo se dobbiamo parlare di arduino e aermodellismo questo tema è estremamente interessante.. dunque, sempre all'interno di questo post ho spiegato piu o meno i moduli capture e compare... rileggendo e ristudiando dal datasheet.. in effetti emergono dei dettagli che la volta scorsa ho trascurato.. per non annoiare nessuno di seguito riporto un link dove meglio di me credo sappia spiegare come unsare il capture :

Arduino playground - ReadReceiver

buona lettura se avete dubbi contattatemi.


a dopo
fausto

[faustog_2]

ecco un sistema che lavora con i signoli pin elementare.. quando arduino non deve far altro che appunto leggere e inviare i dati a motori come traducendoli in PWM

RC Hobby Controllers and Arduino - SparkFun Electronics

a dopo
fausto

[faustog_2]

da quello che ho potuto sperimentare.. il processore Atmel 328p ....incrementa il timer in 1/8 uS ovvero 0,125 uS micro secondi

F_CPU/128000 espressi in nano secondo
..se adoperiamo un prescaler maggiore di 1 allora diminuiremo la frequeza...