06-02-2013 09:46 AM
06-02-2013 09:59 AM
thanks, but I was wondering if it was some better method
06-02-2013 10:52 AM
06-02-2013 10:52 AM - edited 06-02-2013 10:54 AM
Instead of an extra boolean and local variable, you could create a local variable of the gauge and do the comparison in the second loop. Keep it lightweight!
06-02-2013 11:23 AM - edited 06-02-2013 11:33 AM
send it as a bool notifier, no switch involved...
06-02-2013 12:02 PM
Tanks, this is intersting.
At first glance, seems to work, but in fact a strange thing happens, the two LEDs lambegguano with the same frequency, whereas I would like them each with their own. The problem is caused by waiting for the notification from the second cycle. I think I will use the smallest delay in the main loop ( none in the second) and using some math with remainders I can arrange the leds blinking rates. Pheraps it would be better to use queque instead notification.
06-02-2013 12:04 PM
at first glance, seems to work, but in fact a strange thing happens, the two LEDs blinks with the same frequency, whereas I would like them each with their own. The problem is caused by waiting for the notification from the second cycle. I think I will use the smallest delay in the main loop and then I causing the remains as I'm arranging the flashes
06-02-2013 12:16 PM - edited 06-02-2013 12:17 PM
Wire a 200 constant to your wait on notification
06-02-2013 12:16 PM
betobeto33 wrote:At first glance, seems to work, but in fact a strange thing happens
So why did you mark it as solution? Seems way overengineered for such a simple task and, as you noticed, it is constipated. 😄
06-02-2013 01:05 PM - edited 06-02-2013 01:12 PM
Also notice that you can use a single loop running at the greatest common divisor of the different blink rates. Now you don't even need to communicate between different loops. 😄
Here's a quick draft. Modify as needed.