I am new to AVR, but i have programmed PICs before, only this time i am doing everything in linux too so you'll guess that i am using avrdude...
My goal for this project is to change a bicolor LED's color depending on a certain state.
By default, the led is RED (if you make the connections right of course), then i want it to go to yellow (which is a quick change between green and red) while the user is holding the button down then on release, it will go to green, then the next time it will turn off.
So, to recap,
LED is red
While i hold the button down its gonna be yellow
When i release it will be green
While i hold the button down again its gonna be yellow
When i release it will be off
While i hold the button down again its gonna be yellow
When i release it will be red (and so on...)
In my actual code, everything works really well sometimes, but sometimes the led gets stuck at yellow and i have no clue why
Any ideas?
Code is on ideone : http://ideone.com/LI9gH
Thanks
I'm guessing you're simply seeing the random generator missing the button changes about 1/3rd of the time, because the debouncing is slightly off. Consider the time spent in different states:
check button
wait 10ms
check button again
if button values differ, update state
if yellow
shine red for 1ms
shine green for 4ms then leave green on
otherwise
set current color
That's your main loop. As you can see, it checks the button in two instants during about 15ms time; and it doesn't compare to the last value for which it updated state, only with the value 10ms prior. Release the button during the 5ms period of "yellow", and allumerAmbre will not reset until the next release that happens to fall in the 10ms period. Also, the yellow wound up 1/15 red, possibly not the mix you intended.
I don't know where the problem is, but I can suggest an alternative approach if that helps. :-)
Because you're cycling through a sequence of LED states, you could merely list them in an array and step along it (wrapping around when you reach the end), updating the LED each time, whenever the button state changes.
EDIT:
Here's an alternative:
colours = [red, yellow, green, yellow, off, yellow]
current button = released
state = 0
repeat
check button
if button != current button
current button = button
state += 1
if state >= len(colours)
state = 0
// showing the colour sets the LED and includes a delay
show colours[state]
Related
Shouldn't this code move the player? It won't animate the player, but it should at least move it...
The top one is when I press Down, the next one is when I press Left, the second from the bottom shows when I press Up, and the last one is when I press Right.
All I want to do is move the player at this point, I'm not going to worry about adding the animations right now. If anyone knows how to help me, I would be extremely thankful!
Update: I just noticed your error codes from the second screenshot now. The issue is likely that you need to turn on physics for the room/object.
Original reply:
What if instead of trying to set phy_position_x/y directly, which GM recommends against, you set the phy_speed_x/y? So for instance move right/left would look like this:
if moveRight
{
phy_speed_x = spd;
}
if moveLeft
{
phy_speed_x = -spd;
}
You may need to have "phy_speed_x = 0;" before the if statements to keep the object from moving when no button is pressed. I don't use the built-in physics system myself so I have not tested this.
QProgressBar works either as busy mode or percentage mode.
But i want to show the both!
In my application sometimes(not always) it takes too long time for just a 1 percent change.
So i want to show some kind of busy indicator effect while showing percentage.
how can i do this? do you have any idea?
you can change your mouse cursor using :
QApplication::setOverrideCursor(Qt::WaitCursor);
but don't forget to restore the old one, once you're done
QApplication::restoreOverrideCursor();
or you can add a second progressbar with more precision
In CUDA Information Tool Window in NSIGHT, under warps , you will get the following table:
Can someone explain me what are the different colored region indicating here?
I could not locate this in the user guide so I am asking here.
If you mouse over the lanes a tool tip will show the state of the lane.
The legend is
Lane/Thread State Color
==============================
Inactive Gray
Active Forest Green
At Barrier Light Sea Green
At Breakpoint Red
At Assert Orange
At Exception Dark Red
Not Launched Medium Gray
Exited Dark Gray
I have filed a bug to update the documentation.
I am developing a magnet effect in my Qt project.There two widgets(Master and Slave).Slave's left border will be moved to Master's right border(that's I called magnet effect) when they are 30 pixels away from each other when Slave is moving,then they enter TOGETHER_STATE.Once they enter TOGETHER_STATE,Slave will be moved when Master is moving,not vice versa.**They enter SEPARATE_STATE when **Slave's left border is more than 30 pixels away from Master's right border when it is moving.As far as I know Teamviewer has similar effect.
One way to implement magnet effect is that move Slave to Master's right border using move function in Slave's moveEvent when condition described above is satisfied. But it will contribute to flicking because move widget in moveEvent will lead to infinite recursion.
Do anyone have any good ideas?Did I make myself understood?
The slider thumbs in my Flex 3 application usually work correctly, but often they seem to become insensitive to mouse downs on what should be thumbPress events.
It turns out that mouseOut events are being fired as the mouse moves away from the edge of the thumb towards the center. The thumb is sensitive to mouseDown events only when it is in the "over" state.
I am seeing the same behavior:
-- Displaying the default thumb rather than my custom class
-- Using a hitArea sprite (I tried a child TextInput sized to cover the thumb with alpha 0).
Can anyone suggest either a fix or a workaround? I can identify the faulty mouse out events, but then don't know how to compensate, for example, by reestablishing the "over" state, or perhaps with programmatic control of the mouse.
Thanks,
Peter
Nevermind, I figured this out myself. The mouse-out events are due to mostly invisible objects in the way -- the result of a workaround from long ago that I forgot about! :-(