Costruzione Radiocomando omologato

[protomax]

Originalmente inviato da Stak*

Salvee da molto nn mi collego al forum... vi sarete scordati di me, cmq mrk mi ha parlato un po' del progetto, nn ho avuto tempo di leggere tutti i post di questa conversazione cmq ho trovato per caso questo su internet e potrebbe servirvi nn so to': http://homepages.paradise.net.nz/bhabbott/decoder.html

Carino ;-)))))

[Mrk89]

Ciao a tutti, ho ricontrollato il software di due giorni fa....
Ho sistemato un po' i tempi.
Ancora però sono da sistemare i due delay in accordo però su una rilevazione sperimentale dei ritardi...
Nel senso che per ora non lo posso provare, e che i delay vanno regolati in accordo con il tempo di conversione dell' ADC.
Appena compro il PIC faccio l'ultima "taratura" dei ritardi e provo il tutto....
Poi invierò pure il segnale visualizzato sull'oscilloscopio.



ecco il software:




void main (void)
{
int n,i,c,sinc,durata=0;
long int canale;
TRISB = 0;
TRISC = 0;
TRISD = 0;
ADCON1 = 0x80;

while(1){
n=1;
while(n<9){
n++;
PORTB.F0=1;
canale = ADC_Read(n);
canale = canale*1000/1024;
delay_us(262); // delay casomai variabile
PORTB.F0=0;
delay_us(563); // delay casomai variabile
canale = canale/6;
canale = canale - canale/10 - canale/4;
i=0;
while(i<=canale){
i++;
**
durata = durata + canale;
**
sinc = 12000 - durata;
sinc = sinc/3.3;
c=0;
while(c<=sinc){
c++;
**
**
**



Ho soistituito i for con dei while così da avere un controllo migliore sui ritardi.

[protomax]

Originalmente inviato da Mrk89

Ciao a tutti, ho ricontrollato il software di due giorni fa....
Ho sistemato un po' i tempi.
Ancora però sono da sistemare i due delay in accordo però su una rilevazione sperimentale dei ritardi...
Nel senso che per ora non lo posso provare, e che i delay vanno regolati in accordo con il tempo di conversione dell' ADC.

Ecco perche' si parlava di Interrupt vedi intervento di Mschiepp .
Nel momento in cui dovrai aggiungere qualcosa dovrai ritarare e poi arriverai ad un punto in cui i tempi per fare altro non ti basteranno per svolgere il lavoro in ogni tuo ciclo...es: premere in tasto, comandare un display, controllare il livello batterie, mettere un timer ecc... a questo punto sarai costretto a prendere una decisione :
- Cambiare modo di pensare alla programmazione .
- Cambiare micro se quello che hai non ti permettere di cambiare modo di programmare .

Tutto dipende da come affronti il progetto e che cosa vuoi realizzare ...alla base di un buon prodotto c'e' una buona progettazione

[Mrk89]

Originalmente inviato da protomax

Ecco perche' si parlava di Interrupt vedi intervento di Mschiepp .
Nel momento in cui dovrai aggiungere qualcosa dovrai ritarare e poi arriverai ad un punto in cui i tempi per fare altro non ti basteranno per svolgere il lavoro in ogni tuo ciclo...es: premere in tasto, comandare un display, controllare il livello batterie, mettere un timer ecc... a questo punto sarai costretto a prendere una decisione :
- Cambiare modo di pensare alla programmazione .
- Cambiare micro se quello che hai non ti permettere di cambiare modo di programmare .

Tutto dipende da come affronti il progetto e che cosa vuoi realizzare ...alla base di un buon prodotto c'e' una buona progettazione

Giusto!!
allora vediamo che combino.....nel frattempo se qualcun'0altro ha qualche ideuzza...che ne so...qualche flow-chart magari per avere un'idea di come iniziare un nuovo software....

[rivp6]

Originalmente inviato da Mrk89

Giusto!!
allora vediamo che combino.....nel frattempo se qualcun'0altro ha qualche ideuzza...che ne so...qualche flow-chart magari per avere un'idea di come iniziare un nuovo software....

Allora...queste cose si risolvono realizzando una macchina a stati. Devi crearti un interrupt con il timer che ti gestisce la trasmissione di un'area di memoria riempita dal programma principale, che legge gli ADC, i pulsanti, gestisce LCD e quant'altro. Così svincoli la generazione dei timing dal programma principale.
Ad ogni tick dell'interrupt, modifichi o meno lo stato del'uscita TX in base a quanto hai già trasmesso. Sembra complicato, ma se ci ragioni un attimo è l'unico sistema professionale per realizzare questo tipo di programmi. Concentrati intanto sul task di trasmissione, e quando funziona poi affronti il resto che vedrai diventa una cavolata.

[rivp6]

Allora...queste cose si risolvono realizzando una macchina a stati. Devi crearti un interrupt con il timer che ti gestisce la trasmissione di un'area di memoria riempita dal programma principale. Il programma principale che non ha strette esigenze di temporizzazione legge gli ADC, i pulsanti, gestisce LCD e quant'altro. Così svincoli la generazione dei timing dal programma principale.
Ad ogni tick dell'interrupt, modifichi o meno lo stato del'uscita TX in base a quanto hai già trasmesso. Sembra complicato, ma se ci ragioni un attimo è l'unico sistema professionale per realizzare questo tipo di programmi. Concentrati intanto sul task di trasmissione, e quando funziona poi affronti il resto che vedrai diventa una cavolata

[Claudio_F]

Originalmente inviato da Mrk89

nel frattempo se qualcun'0altro ha qualche ideuzza...

Allora, dobbiamo generare una trama PPM una volta ogni 20mS circa? Bene, un'idea puo' essere di "agganciarsi" a un segnale hardware, puo' essere l'interrupt di un timer interno o una frequenza esterna a 45..50Hz inviata su un pin. Quando scatta il momento, il programma si occupa della trasmissione della trama, che, nell'ipotesi di 8 canali, richiedera' da 8 a 16 millisecondi, nel tempo rimanente si possono svolgere le altre funzioni, lettura ADC ecc.

[Claudio_F]

Originalmente inviato da rivp6

Ad ogni tick dell'interrupt, modifichi o meno lo stato del'uscita TX in base a quanto hai già trasmesso.

Corretto, ma credo che qui ci siano vincoli di tempo piu' stringenti, la parte variabile della fase Toff del segnale ppm puo' durare da 1 a 2mS e deve avere una certa risoluzione, gia' per 100 punti occorrerebbe un aggiornamento ogni 10microsecondi.

[protomax]

Originalmente inviato da Claudio_F

Corretto, ma credo che qui ci siano vincoli di tempo piu' stringenti, la parte variabile della fase Toff del segnale ppm puo' durare da 1 a 2mS e deve avere una certa risoluzione, gia' per 100 punti occorrerebbe un aggiornamento ogni 10microsecondi.

Dipende dalle architetture usate ma in genere se si usa un interrupt con priorita' alta (sopra di lui non c'e' nessuno che interviene) si puo' pensare di far si che l'interrupt dia la partenza della trama legata ad un timer preciso e poi all'interno dell'interrupt si calibri la procedura di trasmissione .

In questo modo si ha a disposizione indipendentemente dalla esecuzione dell'interrupt altri "istanti di tempo" in cui si puo' fare altro.

Pensate all'interrupt come un evento che arriva "congela tutto il resto" prende il soppravvneto sul processore (esegue il codice di interrupt) e poi restituisce il controllo ristabilendo la situazione che aveva interrotto

forse non e' proprio un flowchart ma e' un indicazione

[Mrk89]

Originalmente inviato da protomax

Dipende dalle architetture usate ma in genere se si usa un interrupt con priorita' alta (sopra di lui non c'e' nessuno che interviene) si puo' pensare di far si che l'interrupt dia la partenza della trama legata ad un timer preciso e poi all'interno dell'interrupt si calibri la procedura di trasmissione .

In questo modo si ha a disposizione indipendentemente dalla esecuzione dell'interrupt altri "istanti di tempo" in cui si puo' fare altro.

Pensate all'interrupt come un evento che arriva "congela tutto il resto" prende il soppravvneto sul processore (esegue il codice di interrupt) e poi restituisce il controllo ristabilendo la situazione che aveva interrotto

forse non e' proprio un flowchart ma e' un indicazione

Vediamo se ho capito bene....
Nel "main" si leggono gli ADC e si pilotano altri dispositivi ( lettura pulsanti vari, pilotaggio display) e con l'interrupt si genera la trama degli 8 canali...quindi il timer interno deve dare un'interrupt ogni 20ms...giusto??