|
Say I have a set of 8 LED's and need to send a byte as a unified command to set on/Off for a LED
1 LED = 1 bit (0=Off , 1 = On )
I am having trouble combining two cases
lets consider just LED 0 that corresponds to bit 0
I work according to a input command
Case 1 :
Say a command for LED0 is ON
What I need to do is the following :
Get the Status of 8 LEDS in a byte
my Mask = 0x01
OR this Mask with the byte received .
Send the Byte
--------------------------------------
Case 2
Command for LED0 is Off
What I need to do is the following
Get the Status of 8 leds in a byte
my Mask = ~(0x01)= 0xFE
AND the result with the byte received .
Send the Byte
IS there a way I can combine both cases
Like I want to eliminate the difference in AND / OR and have a single bit operation .
I know I can do all this using an IF else. I was wondering if this can be achieved using bit operations .
|
|
|
|
|
I am not sure what you are trying to do. Do you want to test the status of LED0? If so just AND it with 0x01. Are you trying to set the status? Then I think you need both cases AND to turn it off and OR to turn it on.
John
|
|
|
|
|
In effect, you have one operation for turning a bit/LED on and a second operation for turning a bit/LED off, and you are wanting to perform both operations on a set of bits/LEDs at the same time. Your operations are for "change."
If you know the "new" status of all 8 bits/LEDs, then it is easy to just send all 8 bits together and be done with it. If, on the other hand, you know the "new" status only for some of the 8 bits/LEDs, then really you do know the "current" status for all 8 bits/LEDs, since some will be from the "previous" state and others will be from the "new" state.
In any case, since at that point you know how all 8 bits/LEDs should be displayed, just send out the new settings and don't think about how they have "changed." Think of the operation as a "set."
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
Hi,
Here it goes: the user of my program click a button of a toolbar. Then a function is executed corresponding to this button.
I am using a document/view architecture with VC++ 6 and I am able to change the state of the button (i.e. grayed, checked…) only once the function is finished.
I would like to be able to update the state of the toolbar button of menu while executing the function:
<br />
void CMyProjectView::OnButtonDown() <br />
{<br />
<br />
<br />
<br />
}<br />
Thanks,
Rno
|
|
|
|
|
|
I am looking into it but it is not working...
Do you have another suggestion?
Thanks,
Rno
|
|
|
|
|
1) Create an OnUpdateButton() for the button you want to disable.
2) Type in pCmdUI->Enable(FALSE); ( or pCmdUI->Enable(); ).
3) Place a break point on step (2).
4) Run your application in debug and start stepping.
OR
1) Goto the MFC\SRC directory
2) Open BARTOOL.CPP
3) Search for CToolCmdUI::Enable
You should have no problem figuring it out from there.
I hoped this helped!
INTP
|
|
|
|
|
I have the following code:
1. for(int i = 0; i < 20; ++i)
2. if(!m_aSoftwareGains[i].Load(pFile))
3. return false;
4. m_bSoftwareGainsLoaded = true;
I didn't put in the seemingly extraneous braces.
Rather than running the following lines:
1,2,1,2,1,2,1,2...1,2,4
it runs:
1,2,4
Can anyone explain to me why this is?
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
What? The compile should output an error message. Insert the braces.
Kuphryn
|
|
|
|
|
kuphryn wrote:
What? The compile should output an error message. Insert the braces
why ? syntax is ok. But inserting brackets is still a good idea !
~RaGE();
|
|
|
|
|
A good idea, yes. But not required. It should execute the way I want, right?
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
Yes. Have you put a breakpoint on statement #4 and noted the value of 'i' at that point? Is it >= 20?
Can you reproduce this problem in a smaller program such that it could be posted here?
|
|
|
|
|
i = 0
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
As soon as my build finishes, I'll try to reproduce it in a postable version.
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
hmm..
does it work correctly when you use braces?
and what compiler are you using?
|
|
|
|
|
Works fine when I use braces.
Using VC++ 6.0 SP5.
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
Rage wrote:
But inserting brackets is still a good idea !
I always insert the braces. It makes the code easier to read and avoids me forgetting to add them when I add another statement to the for loop. As for the error I can not see why...
John
|
|
|
|
|
To me, the code is "cleaner" without the braces, but I understand it's just a style thing.
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
"just a style thing"?
Read a good book on defensive programming - "Code Complete" comes to mind. Your "style" is prone to errors.
|
|
|
|
|
John M. Drescher wrote:
I always insert the braces
I'll to that!
I prefer to wear gloves when using it, but that's merely a matter of personal hygiene
[Roger Wright on VB]
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
[Rich Cook]
|
|
|
|
|
I sounds like you are single steping through the code with the debugger.
1. for(int i = 0; i < 20; ++i)
2. if(!m_aSoftwareGains[i].Load(pFile))
3. return false;
4. m_bSoftwareGainsLoaded = true;
<pre\>
When single stepping it will appear to go 1,2,4,1,2,4,...,1,2,3.
<pre>
1. for(int i = 0; i < 20; ++i)
2. {
3. if(!m_aSoftwareGains[i].Load(pFile))
4. return false;
5. }
6. m_bSoftwareGainsLoaded = true;
<pre\>
Now It should appear to be 1,3,5,1,3,5,...,1,3,4.
INTP
|
|
|
|
|
Yes, I discovered this after digging through the assembly. Oops.
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
Are you sure you don't have a ";" at the end of line one?
I've tried to reproduce the difference in behaviour, but with no success. When you look at the disassembly, it seems to be identical with or without braces.
Haakon.
'Problems worthy
of attack
prove their worth
by hitting back.'
Piet Hein
|
|
|
|
|
It was a user problem. I assumed the problem was there, and that biased my testing.
I stepped through, and when the code returns from the call (line 2), the little yellow arrowhead points to line 4. THAT DOESN'T MEAN THAT IT IS THE NEXT INSTRUCTION TO RUN! I must have seen that in my testing, wondered what the hell was going on, and stopped the debug.
I too traced through the assembly, but made the same mistake - didn't trace through far enough.
Oh well.
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
No problem.
If we didn't learn anything, you certainly have.
H.
'Problems worthy
of attack
prove their worth
by hitting back.'
Piet Hein
|
|
|
|