ElectroYou

Ciao a tutti,

sto sviluppando un'applicazione all'infrarosso con protocollo di trasmissione molto simile a quello di SONY ma leggermente modificato. Simile perché le tempistiche di 1, 0 e start sono le stesse ma ciò che cambia è la lunghezza dei bit (16 bit), l'invio di due segnali di Start e la frequenza a 40KHz. Detto ciò, sto programmando un 16F1827 e per decodificare il segnale utilizzo il modulo ECCP (Compare Capture PWM) in modalità capture. Il PIC funziona con quarzo da 8Mhz e il PLL è disabiliato. Il programma funziona ovvero riesco a decodificare giustamente il segnale, ma dopo un po di decodifiche il programma si blocca e non capisco il perché, l'unico modo per farlo riprendere è un reset dal pin MCLR. E' una settimana e mezza che ci sono sopra a questo problema e non ne vengo a capo. Di seguito riporto il codice:

Codice: Seleziona tutto

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

#define RISING 0B00000101
#define FALLING 0B00000100
#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


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, check=0, entrato=0, bit_counter=0, counter_reply;
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 splitPacket();
unsigned short int getButtonPressed();
unsigned short int checkPacket();
void playBuzzer(unsigned short int message);
void setTimer0();
void clearTimer0();


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
    }
   
    if(counter>5) //if counter is grater of 5
      rx_status = FIRST_START; //reset the main routine to decode the signal
     
    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
        }
        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;
        }
        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
        }
        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
             }

        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
          counter = 0; //clear counter
          CCP1CON = FALLING; //restore the CCP module as falling rise edge
          en_counter = 0; //disable counter
        }
     
      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)
  {
    check = checkPacket();
  }
}

void playBuzzer(unsigned short int message)
{
  //write code
}

unsigned short int getButtonPressed()
{
  unsigned short int button = 0;
 
  button = rx_data.button;
 
  return button;
}

unsigned short int checkPacket()
{
  unsigned short int returned_value=0;
   
   if(rx_data.data_rady)
  {
    rx_data.data_rady = 0;
    IntToStr(rx_data.packet, txt);
    Uart1_Write_Text(txt);
    Uart1_Write_Text("\r\n");
  }
 
void initPic()
{
  TRISA = 0B00000011;
  PORTA = 0;
  ANSELA = 0B00000011;
  WPUA = 0B00000000;
 
  ADCON0 = 0B00000000;
  ADCON1 = 0B00000000;

  TRISB = 0B000001111;
  PORTB = 0;
  ANSELB =0B00000000;
  WPUB = 0B00000000;
 
  APFCON0 = 0B00000001;  //ccp1 in RB0 pin
  APFCON1 = 0B00000001;  //tx pin in RB5 pin

  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);
}


Qualcuno sa come aiutarmi per cortesia ?

Saluti,
lcua31989

in attesa che qualcuno che ne sappia più di me provo a formulare un ipotesi:
prova a disabilitare il watchdog timer (se non l'hai fatto) e guarda se il codice funziona bene e a lungo...

scusami ma è tutto ciò che posso dirti non avendo mai programmato seriamente un micro che non sia arduino

Ciao,

figurati apprezzo l'aiuto... purtoppo è stata una svista, si il watchdog è disabilitato.

Ne approfitto per arricchire di dettagli il problema; quando si blocca il PIC funziona normalmente, tutte le altre funzioni di ingresso e uscita sui registri PORTA e PORTB funzionano correttamente. Detto ciò escluderei un problema con il puntatore interno sul PIC, ma piuttosto sul modulo CCP. Ancora però non riesco a venirne a capo

Saluti,
lcua31989

Ciao lcua31989, intanto dovresti confermare la completezza del codice riportato.
Potrebbe essere solo una svista o indicativo del fatto che qualcosa manchi visto che la parentesi di chiusura della funzione "checkPacket()" è assente.
Alcune funzioni, tra quelle richiamate, non sono presenti; indipendentemente dalla loro importanza bisognerebbe capire o sapere perché non ci sono.
Per questo ...

lcua31989 ha scritto:ma dopo un po di decodifiche il programma si blocca

... potresti rispondere a:
i) quante sarebbero le "decodifiche" che vanno a buon fine ?
ii) tale quantità è ripetitiva, dopo il reset ?
iii) poi, chi trasmette a chi ? (il codice sembrerebbe quello del ricevitore)
iv) il messaggio che viene trasmesso come è strutturato ? (qualcosa ho capito ma potresti essere più chiaro nella tua spiegazione ? )
v) vorrei evitare di andarmi a cercare il protocollo della sony ma se vuoi riportare il riferimento al quale ti sei appoggiato per il tuo progetto sarebbe cosa gradita e, contestualmente, potresti puntualizzare nel merito di questo ...

lcua31989 ha scritto:Simile perché le tempistiche di 1, 0 e start sono le stesse ma ciò che cambia è la lunghezza dei bit (16 bit)

... spiegando cosa intendi per "lunghezza dei bit (16 bit)", così magari è un pochino più chiaro a tutti.
Per l'argomento che hai posto azzarderei una risposta ma preferirei che tu prima, se per te fosse possibile, rispondessi a quanto sopra riportato.

Saluti

Ciao,

codice rivisto:

Codice: Seleziona tutto

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

#define RISING 0B00000101
#define FALLING 0B00000100
#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


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, check=0, entrato=0, bit_counter=0, counter_reply;
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 splitPacket();
unsigned 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
    }
   
    if(counter>5) //if counter is grater of 5
      rx_status = FIRST_START; //reset the main routine to decode the signal
     
    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
        }
        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;
        }
        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
        }
        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
             }

        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
          counter = 0; //clear counter
          CCP1CON = FALLING; //restore the CCP module as falling rise edge
          en_counter = 0; //disable counter
        }
     
      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)
  {
    check = checkPacket();
  }
}

unsigned short int checkPacket()
{
  unsigned short int returned_value=0;
   
   if(rx_data.data_rady)
  {
    rx_data.data_rady = 0;
    IntToStr(rx_data.packet, txt);
    Uart1_Write_Text(txt);
    Uart1_Write_Text("\r\n");
  }
}
 
void initPic()
{
  TRISA = 0B00000011;
  PORTA = 0;
  ANSELA = 0B00000011;
  WPUA = 0B00000000;
 
  ADCON0 = 0B00000000;
  ADCON1 = 0B00000000;

  TRISB = 0B000001111;
  PORTB = 0;
  ANSELB =0B00000000;
  WPUB = 0B00000000;
 
  APFCON0 = 0B00000001;  //ccp1 in RB0 pin
  APFCON1 = 0B00000001;  //tx pin in RB5 pin

  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);
}


alcune funzioni non ci sono, perché le ho cancellate dal programma completo originale e mi sono dimenticato di toglierle nella dichiarazione dei metodi. Per quanto riguardano la parentesi l'ho persa qui nel copia e incolla del codice .

1) purtroppo la quantità di decodifiche sono una ventina, ma a volte una decina o anche 2 o3. Non so da cosa dipenda

2) Dopo il reset non è ripetitiva la quantità sopra citata. A volte devo fare il reset sin da subito perché si blocca già in partenza.

3) Il "telecomando" autocostruito, non so se vuoi ti posto il codice del trasmettitore perfettamente funzionante e senza bug. Lui trasmette al ricevitore che è quello che si blocca dopo un po di ricezioni

4) Il trasmettitore invia una serie di impulsi a 40KHz e la quantità di impulsi varia in base se il dato trasmetto è un segnale di start, uno o zero. Le tempistiche sono, calcolando il tempo dei 40KHz con 1/f = 25 uS:
- Start: 2600 uS alto e 600 uS basso. Quindi avrò 2400uS/25uS = 96 impulsi da 40 kHz e uno spazio
completamente a zero da 600 uS.
- Uno: 1200 uS alto e 600 uS basso. Quindi avrò 1200uS/25uS = 48 impulsi da 40 kHz e uno spazio
completamente a zero da 600 uS.
- Zero: 600 uS alto e 600 uS basso. Quindi avrò 600uS/25uS = 24 impulsi da 40 kHz e uno spazio
completamente a zero da 600 uS.
- Pausa di ripetizione: 50 uS

Il data frame diversamente da sony è così strutturato:
S1 +S2 + T + A5 + A4 + A3 +A2 + A1 +A0 + C6 + C5 +C4 +C3 + C2 + C1 + C0

dOVE:

S1--> Primo segnale di start.
S2 --> Secondo segnale di start.

T --> Toggle. (Come per il protocollo philips il toogle identifica se il pulsante del telecomando è premuto
oppure no.
A --> E' l'indirizzo del ricevitore
C --> Numero identificativi dei pulsanti premuti.

ecco la documentazione, Ah si ho anche scambiato la codifica degli uno e zero :

http://www.cypress.com/?docID=46755

Per darti un'idea del segnale trasmesso allego uno screen print di proteus. Purtoppo non possiedo l'oscilloscopio per verificarne il corretto segnale. Tieni conto che proteus non è al 100% affidabile.

Ciao lcua31989

Parto dal presupposto che il trasmettitore da te predisposto funzioni e funzioni correttamente; ai fini di questa "indagine" potrebbe essere utile dare un'occhiata anche a quello ma, per ora, vediamo se possiamo farne a meno.
Eventualmente lo puoi pubblicare per condividerlo con gli utenti che, a vario titolo, seguono il thread; credo che il gesto sarebbe apprezzato.

Tornando alla questione, ho visto il documento associato al link che hai riportato ma questo fa riferimento alla Sony e non alla Philips alla quale invece hai accennato menzionando il toggle.
Per quanto ti riguarda questo (il toggle) quale durata dovrebbe avere e come dovrebbe essere "composto" ?
Inoltre, con questo ...

lcua31989 ha scritto:ho anche scambiato la codifica degli uno e zero

... "precisamente" cosa intendi scrivere ?
Quello che hai riportato è ambiguo (anche considerando quanto hai riferito al punto 4) del tuo ultimo Post ) perché l'interpretazione che si può dare è più d'una; ovvero puoi avere attribuito il significato di 1(uno) al segnale che rappresenta in realtà lo 0(zero) oppure hai invertito i livelli di tensione lasciando inalterati i periodi (n.1); in entrambi i casi si intende sempre fare riferimento al "Sony SIRC infrared protocol".

Quest'ultimo, poi, menziona una tempistica che segue lo "idle" time e precede la trasmissione del messaggio; hai implementato o tenuto conto di una cosa del genere ?
Te lo chiedo, non col fine di esprimere un parere ma, semplicemente, per recuperare qualche informazione in più.

Saluti

(n.1) - ad es.il "one sign." è tale e così interpretato se la tensione risulta: 1200 uS bassa(0) e 600 uS alta(1).

Ciao,

WALTERmwp ha scritto:Parto dal presupposto che il trasmettitore da te predisposto funzioni e funzioni correttamente;

Posso confermarti che il trasmettitore funzione egregiamente

WALTERmwp ha scritto:Tornando alla questione, ho visto il documento associato al link che hai riportato ma questo fa riferimento alla Sony e non alla Philips alla quale invece hai accennato menzionando il toggle.
Per quanto ti riguarda questo (il toggle) quale durata dovrebbe avere e come dovrebbe essere "composto" ?
Inoltre, con questo ...

Il bit toogle cambia: se il pulsante del trasmettitore sarà premuto invierà il segnale H (1200uS H + 600uS L), quando esso viene rilasciato il trasmettitore invierà L (600uS H + 600uS L). Per la precisione è il bit 14 che varrà 1 o 0 a secondo dello stato del pulsante. Facciamo un esempio:
1) Il dispositivo ha come indirizzamento 0B00000001
2) Viene premuto il pulsante che ha come codice di trasmissione 0B00000001
3) Vengono inviati i due bit di Start
Seguendo il dataframe: S1 +S2 + T + A5 + A4 + A3 +A2 + A1 +A0 + C6 + C5 +C4 +C3 + C2 + C1 + C0
otterremmo come decodifica questo codice 0B 1110 0000 1000 0001.
Ora il suddetto pulsante viene rilasciato il codice ricevuto sarà: 0B 1100 0000 1000 0001.
Spero di essere stato chiaro, altrimenti non farti scrupoli a chiedere chiarimenti

WALTERmwp ha scritto:

lcua31989 ha scritto: ho anche scambiato la codifica degli uno e zero

... "precisamente" cosa intendi scrivere ?

niente ho detto io una cacchiata scusa il mio errore

WALTERmwp ha scritto:Quest'ultimo, poi, menziona una tempistica che segue lo "idle" time e precede la trasmissione del messaggio; hai implementato o tenuto conto di una cosa del genere ?
Te lo chiedo, non col fine di esprimere un parere ma, semplicemente, per recuperare qualche informazione in più.

Si l'ho fatto. Nel trasmettitore è scritto questo codice:

Codice: Seleziona tutto

  if(P6 == PRESSED)
  {
       pkt.toogle = 1; //setta la variabile toogle a 1
       pkt.command = P6_VALUE; //il comando da inviare sarà il valore di P6
             
       while(P6 != NOT_PRESSED)  //fino a quando il pulsante non viene rilasciato
       {
         sendData(pkt.command, pkt.toogle); //preparazione dati da iviare
         Delay_ms(45); //tempo di ritrasmissione
       }
       pkt.toogle = 0;
       sendData(pkt.command, pkt.toogle);
  }


Ora la codifica, trasmissione funzionano senza problemi. Quello che da problemi invece è la decodifica che riceve il corretto pacchetto attribuendo ad esso la corretta semantica del messaggio, ma dopo un po di codifiche s'inchioda il ricevitore e non riesco a venirne a capo. Per ripristinare il corretto funzionamento devo mettere a L il pin MCLR. Spero tu possa aiutarmi perché non ci riesco da solo, se vuoi altri chiarimenti o vuoi il codice sorgente del trasmettitore per dargli un'occhiata chiedi pure

ciao,
lcua31989

Ho preso visione del codice riportato nel Post [5] ma ho qualche perplessità in merito.
Al momento tralascio considerazioni di carattere generale sulle quali potremmo e, secondo me, dovremmo tornare perché fondamentali per una coerente implementazione.
Prima di procedere ad una eventuale sistemazione dello script credo sia il caso di stabilirne l'affidabilità per quello che è ora.

Per l'interpretazione che posso (riesco a) dare con gli elementi a disposizione trovo veramente strano che il ricevitore riesca a funzionare anche una sola volta; ma è possibile che mi sfugga qualcosa, e non ci sarebbe nulla di strano.

La mia perplessità deriva dal fatto che nell'evoluzione dello switch (contenuto nella ISR) non dovresti riuscire ad andare oltre lo stato "SECOND_START".

Questo lo scrivo partendo dai presupposti che di seguito riporto ed in assenza dei quali o di parte di essi la "perplessità" da me manifestata dovrebbe essere "rivista".

I presupposti sono:

i) l'evoluzione del timer 1 è svincolata ed indipendente dal modulo di comparazione
ii) in assenza di trasmissione (cioè in "idle time") il tuo microcontrollore rileva in ingresso il segnale alto (cioè on, 1)
iii) quando inizi la trasmissione, prima che si possa cominciare ad interpretare lo stato del segnale in ingresso come primo start (cioè FIRST_START) dovrebbero trascorrere tra i 600 us ed i 2400 us; in questa fase, la tempistica che ho stimato (relativa al conteggio che avviene a seguito della prima transizione H -> L) dovrebbe appunto rappresentare il periodo che segue lo "idle time" e precede l'inizio del messaggio vero e proprio ( cioè: S1, S2, ... ).
Invece mi trovo ad interpretarlo come S1 (ma non vedo alternative), e così evolve nello "switch".
iv) dopo questa fase ci si dovrebbe predisporre alla ricezione di S1 che, invece, si ritiene d'avere già acquisito; così, seguendo il flusso del codice, ci si ritrova nello stato relativo al rilevamento del secondo start cioè S2 (in SECOND_START) mentre invece quello che viene trasmesso è ancora il primo start cioè S1.

Giunti a questo punto la ricezione è compromessa; dovessero essere messi in discussione i presupposti (me li rettifichi), è chiaro che la "partenza" va rivista, sulla base di altre indicazioni che tu dovresti fornire.

Per quanto sopra, mi sorge di nuovo un dubbio in merito a ciò che avevi scritto a proposito ...

lcua31989 ha scritto:Ah si ho anche scambiato la codifica degli uno e zero

... salvo poi ricrederti ritirando quella affermazione.

Saluti

Ciao,

chiedo un'altra volta scusa, mi sa che l'ho scritto nel primissimo post, ma prima dell'invio è salta la corrente omettendolo al rifacimento di esso. Il segnale trasmesso dal fotodiodo (vedi segnale allegati post[5]), viene ricevuto e decodificato dal sensore tsop 1740. Purtroppo questo sensore non è possibile emularlo sul simulatore ISIS proteus e quindi non posso fartelo vedere perché non posseggo l'oscilloscopio purtroppo. Comunque posso allegarti il datasheet http://www.micropik.com/PDF/tsop17xx.pdf.

Il timer1 viene sincronizzato con la variabile en_counter.

Se hai bisogno di chiarimenti nessun problema

Ciao
lcua31989

lcua31989 ha scritto:chiedo un'altra volta scusa

... ma non vedo alcun motivo per farlo.
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").
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 ...
Dato che trasmettitore e ricevitore mi pare di capire sono caratterizzati da un adattamento "custom" è fondamentale conoscere questi dettagli; in difetto diventa un problema interpretare l'evoluzione dello "switch()" che governa il parsing.

Saluti