Dear all
iam having problem with SWITCH case
switch(aaa) { case '1': LIGHT=1; printf("Light On\n"); break; case '2': LIGHT=0; printf("Light Off\n"); break; case '3': printf("Unknown Command\n"); break; default: printf("New Command\n"); break; }
this code is running in the uvision simulator well fine.
but after compiling its not working with the chip.
same code after removing "default" tag is working with simulator as well as chip fine.
switch(aaa) { case '1': LIGHT=1; printf("Light On\n"); break; case '2': LIGHT=0; printf("Light Off\n"); break; case '3': printf("Unknown Command\n"); break; }
is there any "Target setting" i need to change?
iam using
On chip ROM - Enabled X-Tall - 11.0592 Memory Model - Small Code Rom Size - Large Operating System - None
and in "C51" Option Level - 8 common tail merging Emphasis - Favor Execution speed Compiler control string - BROWSE DEBUG OBJECTEXTEND
thanks in advance.
In what way is it "not working"?
Dear Andy Neil
thats what iam struck up.
iam using the following code to read some ports.
void timer0_int(void) interrupt 1{ if(++int0count == 1000){ pval=P2; pv1=P0_3; printf("Reading = %bx,%bx. \n",pval,pv1); int0count = 0; } }
if iam adding "default" in switch case then its not giving any reply
that switch case iam using in a while loop and in the main()
while (1){ aaa = _getkey(); switch(aaa){ ........ ........
iam going to re analyze the scenario. iam having the doubt like whether its exceeding any code size. or any other setting avoiding from run.
Thankyou for putting time to reply
putting printf in an ISR is a really bad idea!!
Rather that just saying "it doesn't work", you need to fully & completely describe the symptoms: What does happen that you weren't expecting? What doesn't happen that you were expecting? What debugging and other investigations have you done to acount for the difference?
That would fit the symptoms. The default state must generate more printing, increasing the chance for a conflict.
printf() is not re-entrant. you can not use it in an interrupt and main. Plus it is big so it will spend a lot of time in the interrupt. This may cause you to miss receive bytes.
Nonsense - Don't be so boring! Of course you can use printf in an ISR and main - just like you can fill-up a diesel car with petrol.
Doesn't tend to give reliable operation, though...
Thats ok, Give some solution other than using printf in ISR.
i need to send some datas from uC to the computer.
iam working on my previous error, in some more places i faced the problem. iam gathering the information
any feed back on AVR/SPI Flash Programmer? now iam using SPI Flash Programmer 3.7 so far i used labview programmer only.
there it'll erase+program+verify automatically. lock bit we can set in option.
but here iam manually erasing reloading and programming. lockbit also iam setting manually.
iam in some mysterious condition. any way thanks a lot for your people's efforts
Your ISR should do the absolute minimum required to service the interrupt and capture any related data - and nothing else;
You should leave it to your "main" code to deal with transmitting data to the computer.
"any feed back on AVR/SPI Flash Programmer?"
That has nothing to do with any Keil tools, nor even any architecture supported by Keil tools - you need to ask that is a different forum, eg http://www.avrfreaks.net
Thanks For all who shared me the information
now my device is working fine. the problem i found is in wiring area.