This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

rfreader

#include<reg51.h>
void boud_rate()
{
        SCON = 0x50;
        TMOD = 0x20;                /* timer 1, mode 2, 8-bit reload */
        TH1  = 0xFD;                /* reload value for 2400 baud */
        TR1  = 1;
        TI   = 1;
}
char serial_receive()
{
    char chr;        /* variable to hold the new character */
        while (RI != 1) {;}
        chr = SBUF;
        RI = 0;
        return(chr);
}

void main(void)
{

        boud_rate();
  unsigned char rx_data;

  for(;;)
  {
    rx_data = serial_receive();

    switch(rx_data)
    {
//      case '1': open_door();
          case 0067892341 : open_door();
        break;
//      case '9': open_door();
       case 0045780034 : open_door();
        break;

      default: dont_open();
    }

    proper_delay();
  }
}

errors

'rx_data':undefined identifier
 illigal octal digit

please tell me how to overcum these errors

Parents Reply Children
  • But I just told you the processor have no binary or decimal or octal or hexadecimal.

    A number is a number.
    Binary just means that the number is presented in base 2.
    Hexadecimal means the number is presented in base 16.
    But the number 17 is still the number 17.

    If your device sends the codes as a sequence of ASCII characters and your hard-coded keys area also sequences of ASCII characters, then you obviously don't need any conversion.
    If you decide to try to store the keys as numbers (bad, since they can be larger than what you can store in a long int), and the connected device sends in codes as ASCII then you will obviously have to convert the stored numbers into ASCII strings or convert received ASCII data into numbers. But your examples suggests that your keys are already arrays of ASCII digits and the UART receives sequences of ASCII characters.

    How long are you going to ignore my question of when you plan to implement synchronization with newline characters, since your code currently just count received characters and assumes that they represent a key code. And your code ignore the off-by-one between each code, when you receive a newline character and most probably considers it to be the first character in the next key...

    Problems seldom go away just because you ignore them.

  • do i need to convert the binary no received in SBUF to decimal or ASCII and then i should compare with the other no?

    'maybe' is the only possible answer

    Erik

  • do i need to convert the binary no received in SBUF to decimal or ASCII and then i should compare with the other no?

    the "debugging method" of throwing some code together and posting it on a forum is not very efficient and will, probably, never get you to ways end

    If you had even an inkling of what you had coded for you would not ask the above question.

    do some REAL debugging (if you are even able to do so) and post the results, do not just keep posting irrelevant questions

    Erik

  • Actually, the processor has only binary!

    The processor is just a big chunk of digital hardware; all it knows is electrical signals which can be in one of two states - a so-called "binary" system.

    The processor doesn't actually even know about numbers - we just choose to group these elctrical signals togerether, and interpret them as numbers...