#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
How about:
unsigned char rx_data; boud_rate();
#include<reg51.h> void baud_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) { #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) { baud_rate(); unsigned char rx_data; for(;;) { rx_data = serial_receive(); switch(rx_data) { case 0067892341 : open_door(); break; case 0045780034 : open_door(); break; default: dont_open(); } proper_delay(); } } errors rx_data:undefined identifier illigal octal digit
Sorry, but no. You haven't debugged your code. It does not work when you step through it either.
You don't need to step through in a debugger - enough to follow the flow with pen and paper and try three different alternatives. Code matching first acceptable key. Code matching second acceptable key. Code not matching any key.
for (i = 0; i < ACCEPTABLE_INPUT_COUNT; i++) { j = strcmp(acceptable_inputs[i],input); if (j==0) { lcd_printxy(1,8,"yes"); input_pos=0; } else { lcd_printxy(1,1,"no"); input_pos=0; } }
How did you decide that if your input fails the test against the first code, it's a failure? Don't you think you need to iterate through the full array and first when all known codes mismatches, it's a fail?
Did't you notice that when you did your stepping through the code?
Why are you in such a hurry? The logic is simple. But to get something to work, you need to have the patience to work out all acceptable and unacceptable paths and verify that they they happen as expected. Any time you take a shortcut, you cut yourself. It is costing _you_ a lot of time, that you don't work a bit slower and really try to follow the logic of your code.
for (i = 0; i < ACCEPTABLE_INPUT_COUNT; i++) { j = strcmp(acceptable_inputs[i],input); if(j==0) break; } if (j==0) { lcd_printxy(1,8,"yes"); input_pos=0; } else { lcd_printxy(1,1,"no"); input_pos=0; }
as you said i am getting problem in this part of code. it is receiving all the characters but not able to compare, it is printing "no" on the lcd.. i am not able find out why it is happening so, Sir please help me out. which step of the above code should be corrected.
@Andrew Neil
Why don't you write a bit of the code at a time and test it before doing the next bit. You stand a chance of creating a whole project that works properly.
I thought the strings from the RFID reader ended with a newline. If so - how do you handle the line breaks?
And what is the result of your debugging? Soon one month later. Own time debugging the individual parts of the program would have made you finish this project about three weeks ago. Of course, that would have required you to take regular looks in a book about the C language, when the debugger showed you that a statement didn't do what you thought it would do.
Own time debugging the individual parts of the program ... take regular looks in a book about the C language if you need to do that then what are fora for?
Of course, I AM being Ironic.
Erik
Pradeep,
Let's try taking a step back. When you create code, how do you normally test it or decide that it is working? Do you look over it and evaluate if it's correct or not? Do you press the simulate button and step through the program, watching how the code handles each statement? Do you program it directly to the chip and observe the results?
I think what everyone here is trying to help you with is not just how to solve the problem with THIS code but to teach you how to solve code problems without needing a forum to come to with each issue. The more familiar you are with the tools, the more you will be able to determine WHERE the problems are in your code. Maybe you won't be able to solve everything on your own right away but it should help you come back to the forums with the problem area of the code (without posting ALL the code) and give more information about what the problem is (rather than "I have a problem, please help").
So, at this point, can you describe how it is that you evaluate whether your code is working?
i am very sure that when i debug i am getting the output but when i download it and read the input using rf-reader its is not comparing. i even tested the rfreader on the hyper-terminal it is reading the correct values.. so the problem might be that i may be receiving some converted values like hexadecimal or octal digits that i dont know... but i am sure that i am not receiving the decimal digits in to the SBUF..
what will be the output of rs232? will it be in the form of hexadecimal or decimal? because i have displayed the no which i am receiving.. what i have done is i gave the input through flash magic(flash magic-tool-terminal). for 'a' i am getting the display as 02, for p i am getting the display as 128 etc ... i not getting what these no's are?
try to understand my problem and help me out
There are no binary, octal, decimal or hexadecimal values - there are just values. Octal is a way of _presenting_ a number. But the value 123 is still the value 123 even if you decide to express it as 7b hex or 173 octal or 1111011 binary.
When will you take care of the newline characters that I have mentioned to you several times?
The output of RS232 is a series of positive and negative voltage levels; in that sense, it is "binary" - meaning, "a system that can take one of two values at any one time"...
www.lmgtfy.com
do i need to convert the binary no received in SBUF to decimal or ASCII and then i should compare with the other no?
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.
'maybe' is the only possible answer
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
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...
Ok first let me be very clear with my problem.
a. the while(RI != 1) ; loop never exits when I hook it up to my RFID reader. possible problems: faulty wire? Since I can read(using another wire) from the RFID reader to the "Terminal" screen in FlashMagic, and read in digits in the format: "$1234567890"(The '$' in this is confusing me, I still don't understand if its a garbage symbol, or a symbol of importance OR a start-transmit SIGNAL)
b. Secondly if its an output of significance is it ASCII character?(7bit ascii or 8bit ascii?)
c. I tried pushing keyboard buttons in the terminal hooked up to a USB to SERIAL converter. HOPING that I send ASCII values and check/debug my code IN-REAL-TIME. To my surprise, the values are /not/ ascii conformant(which don't obey the ascii table AKA garbage). Is it coded in another format? If yes which.. if no - WHY am I getting WRONG values?
Hope this cools people off here. I have come here to gain knowledge from the "GURU"s, not be flamed for my post. I am NOT a troll if that's your concern.
a simple check is to transmit 'U' (uppercase U) and scope on it. The frequency of the square wave will be 1/2 the baudrate
Unfortunately, I have no Oscilloscope (too expensive in India). I will have to debug this by logic.. or math?
although, I can make my own Software-Based Oscilloscope and see the readings. :-/
Here's a cheap alternative:
http://www.saleae.com/logic
from http://www.saleae.com/logic :"A large fraction of practical, real world applications run at less than 10MHz, and Logic is ideal for these" When did you last see an enbedded app running at less than 10MHz? Of course if you were to buy something for the sole purpose of seeing your UART output, the thingy would be OK. when salespeople are pushing new stuff they speak of "less than 33MHz is outmoded", when they peddle slow stuff they speak as above,
PS I do not know anything that logic (lowercase 'l') is not ideal for.
Unfortunately, I have no Oscilloscope (too expensive in India). I will have to debug this by logic.. or math? try here http://www.keil.com/c51/baudrate.asp
Depends on the kind of stuff you do with embedded. Most embedded apps I did in the past were only 1MHz using at Atmel chip as it was mainly hobby related stuff. It works fine for most Atmega chips using the AVR. it will work fine for any UART based stuff. Yes, it won't do a lot of high speed apps over 10MHz but at that point, you'd just buy a better scope.
So, if scopes are too expensive in India and he needs something to do basic testing, why wouldn't this be a worthwhile solution for him? Do you have a better suggestion?
there is nothng worse than an instrument that show a false picture.
If you consider yourself 100% qualified to tell when a given instrument show a false picture (e.g. not showing a 5ns Glitch on a strobe) then maybe, just maybe, you will get some use of a "hobby" instrument.
THUS, hooking a 10MHz unit to the UART will show a totally misleading picture if there are reflections on the line og the 100ns type (YES, I have seen that killing transmission)
To work efficiently with electronics you need instruments that show anything that is wide and tall enough to make your circuit react (for most small embedded 2V and 5ns will do)
Understandable but, as you mentioned, it's very likely a logic issue rather than a reflection issue at this point. He needs some way to be able to visualize what's going on. You are right that he's going to need a scope if he wants to pick those things up but he might not actually need that (and if it's a non option, which it sounds like it is, he either needs to find an alternate tool or get better at analyzing logic errors, which it doesn't appear is going to happen at this point either).
From what I see, this is a reasonable option.
Here is another product (i haven't used this one but if I remember correctly, it got pretty good reviews). Their top model goes up to 100MHz but it's significantly more expensive than the Salae one (which I have used and works for logic debugging. I personally have found it to be pretty accurate, but then again, the signals I've worked with have been pretty clean. i don't know much about AC noise in India).
http://www.usbee.com/rx.html
What you say makes sense but at this point, I think he just needs a tool to help him find the issue on his own rather than rely on others to debug it for him. I think these would help him and they're not too expensive.
You must be the only person in the history of humanity who uses an instrument of 100% fidelity.
All instruments show a false picture, some are more false than others. No instrument ever showed, or will show 100% fidelity.
I don't really agree with the statement that microcontroller solutions often requires very fast instruments.
Most microcontrollers have a nice integrated clock oscillator. Either the processor runs from an internal RC oscillator, or it makes use of an external crystal and then potentially steps up the frequency internally.
But few people here have issues that the oscillator doesn't run as expected. And most microcontrollers used by beginners have all memory internally, so no fast address, data or control signals.
What then remains are JTAG interface, GPIO and peripherial-specific pins. The UART is seldom run at very high speeds. The microcontroller is often master for SPI communication, allowing the SPI speed to be reduced if needing to look at the signals. I2C don't need high speeds. ADC is an input peripherial where the majority of testing can be done at way less than the maximum bandwidth of the ADC. JTAG can be tested at a lower speed.
So even very cheap USB-connected oscilloscopes with just 1MHz bandwidth and a few Msamples/second can solve most issues people have with their microcontroller designs. It really is very seldom that there are ringing etc on signals that are the big issue, so it really is very seldom people do need really good gear to look at actual signal shapes.
All instruments show a false picture, some are more false than others. No instrument ever showed, or will show 100% fidelity. sure, 100% is not reachable, I atually had an experience in the old TTL/455 days when the only scope that worked for a given glitch was the "DNA scope" We had to reason out way to where and what the glich was. HOWEVER, the more you see, the better off you are and buying something that is LIKELY to be "infidel" is not a good idea.
"All instruments show a false picture ..."
What you meant to say was: All instruments show a true picture of something that may be a misrepresentation.
View all questions in Keil forum