| ??? 06/09/11 11:36 Read: times |
#182552 - volatile sbit may be the problem Responding to: ???'s previous message |
Maarten Brock said:
first if(dn_pressed) is either true or false, the next statement is at label dn1:. So there is no need to evaluate the if statement. Point taken. Without 1st if(dn_pressed) statement also, the program will move to 2nd if(dn_pressed). Thanks. But since dn_pressed is an sbit it is inherently volatile and thus must be read when the code says so. That's why its value is sampled into the carry flag. The next statement is again if (dn_pressed) and is implemented with the jnb instruction. My definitions for dn_key is like #define dn_key P0_6 // Key for decrementing #define dn_pressed !P0_6 // Dn key pressed When I say if(dn_pressed) it is first converted to if(!P0_6) then it is natural to assume it as jnb P0_6. This is what I'm thinking. May be it is happening as you have said. But I'm still doubtful. |
| Topic | Author | Date |
| Compiler variations?? | 01/01/70 00:00 | |
| Fundamental philosophy of High-Level Languges (HLL) | 01/01/70 00:00 | |
| C code | 01/01/70 00:00 | |
| and so what | 01/01/70 00:00 | |
| Stop wondering about the compiler output | 01/01/70 00:00 | |
| Very nice to learn this important matter | 01/01/70 00:00 | |
| Exactly what you wrote | 01/01/70 00:00 | |
| volatile sbit may be the problem | 01/01/70 00:00 | |
| read up on (not) volatile | 01/01/70 00:00 | |
| Look at my profile | 01/01/70 00:00 | |
| Not offence intended | 01/01/70 00:00 | |
| defining P0_6 so that compiler doesn't treat it as volatile | 01/01/70 00:00 | |
| Skip the goto - almost always exists beautiful rewrites | 01/01/70 00:00 | |
| Goto really is a bastard code construct | 01/01/70 00:00 | |
| and therefore ... | 01/01/70 00:00 | |
Will come back with modified code | 01/01/70 00:00 | |
| Wonderful as always! | 01/01/70 00:00 |