Just throw in a 20 ms delay at the end but inside of your while loop so you don’t starve the processor. Then you’re all set. 100 ms is lethargic.
where exactly in this:
while(1)
{
// check for a button press only if we are not already pressed.
if(vexRT[Btn6U]==1)
{
if(!buttonPressed)
{
// change the toggle state
buttonToggleState = 1 - buttonToggleState;
// Note the button is pressed
buttonPressed = 1;
}
}
else
{
// the button is not pressed
buttonPressed = 0;
}
// Now do something with our toggle flag
if(buttonToggleState)
motor[port9] = 127;
else
motor[port9] = 0;
}
before the last curly bracket
after “motor[port9] = 0;”?
@Barin was correct that you don’t need a delay in your code, @LauraDarkez318 . I didn’t look at it right the first time and thought your first else was complementary to your nested if, not your button press if. You will not need a delay in order to prevent continuous toggling on and off. I tested it as you had it written and it worked fine.
The only other thing I noticed while testing it was that if you use a motor command to turn off your flashlight, you will want to set it at -127 to be off. 0 is half brightness.
BTW, @LauraDarkez318 , good use of commenting in your code!
the vex flashlight registers as reverse, and when i set them to 0 previously it turned them off completely
yes
idk if it changes that because of the specific code
its working. just had to move the starttask to the beginning
if i have the same code but different controls in its own task will the variable names effect eachother?
If you keep the variable declarations restricted to a function/task, then those are local variables handled independently. You’ll get no confusion. If your function/task is accessing global variables, then you might run into problems.
so if they are in isolated tasks then its fine, got it
Feel free to make each instance of a toggle its own method, so that you can just call it in your main loop.
def ToggleLights() {
// code goes here
}
...
ToggleLights();
//lights get toggled
...
I’m generally a fan of simplicity
bool toggle = false;
if(vexRT[Btn6U])
toggle = !toggle;
if(toggle)
motor[port9] = 127;
else
motor[port9] = 0;
Hope this helped
This is, at best, an inconsistent solution. I personally would not even call it a solution.
See here
Yup. @NightsRosario 's solution is basically a 50-50 coin toss. Each time you press the button it might or might not end the way you want it to, assuming those if statements are inside a loop.
So I’m assuming that @Barin was alluding to the fact that not everyone is a ninja and can press the button perfectly every time. That’s a fair argument.
bool toggle = false;
if(vexRT[Btn6U]){
toggle = !toggle;
while (vexRT[Btn6U])
delay(1);
}
if(toggle)
motor[port9] = 127;
else
motor[port9] = 0;
That should fix the problem addressed
While this solves the “ninja” problem, it will hog the CPU, especially if not put in a task. Even if put in a task, the
delay(1)
is simply too short to avoid unnecessary CPU hogging.
Also, this is more personal preference, but I try to avoid tasks (and, by extension, code that requires the task scheduler) entirely. I consider tasks (not to be confused with multithreading), in most cases, to be used simply as a lazy way to implement loops even though a perfectly good infinite loop already exists. Plus, for anyone interested in software design, being able to implement loops without tasks is a good skill to have.
Correct me if I am wrong, but I generally teach people to avoid using delay for anything other than setting the frequency of a loop. For long waits I recommended using [escapable] loops with small wait()s built in. If you use delay for more than that time, it means your robot will literally ignore all commands and processing until the wait is over.
This is why in the toggle I shared, it involves a check for if the button was pressed last time the loop ran.
Edited phrasing
You are exactly right if I interpreted your post correctly.
Small
delay()
s (5-20 ms) serve an important function in both tasks and the main execution block’s infinite loop in allowing other tasks (including built-in tasks like responding to field control) to run.
However,
delay()
does pause the execution of the code in which it is implemented, which is not ideal (except, obviously, for the single short
delay()
to allow tasks to run). One key aspect of the implementing-loops-without-tasks I alluded to earlier is, to achieve what is effectively a delay, using
if
and comparing the current system time to a saved system time that corresponds to when the
delay()
would have started.