We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi friends,i must have you help for this Cereous problum,
i have a code about a digital thermometer using the proc baord. I have compiled this code in microvision ide And the code is compiled and Built with some warnings and it works very Well.
The point is that i have built the circuit in time and it works perfectly.
the code isthis
int wait_1second ( void) delay { int delay_count ; delay_count = 100000; label: delay_count = --delay_count; if ( delay_count > 1 ) goto label; end_label: } }
I burn the proc whith the .hex generated and my LCD just show squares and charactors .
I have written the same code using other one and it works perfectly, i don't use assembler, thats the reason why i'm here asking for help. I put this circuit in files .asm & .hex for you to see.
Thanks in advance
1) Get a book about the C programming language.
2) Stop using labels and goto to create loops.
3) Don't use a counted loop, but instead use a timer to keep track of the time.
4) "I have written the same code using other one and it works perfectly" - what is "other one"?
Where to start? There are lots of potential problems here.
Your delay_count variable is only a 16 bit integer.
Your code achieves nothing, so the optimiser might optimise it out.
The function declaration is wrong.
delay_count = --delay_count; : Why not just delay_count--;
Labels have no place here, (use a while loop.)
Your function is declared as returning an int, but doesn't.
Hello Spur Sohel,
You are putting too big a number into the int variable. The biggest is 32000 and you are putting in 100000.
Change the int to long and it will work.
Janice
hi janice,
it works pefectely
thanx; i o u 1
If that's what you think, then you are seriously deluding yourself, I'm afraid!
A High-Level Language (HLL) such as 'C' gives you absolutely no guarantee whatsoever as to how long any particular set of source statements will take to execute - but your wait_1second functions relies completely upon it!
Therefore, your program is only working by pure luck - it might take just one, small, apparently unrelated change to break it completely!
As has already been said, do not use 'C' software loops for timing delays! For short delays, it might be OK to use an assembler delay loop; For delays on the order of a second, you should almost certainly be using a hardware Timer.
See: www.8052.com/.../read.phtml
look, you have no idea what you are doing. you are dangerous. you are sloppy. you are hopelessly unaware of the possible consequences of your actions. you are potentially a danger for society. what makes you think your code works perfectly? looks pretty lousy to me!
looks pretty lousy to me!
<code>delay_count = --delay_count;</code>
Yeah I think one of my eyeballs just exploded.
A pretty awful example:
delay_count = --delay_count;
But a senior team member I had the (mis-)fortune to work with produced a function similar to this:
bool Foo(void) { if ( TestCondition1() ) return FALSE; if ( TestCondition2() ) return TRUE; return 2; }
The really worrying thing is that he refused to see any problems with the return values.
And I ended up being the unfortunate sucker who had to maintain his projects when he left!
Wow I'm not sure weather to say "that's amazing" or "that's dismaying"
However most if not all programmers are somewhat unaware of there own mistakes. It is the same reason why one cannot proof read there own documentation safely (it just doesn't work because your BRAIN fixes the problem without you noticing it as you know what you said).
It would be great if one had used a language for 10 years and new it by heart, however new programmers pop up every day. Doing the same mistakes the prior generation warned them NOT TO. (Some think they are even clever.) Back to the point, it's very difficult for someone to see something wrong with there own code. This is why sometimes it's good to flow chart what your code is doing and then ask yourself "does this make sense"?
hence the ancient phrase "a man is always right in their own eyes"
Stephen
A case in point - excellent illustration!
;-)
I take it "senior" wasn't his job position, but a reference that he had passed his "best before" date...
Don't everyone want an autopilot who wants to roll the plane upside-down if you cross the north pole?
"...he had passed his "best before" date..."
The work he left indicated that there never was a 'best' period.
It should be noted that he was employed in a period of the deparments history where someone was considered talented enough to be a firmware coder if that person possessed a degree - Regardless of what subject that degree was in.
He had a degree in media studies!
I think the prototypes of the F-16 had that, and if I am not mistaken - the F-22, too! And I'm sure that flight control systems for figher jets are written by skilled people.