Ricezione segnale infrarosso

[lcua31989]

Per riuscire ad "interpretare" la situazione avrei bisogno di sapere quale è il livello logico di tensione all'ingresso (sul pin) del microcontrollore, che poi acquisisce il frame, quando non viene premuto alcun pulsante quindi in condizione di "riposo" (in "idle time")

Il pin ha una resistenza di pull up da 15K ohm. Quindi le tensioni che possono essere sono solo due 5V oppure 0V. Quando non viene premuto alcun pulsante sul pin del microcontrollore ho una tensione di 5V costante.

Inoltre sarebbe importante, per me, capire se a seguito della pressione di un tasto (del trasmettitore) ha subito inizio l'invio del "data frame" o se questo è preceduto da una variazione di stato (da H->L o da L->H) nel quale poi vi permane per un periodo predefinito prima, appunto, di cominciare con la trasmissione di S1, S2, T ...

Ho provato a disegnare con paint (con l'esempio riportato nel post[5]) il segnale sull'ingresso del microcontrollore, proveniente dal sensore di ricezione. Non è precisissimo ma ho comunque cercato di rispettare le tempistiche. Ti allego la foto (spero che ti possa tornare utile). La trasmissione inizia quando viene premuto il pulsante con due segnali di start.

Ciao
lcua31989

[WALTERmwp]

Ho valutato il programma sulla base delle ultime indicazioni che hai messo a disposizione e, seguendo l'evoluzione della ricezione di un codice a caso, non mi risultano delle anomalie.

Bisogna notare che il programma, dovesse perdurare lo stato alto del segnale con la conseguente assenza dell'evento di "FALLING", continuerebbe a "ciclare" senza segnalare (*) l'anomalia, pur non avendo completato l'acquisizione del "data frame".
Questo è dunque solo un esempio per il quale, al suo verificarsi, la decodifica non può avere seguito; è solo una possibilità.
Vorrei poi escludere eventuali problemi legati alla esecuzione delle due funzioni

Codice: Seleziona tutto

    IntToStr(rx_data.packet, txt);
    Uart1_Write_Text(txt);


per le quali non posso scrivere nulla; tu potresti eventualmente verificarle.

Sono contrario ad una routine ISR sviluppata come in questo caso; mi riservo quindi di fare delle considerazioni proprio su questo aspetto e le eventuali implicazioni relative agli "inneschi" degli interrupt(s).

L'evoluzione dello switch che esegue il "parsing", di per sé mi sento di scrivere che potrebbe andare bene, ad eccezione di quanto sopra riportato(*).
Altre eventuali anomalie le dovrei ancora ipotizzare ma, appunto, non escludo che vi possano essere.

In sostanza il codice potrebbe andare bene se la ricezione fosse ideale.
Sarebbe quindi utile avere un'idea del segnale che effettivamente arriva sul pin di ingresso del micro (del PIC).
In difetto di ciò si potrebbe comunque fare qualche prova intervenendo sullo stato d'interfacciamento tra sensore di ricezione e micro; potresti provare togliendo la resistenza di pull-up che tu hai inserito ?
Su quel "filo" c'è solo quella resistenza o è presente qualche altro componente (per es. condensatori) ?

Saluti

[lcua31989]

Ciao,

Vorrei poi escludere eventuali problemi legati alla esecuzione delle due funzioni

Codice: Seleziona tutto

    IntToStr(rx_data.packet, txt);
    Uart1_Write_Text(txt);


per le quali non posso scrivere nulla; tu potresti eventualmente verificarle.

Si ho appena verificato togliendole, aggiungendo un led che dopo tot iterazioni dentro nell'if o lo accende o lo spegne; come riportato sotto:

Codice: Seleziona tutto

if(rx_data.data_rady)
  {
    rx_data.data_rady = 0;
    if(led_count==5)
    {
      PORTA.F2 = !PORTA.F2;
      led_count = 0;
    }
  }


Niente da fare continua a bloccarsi anche con il led. Quindi possiamo escludere a priori che il problema sia dovuto alle due funzioni. Ne sei d'accordo?

Sono contrario ad una routine ISR sviluppata come in questo caso; mi riservo quindi di fare delle considerazioni proprio su questo aspetto e le eventuali implicazioni relative agli "inneschi" degli interrupt(s).

Tu come lo avresti fatto? perché saresti contrario?

In sostanza il codice potrebbe andare bene se la ricezione fosse ideale.
Sarebbe quindi utile avere un'idea del segnale che effettivamente arriva sul pin di ingresso del micro (del PIC).

Purtroppo non ho l'oscilloscopio

potresti provare togliendo la resistenza di pull-up che tu hai inserito ?

certamente, l'ho tolta e ho lasciato il codice del led, ma nulla da fare, dopo un po di ricezioni si blocca.

Su quel "filo" c'è solo quella resistenza o è presente qualche altro componente (per es. condensatori) ?

C'è un Led rosso che blinka non appena riceve un segnale, quindi lo schema sarebbe così:

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

Ciao
lcua31989

[WALTERmwp]

Ne sei d'accordo?

... certo.

Tu come lo avresti fatto?

... portando fuori dalla ISR il codice non essenziale alla gestione dell'interrupt.
Come ti ho scritto mi riservo di fare qualche altra valutazione in merito alle implicazioni del codice "così com'è"; se poi vuoi si può modificare l'esistente.
Prima però desidererei capire cosa eventualmente "non va" a livello software; con questa affermazione parto dal presupposto che dal punto di vista hardware, non potendo io avere alcun riscontro, il funzionamento sia corretto (***).

perché saresti contrario?

... in generale perché, per esempio, il tempo impiegato per l'esecuzione di codice all'interno della ISR "dilata" quello che trascorre (trascorrerebbe) prima che il successivo evento di interrupt, intanto eventualmente insorto, possa essere riscontrato una volta usciti dalla ISR stessa.
In questo caso però non mi pare sussista tale condizionamento però, mi conservo qualche riserva.

(***) Dallo schema che hai riportato ci sono tre resistenze.
Se R1 ti serve per alimentare il sensore, non la tocchiamo.
Se R2 è la resistenza di pull-up (immagino che il catodo del led sia collegato al pin di ingresso del microcontrollore) ed R3 serve solo al led, se possibile scollegherei entrambe e riproverei a trasmettere.

Saluti

[lcua31989]

Ciao,

Se R1 ti serve per alimentare il sensore, non la tocchiamo.
Se R2 è la resistenza di pull-up (immagino che il catodo del LED sia collegato al pin di ingresso del microcontrollore) ed R3 serve solo al LED, se possibile scollegherei entrambe e riproverei a trasmettere.

Ho provato a togliere sia la resistenza di pull up che R3 e il relativo led ma come al solito si blocca.

Detto ciò ti informo che ho trovato il problema così pare. Ovvero, alla fine dell'interrupt io mettevo il registro

Codice: Seleziona tutto

MCCP1CON = FALLING;

e l'ho sostituito con

Codice: Seleziona tutto

MCCP1CON = 0;

. Nella funzione di calcolo e gestione del pacchetto ricevuto ho ricopiato l'intero codice di impostazione dell'intero modulo.
Così il codice in definitiva è:

Codice: Seleziona tutto

  #include "EEprom_Mapping.h"
#include "Remote_Mapping.h"

#define RISING 0B00000101
#define FALLING 0B00000100
#define CLEAR 0B00000000

#define START_EVENT 4 //one start signal: 3000uS -> (2400uS high, 600uS low)
#define ONE_EVENT 2   // Logic one signals: 1200uS high and 600 uS low
#define ZERO_EVENT 1  // Logic zero signals: 600uS high and 600 uS low
#define FIRST_START 0
#define SECOND_START 1
#define TOOGLE 2
#define CAPTURE_DATA 3

#define MOTOR_UP PORTA.F2
#define MOTOR_DW PORTA.F3


typedef struct rx_buffer       //data struct for signal receiving
{
  unsigned short int start;
  unsigned short int toogle;
  unsigned short int device;
  unsigned short int button;
  unsigned short int data_rady;
  int packet;
} buffer;

typedef struct zero_timer   //data struct for the timer 0
{
  unsigned short int timer;
} t_zero;

typedef struct one_timer   //data struct for the timer 1
{
  unsigned short int h_timer;
  unsigned short int l_timer;

} t_one;

unsigned short int counter=0, rx_status=FIRST_START, en_counter=0, bit_counter=0,
                   reset = 0, reset_counter=0;
unsigned int bit_load = 8192, ms_seconds=0, delay=0;

char txt[20];

buffer rx_data={0, 2, 0, 0, 0, 0};

t_one timer_one_a = {0xFB, 0x50}; //600uS
t_zero timer_zero_a = {21};

void initPic();
unsigned short int getToogle();
signed short int checkPacket();



void Interrupt()
{
  //timer 1 is in overflow every 600 uS
  if(PIR1.TMR1IF)
  {
    if(en_counter==1) //if enable counter is one
    {
      counter += 1;  //count up
    }
    else if(PORTB.F0==1) //If the PORTB.F0 is H
         {
           reset_counter+=1; //add 1 to the reset counter
           if(reset_counter==70) //If 42 milli-seconds have elapsed
           {
             reset_counter=0; //clear reset counter
             reset=1; //reset = 1
           }
         }

    if(counter>5) //if counter is grater of 5
    {
      rx_status = FIRST_START; //reset the main routine to decode the signal
      CCP1CON = CLEAR;
    }

    TMR1H = timer_one_a.h_timer;  //restet timer 1
    TMR1L = timer_one_a.l_timer;  //restet timer 1
    PIR1.TMR1IF = 0; //restet Interrupt timer 1
  }

  //This Interrupt routine measure the translations H -> L only
  if(PIR1.CCP1IF)
  {
    if(CCP1CON == FALLING) //if a translation H -> L is available
    {
      CCP1CON = RISING;  //Will be measured the L -> H translation
      en_counter = 1; //enable counter
    }
    else if(CCP1CON == RISING) //if a translation L -> H is available
         {
           CCP1CON = FALLING; //Will be measured the H -> L translation
           en_counter = 0; //disable the counter
         }

    switch(rx_status)
    {
      case FIRST_START:  //routine able to detect the first start bit

        rx_data.data_rady = 0; //Data is not rady

        if(counter == START_EVENT)  //if the first start bit has been sent
        {
          counter = 0;  //clear the counter
          rx_status = SECOND_START; //Check the next transmission
          rx_data.start = 1;  //Detected the first start bit
          reset_counter = 0;
        }
        else
        {
          rx_status = FIRST_START;
          rx_data.start = 0;
        }

      break;

      case SECOND_START:  //routine able to detect the second start bit

        if(counter == START_EVENT)  //if the second start bit has been sent
        {
          counter = 0;   //clear the counter
          rx_status = CAPTURE_DATA;  //check the next data byte
          rx_data.start = 2;  //Dtected the second start bit
          rx_data.toogle = 0;  //clear and restore all variables
          rx_data.device = 0;
          rx_data.button = 0;
          rx_data.data_rady = 0;
          rx_data.packet = 0;
          bit_load = 8192;
          reset_counter = 0;
        }
        else
        {
          rx_status = SECOND_START;
          rx_data.start = 0;
        }

      break;

      case CAPTURE_DATA: //routin able to detect the data byte: toogle, add, cmd

        if(counter==ZERO_EVENT) //if the zero bit has been sent
        {
          counter = 0;  //clear counter
          rx_data.packet = rx_data.packet | 0; //add zero to the packet
          bit_load = bit_load >> 1; //shift right the next bit to load
          reset_counter = 0;
        }
        else if(counter==ONE_EVENT) //if the one bit has been sent
             {
               counter = 0;  //clear counter
               rx_data.packet = rx_data.packet | bit_load; //add one to the pkt
               bit_load = bit_load >> 1; //shift right the load next bit to load
               reset_counter = 0;
             }

        if(bit_load == 0) //if all data frame has been sent
        {
          rx_data.data_rady = 1; //data is rady to spit
          rx_status = FIRST_START; //restore the status
          CCP1CON = CLEAR; //clear the ccp1con register
          reset_counter = 0; //reset counter = 0
        }

      break;
     
      default: CCP1CON = 0; rx_status = FIRST_START; break;
    }

    PIR1.CCP1IF = 0;  //reset interrupt
  }
}

void main()
{
  unsigned short int messaggio=0;

  initPic();
   
  Sound_Play(880, 500);
  Uart1_init(9600);

  UART1_Write_Text("RS232 rady\r\n");

  while(1)
  {
    checkPacket();
  }
}

signed short int checkPacket()
{
  signed short int returned_value=0;

  rx_data.toogle = (rx_data.packet & 0x2000)>>13;
  rx_data.device = (rx_data.packet & 0x1F80)>>7;
  rx_data.button = rx_data.packet & 0x7F;
 
  if(rx_data.data_rady==1)
  {
    if(rx_data.start==2)
    {
      if(rx_data.device==EEPROM_Read(EE_REMOTE_ADDRESS_LOCATION))
      {
        returned_value = 1; //device address does match
      }
      else
        returned_value = -1; //device address doesn't match
    }
    else
     returned_value = -2; //Start signals are mismatch
  }
  else
    returned_value = -3;  //If data is not rady
 
  if(returned_value>0) //device address does match 
  {
    IntToStr(rx_data.packet, txt); //convert the integer packet in a string
    Uart1_write_text(txt); //Write to the uart the last sring
    Uart1_write_text("\r\n"); //new line
   
  }
 
  if(CCP1CON == CLEAR || reset == 1) //if CCP1CON is cleared or reset condition in set
  {
    //retore initial condition for MCCP module
   
   INTCON = 0b11000000; //Enable interrupts
    PIE1.CCP1IE = 0; //Disable cccp1ie interrup
    PIE1.TMR1IE = 0; //Disable tmr1ie interrupt
    PIR1.TMR1IF = 0; //clear tmr1if interrupt flasg
    PIR1.CCP1IF = 0; //clear ccp1if interrupt flag

    CCP1CON = FALLING;
    TMR1H = timer_one_a.h_timer; //configurations of the timer 1
    TMR1L = timer_one_a.l_timer;
    T1CON = 0b00000001;

    PIE1.CCP1IE = 1; //Enable cccp1ie interrup
    PIE1.TMR1IE = 1; //Enable tmr1ie interrupt
    PIR1.TMR1IF = 0; //clear tmr1if interrupt flasg
    PIR1.CCP1IF = 0; //clear ccp1if interrupt flag

    counter = 0; //clear counter
    en_counter = 0; //disable counter
    reset = 0;
  }

  rx_data.data_rady = 0;
  rx_data.start = 0;
  rx_data.device = 0;
 
  return returned_value;
}

void initPic()
{
  TRISA = 0B00000111;
  PORTA = 0;
  ANSELA = 0B00000111;
  WPUA = 0B00000000;

  ADCON0 = 0B00000000;
  ADCON1 = 0B00000000;

  TRISB = 0B11111111;
  PORTB = 0;
  ANSELB = 0B00000000;
  WPUB = 0B11111000;

  APFCON0 = 0B00000001;  //ccp1 in RB0 pin
  APFCON1 = 0B00000001;  //tx pin in RB5 pin

  OPTION_REG.NOT_WPUEN = 0; //Enable the above pull up resistor

  CCP1CON = FALLING; //define CCP module as capture mode each falling edge

  INTCON = 0b11000000; //Enable interrupts
  PIE1.CCP1IE = 0; //Disable cccp1ie interrup
  PIE1.TMR1IE = 0; //Disable tmr1ie interrupt
  PIR1.TMR1IF = 0; //clear tmr1if interrupt flasg
  PIR1.CCP1IF = 0; //clear ccp1if interrupt flag

  TMR1H = timer_one_a.h_timer; //configurations of the timer 1
  TMR1L = timer_one_a.l_timer;
  T1CON = 0b00000001;

  PIE1.CCP1IE = 1; //Enable cccp1ie interrup
  PIE1.TMR1IE = 1; //Enable tmr1ie interrupt
  PIR1.TMR1IF = 0; //clear tmr1if interrupt flasg
  PIR1.CCP1IF = 0; //clear ccp1if interrupt flag

  Sound_Init(&PORTA, 4);
  ADC_Init();
}


Però se vuoi aiutarmi a scrivere del codice più snello come suggerivi prima ne sarei onorato.

Grazie per la pazienza,
ciao
lcua31989

[WALTERmwp]

Detto ciò ti informo che ho trovato il problema così pare (...)

... in base a quello che poi scrivi sarebbe necessario sapere se ne hai verificato il funzionamento.

Quello che ti ho scritto nel Post [12] teneva conto anche della verifica alle impostazioni ovvero avevo controllato le assegnazione e, sia quelle del modulo ECCP1 che del timer 1, mi sembrano coerenti.
Le "define" impiegate rispettano quanto previsto cioè (pag.226 datasheet):

CCPxM<3:0>: ECCPx Mode Select bits
0100 =Capture mode: every falling edge
0101 =Capture mode: every rising edge

Impostando 0000 disattivi il rilevamento (metti in off) mentre sarebbe corretto lasciarlo come era prima; infatti, quando viene soddisfatto il test ...

Codice: Seleziona tutto

if(bit_load == 0) //if all data frame has been sent

... significa che hai completato l'acquisizione dei 14 bit(s) previsti (toggle compreso) per cui ti devi predisporre per intercettare il successivo evento (che si verifica se viene trasmesso un nuovo data frame) costituito dalla variazione di segnale H -> L.
Ho valutato l'evoluzione logica e il rilevamento dei fronti di salita (L -> H) e discesa (H -> L) è pertinente.

Poi, come ho già scritto, la logica dello "switch()" lascia "scoperte" alcune situazioni ma non pregiudica il recupero del rilevamento di un "data frame" se il precedente non è stato identificato.
Questa affermazione, per esempio, trova riscontro nel caso in cui il secondo start bit (S2) ha una durata inferiore ai 2400 us: si verifica infatti l'impossibilità di "riconoscere" i successivi bit(s) sino a che non viene intercettato l'inizio di un nuovo "data frame".

Comunque, se puoi confermare, a seguito di una verifica pratica, il corretto funzionamento, meglio così.
Dovesse così essere mi farebbe piacere capirne il motivo.
In attesa della tua conferma rimango scettico solo per il fatto che mi pare strano.

Posso dare un'occhiata anche al nuovo sorgente ma prima sarebbe il caso di attendere l'esito dell'applicazione delle tue variazioni.

Saluti

[lcua31989]

Ciao,

... in base a quello che poi scrivi sarebbe necessario sapere se ne hai verificato il funzionamento.

Sì ho provato a togliere la resistenza R2 e R3 + Led ma il problema persisteva.

Quello che ti ho scritto nel Post [12] teneva conto anche della verifica alle impostazioni ovvero avevo controllato le assegnazione e, sia quelle del modulo ECCP1 che del timer 1, mi sembrano coerenti.
Le "define" impiegate rispettano quanto previsto cioè (pag.226 datasheet):

CCPxM<3:0>: ECCPx Mode Select bits
0100 =Capture mode: every falling edge
0101 =Capture mode: every rising edge

Guarda l'application note sezione 14.3.2: http://ww1.microchip.com/downloads/en/DeviceDoc/31014a.pdf

Dice che oltre a fare il clear del bit CCPXIF devo fare anche il clear del CCPXIE. Nel mio codice nuovo "andando a tentoni" ho scritto anche di resettare il flag CCPXIE. Probabilmente senza il clear di esso a colte andava in crash.

Poi, come ho già scritto, la logica dello "switch()" lascia "scoperte" alcune situazioni ma non pregiudica il recupero del rilevamento di un "data frame" se il precedente non è stato identificato.

Ecco io qui non riesco a capire cosa intendi. Quali condizioni sarebbero mancanti?

Comunque, se puoi confermare, a seguito di una verifica pratica, il corretto funzionamento, meglio così.
Dovesse così essere mi farebbe piacere capirne il motivo.
In attesa della tua conferma rimango scettico solo per il fatto che mi pare strano.

Si posso confermare che non ha più avuto stalli, anzi modificando anche l'interrupt del timer (vedi sorgente del mio post precedente precedente) riesco a gestire anche il caso in cui riceva segnali con altre codifiche senza che si impalli. (Questo non l'ho fatto a tentoni c'è dietro uno studio )

Ciao,
lcua31989

[WALTERmwp]

Darò volentieri uno sguardo al riferimento dell'AN che hai riportato, grazie.
Per questo ...

(...)Probabilmente senza il clear di esso a colte andava in crash.

... prima di esprimere un parere vorrei verificare.
Per quanto riguarda l'ultimo programma (codice del Post [15]) direi che che le modifiche apportate lo hanno cambiato in modo significativo: anche questo mi riservo di compararlo con il precedente (codice del Post [5]) al quale adesso mi riferisco per rispondere a ...

Quali condizioni sarebbero mancanti?

precisando che lo switch() non gestisce le incongruenze che si possono verificare in ricezione (per es.per tempi diversi da quelli previsti) ma, a fronte di un errore (che non viene segnalato) continua ad evolvere ignorando anche il termine della trasmissione del "data frame"; i controlli sono parziali.
Riporto quindi quello che ho scritto nel Post [16]: "Questa affermazione, per esempio, trova riscontro nel caso in cui il secondo start bit (S2) ha una durata inferiore ai 2400 us: si verifica infatti l'impossibilità di "riconoscere" i successivi bit(s) sino a che non viene intercettato l'inizio di un nuovo "data frame".".
Cioè, se si verifica che la trasmissione del bit S2, per qualche motivo, non viene acquisita correttamente, il ricevitore continua ad evolvere nello stato SECOND_START perché tutti i bit(s) successivi hanno una durata e composizione completamente differente.
Comunque, riscrivo, che guarderò il nuovo codice con attenzione anche se, nell'evoluzione dello "switch()", da una prima veloce lettura, non mi pare sia inserito il reset dei "Mode Select bits".
Sto quindi anticipando solo dei dubbi, più che affermazioni (proprio perché prima devo leggere), ma sono coerenti dato che nel corso dell'acquisizione non si ricorre a questo azzeramento (quello di MCCP1CON) che invece viene eseguito solo nel caso in cui i 14 bit(s) sono stati acquisiti e quando il periodo con segnale basso supera i 3000 us ( ... quindi perché non dovrebbe essere necessario in altri momenti, quale sarebbe il criterio adottato per stabilire questi momenti ? ).
In sostanza, se funziona, vorrei capire adesso cosa lo permette rispetto a prima tenendo presente che, come avevo già scritto, il programma poteva "anche" non funzionare proprio per la carenza di controlli ed interpretazioni dello stato del segnale ricevuto.

Saluti

[lcua31989]

Ciao,

scusa se c'ho impiegato tanto a rispondere ma sono stato male purtroppo. Comunque:

precisando che lo switch() non gestisce le incongruenze che si possono verificare in ricezione (per es.per tempi diversi da quelli previsti) ma, a fronte di un errore (che non viene segnalato) continua ad evolvere ignorando anche il termine della trasmissione del "data frame"; i controlli sono parziali.
Riporto quindi quello che ho scritto nel Post [16]: "Questa affermazione, per esempio, trova riscontro nel caso in cui il secondo start bit (S2) ha una durata inferiore ai 2400 us: si verifica infatti l'impossibilità di "riconoscere" i successivi bit(s) sino a che non viene intercettato l'inizio di un nuovo "data frame".".
Cioè, se si verifica che la trasmissione del bit S2, per qualche motivo, non viene acquisita correttamente, il ricevitore continua ad evolvere nello stato SECOND_START perché tutti i bit(s) successivi hanno una durata e composizione completamente differente.
Comunque, riscrivo, che guarderò il nuovo codice con attenzione anche se, nell'evoluzione dello "switch()", da una prima veloce lettura, non mi pare sia inserito il reset dei "Mode Select bits".
Sto quindi anticipando solo dei dubbi, più che affermazioni (proprio perché prima devo leggere), ma sono coerenti dato che nel corso dell'acquisizione non si ricorre a questo azzeramento (quello di MCCP1CON) che invece viene eseguito solo nel caso in cui i 14 bit(s) sono stati acquisiti e quando il periodo con segnale basso supera i 3000 us ( ... quindi perché non dovrebbe essere necessario in altri momenti, quale sarebbe il criterio adottato per stabilire questi momenti ? ).

E' vero che il mio switch non gestisce errori di questo tipo, infatti ci pensa il nuovo codice di reset impostato sul timer 1. Se come dici tu, il puntatore rimane bloccato nella routine "SECOND_START", il timer 1 provvede lui stesso a ripristinarne lo stato quando il segnale torna a 1 (assenza di trasmissione).

Codice: Seleziona tutto

if(en_counter==1) //if enable counter is one
    {
      counter += 1;  //count up
    }
    else if(PORTB.F0==1) //If the PORTB.F0 is H
         {
           reset_counter+=1; //add 1 to the reset counter
           if(reset_counter==70) //If 42 milli-seconds have elapsed
           {
             reset_counter=0; //clear reset counter
             reset=1; //reset = 1
           }
         }


Se en_counter è abilitato (nei fronti di discesa) il microcontrollore continua la misurazione degli impulsi. Se la variabile en_counter valer zero (condizione tale per cui CCP1CON=RISING allora mi chiedo se il piedino si trova nello stato logico 1. In tal caso abilito un secondo contatore (reset_counter) che dopo 42 milli secondi continui resetta il tutto. Da notare che la pausa di una trasmissione all'altra è di 50 milli secondi.

Spero di aver chiarito i dubbi, altrimenti chiedi pure.

Ciao
lcua31989