in the simulation program running smoothly, but when the diwnload to the target is not working as it should. .
The following source code
#include <LPC214x.H>
void delay(unsigned int lama) { /* My PCLK of Timer0 is 12Mhz */ unsigned int d; for(d=0;d<lama;d++){ T0PR = 9999; // Prescale Register = 9999 T0MR0 = 1200; // Match Register = 900 T0MCR = 0x00000004; // Stop on MR0: the TC and PC will be stopped // and TCR[0] will be set to 0 if MR0 matches the TC. T0TCR = 0x02; // Counter Reset T0TCR = 0x01; // Counter Enable while(T0TC != T0MR0); T0TC = 0; // TC kembali ke 0 } }
void delay_ms(unsigned int lama_1) { /* My PCLK of Timer0 is 12Mhz */ unsigned int d; for(d=0;d<lama_1;d++){ T0PR = 999; // Prescale Register = 9999 T0MR0 = 12; // Match Register = 900 T0MCR = 0x00000004; // Stop on MR0: the TC and PC will be stopped // and TCR[0] will be set to 0 if MR0 matches the TC. T0TCR = 0x02; // Counter Reset T0TCR = 0x01; // Counter Enable while(T0TC != T0MR0); T0TC = 0; // TC kembali ke 0 }
}
void delay_ns(unsigned int lama_2) { /* My PCLK of Timer0 is 12Mhz */ unsigned int d; for(d=0;d<lama_2;d++){ T0PR = 1; // Prescale Register = 9999 T0MR0 = 12; // Match Register = 900 T0MCR = 0x00000004; // Stop on MR0: the TC and PC will be stopped // and TCR[0] will be set to 0 if MR0 matches the TC. T0TCR = 0x02; // Counter Reset T0TCR = 0x01; // Counter Enable while(T0TC != T0MR0); T0TC = 0; // TC kembali ke 0 }
int main(void) {
unsigned int i; IODIR1 = 0x00FF0000; // set all ports to output
while(1) {
for(i=0;i<4;i++){ IOSET1 = 0x00010000; //set output pins delay_ns(200); IOCLR1 = 0x00010000; //clear output pins delay_ns(200); }
delay_ns(19800);
} }
please enlightenment?!
1) Why didn't you bother to tell some more information than just saying that it doesn't work? Haven't you done any debugging to narrow down what is wrong?
2) Why do you reinitialize the timer for every delay call? You can keep the timer free-running and just look at the counter values.
3) You perform an exact compare for the timer loop. What makes you so sure that your comparison code will manage to catch every single tick of the timer? What if you miss the specific tick - then the timer needs 4 billion more ticks before you get a second chance.
4) You have a function that claims to set up delays in ns resolution - but what errors? How many nanoseconds does it take to initialize the timer before you can even start with the actual time-keeping?
5) You want to toggle some processor pins. Why not select processor pins that can be directly toggled by the timer hardware, without any intervention from the software? That would give you pin toggles without the latency and measurement errors from all the clock cycles spent between each timer delay.
6) Do you really think this is a problem for the forum, and not something you should have been able to fight on your own? Programming is to a big part a question of figuring out a good design. And the next big part is to debug the code. Actually writing in the source code statements is the tiny part. Are you spending any time with design and debugging, or just spending time writing source code?
6) Do you really think this is a problem for the forum, and not something you should have been able to fight on your own? The time "this is a problem for the forum" is when you have narrowed the problem down to something you can describe as a specific problem
Erik
"The time "this is a problem for the forum" is when you have narrowed the problem down to something you can describe as a specific problem"
I thought the thread title "Not working" did describe a very specific problem.
I always tell the doctor "Not working". Same if I turn in my car. After all, the doctor or car mechanic are schooled and payed to be able to find errors. Why give them hints?
www.eetimes.com/.../Developing-a-good-bedside-manner
Just a very unrelated question. The quoted article contains this sentence: "That's a wonderful thing compared with the three-day rebuild time we experienced in the early days of the embedded revolution. But it's too often used to displace thinking."
How many have manged to work with embedded programming where the build times have been even close to that time?
I don't think I have ever seen build times higher than 10-30 minutes. And similar times for reprogramming the device. So maybe worst-case total spin time of 1-2 hours assuming the code changes didn't require lots of editing or thinking.
Hyperbole?
" here: http://www.keil.com/forum/19564/
when the king of diamonds were just a jack embedded computing used minicomputers.
I recall assembly of 3k of code on a PDP-8 with a 10cps teletype taking 8 hours (2 passes of a spool of paper tape).
sorry in advance. . . I'm just learning to program the microcontroller. . . so forgive if you are not pleased. .
"sorry in advance. . . I'm just learning to program the microcontroller. . . so forgive if you are not pleased."
So. 1) Have you walked through my individual items in my first post? Your response?
2) Is it relevant if you have just started to learn programming microcontrollers? In how many other areas of the world would "not working" be a good description of a problem? Wouldn't you agree that if you are stuck, you are much more likely to get good answers if you tell where you are stuck, and what you have tried. What you expected to happen, and what really happened? What you have thought could be causing the problem, and how you have tried to check if it is so?
www.catb.org/.../smart-questions.html
Some tips on debugging:
www.8052.com/.../120313
" href= "http://www.danlhenry.com/caps/keil_code.png">www.danlhenry.com/.../keil_code.png
okeh I apologize in advance. . .
I will not repeat again. . .
So did you understand the problems with your code?