hi all.... This is Gaurav Kothari. I want a very small help from you. As i new to programming part, i started my new project of hello world. my lcd prints it perfectly But now i want my lcd to ask the name first and then to print hello and then the name entered. can anybody please me....
So what input facilities do you have?
i have attached a keypad and lcd. lcd is being attached on port1 and keypad on port 0 and 2. i wrote a command printstring("Hello",name); but it shows me a error... too many parameters
Do you have no access to books, or online resources, about C programming?
So "too many parameters" suggests the function can print only ONE string at a time, no? You could look at the definition of the function too, if it's not clear from the documentation, or the error.
{ char string[64]; sprintf(string, "Hello %s",name); printstring(string); }
This is my code.... .. unsigned char time[3]={"00"}; void main() { unsigned int i,k;
lcdcmd(0x38); lcdcmd(0x0F); lcdcmd(0x06); lcdcmd(0x01); { printstring("ENTER TIME:"); lcdcmd(); i=0; do { time[i]=keypad(); lcddata(time[i]); i++; } while(i!=2); i=0; lcdclear(); printstring("TIME SET", time); msdelay(200); } }
This is my code.... ..
unsigned char time[3]={"00"}; void main() { unsigned int i,k; lcdcmd(0x38); lcdcmd(0x0F); lcdcmd(0x06); lcdcmd(0x01); { printstring("ENTER TIME:"); lcdcmd(); i=0; do { time[i]=keypad(); lcddata(time[i]); i++; } while(i!=2); i=0; lcdclear(); printstring("TIME SET", time); msdelay(200); } }
"but it (sic) shows me a error..."
What do you mean by "it" ?
I guess you mean that this is a Compiler message when you build your code?
"too many parameters"
So use fewer parameters, then!
yes it give me error when i try to build... fewer parameters.... how can i.... do i need to change the code
"it give me error"
You still haven't said what "it" is !!
Nor when or where this happens!
"fewer parameters.... how can i"
Do you understand what "parameters" are in a 'C' function call?
"fewer" means "not so many"; eg, one parameter is fewer than two parameters.
"do i need to change the code"
Clearly, yes!!
This is my code....
It rather obviously is not your code, but rather somebody else's code that you, well, let's call it "picked up", somewhere, but you don't understand it at all.
So guess what: if you want to learn programming, you'll actually have to do just that: learn. And no, just copy-pasting random stuff you don't understand is not the same thing.
And no, just copy-pasting random stuff you don't understand is not the same thing.
Very true. But it doesn't seem to have harmed the income of some consultants I've had the (mis-)fortune to deal with over the years.
Well there's sprintf() and strcat(), see my earlier post.
this is a good example of the fact "if you can't code it yourself, downloaded code is worthless"
It's also an example of bad code found on the net.
It isn't easy for a reader to read and understand "magic" like the following:
lcdcmd(0x38); lcdcmd(0x0F); lcdcmd(0x06); lcdcmd(0x01);
And writing code that demands that the reader always cross-correlates every statement with one or more datasheets isn't a good way to get code that is easy to maintain.
That comment could easily be turned around.
Finding code like that can be very good at getting the reader to go through the data sheets and determine how the code is doing its job (and get a better understanding of it).
Having well defined names can be as equally useless if the code does not work and can be misleading for a reader who then blindly believes that the code of each line is correct.
The true important skill is to have the ability to understand what is being downloaded.
In an ideal world, yes. But there have been a surprisingly high number of occasions where I've found a bug in an incorrectly specified manifest. So there, the fact that it was pretty was a definite distraction and time waster.
"Finding code like that can be very good at getting the reader to go through the data sheets and determine how the code is doing its job (and get a better understanding of it)."
But in reality, not many seem to bother to try to know about why or how something works. All focus is on the final result with the least amount of own time invested, and where the code represents magical formulas that must not be touched.
"Having well defined names can be as equally useless if the code does not work and can be misleading for a reader who then blindly believes that the code of each line is correct."
The blind will fail whatever the code looks like. But we don't spend our engineering skills for the people who don't care how things works, since we'll have to at least hope that anyone who will later maintain the code will be skilled in the craft. And we then don't want to be embarrased when they start reading the code.
"In an ideal world, yes. But there have been a surprisingly high number of occasions where I've found a bug in an incorrectly specified manifest. So there, the fact that it was pretty was a definite distraction and time waster."
Beginners has a tendancy to go one of two routes. Either zero comments. Or they spend their time to "completely" document what every single code line does in natural language - so the first time they modify the code their comments and their code will start to tell two completely different stories. All code should have meaningful symbol names - but the comments should concentrate on why something happens, instead of telling other developers that a = b+c is adding two numbers and assigning to a third variable. Comments are obviously of no use if they lie.
But a big problem here is that beginners are bad at figuring out what is well crafted code, and what isn't. It isn't until they have spent a significant amount of time working with other peoples code they will start to figure out how huge difference there might be in amount of time needed to modify the code if it's well crafted or not.