Go Down

Topic: Switch case variable not updating (Read 609 times) previous topic - next topic

DKWatson

Change,
Code: [Select]
void loop()
{
    Serial.println(visual);
    CycleVisual();
    Visualize();
    delay(10);
}
to
Code: [Select]
void loop()
{
    Serial.println(visual);
    CycleVisual();
    delay(10);
}
and
Code: [Select]
void CycleVisual()
{
    if (digitalRead( BUTTON_1 ) == LOW )
    {
        visual++;
        if (visual > VISUALS) visual = 0;
        delay(350);
    }
}
to
Code: [Select]
void CycleVisual()
{
    if (digitalRead( BUTTON_1 ) == LOW )
    {
        visual++;
        if (visual > VISUALS) visual = 0;
        visualize();
        delay(350);
    }
}
Live as if you were to die tomorrow. Learn as if you were to live forever. - Mahatma Gandhi

NaCl19

#16
Sep 26, 2018, 04:39 am Last Edit: Sep 26, 2018, 04:47 am by NaCl19
This caused the animation speed of the Sparkle() to decrease immensely and the visual counter still does not update correctly  :smiley-sweat:

Edit: It seems as though the counter gets stuck in the RunningLights()

DKWatson

#17
Sep 26, 2018, 04:53 am Last Edit: Sep 26, 2018, 04:54 am by DKWatson
Purely for test, comment out CycleVisual() in loop(), thereby eliminating the button from the equation.

Cycle through visual in its place with a nice delay so you can see what's happening. So change
Code: [Select]
void loop()
{
    Serial.println(visual);
    CycleVisual();
    Visualize();
    delay(10);
}
to
Code: [Select]
void loop()
{
    Serial.println(visual);
    //CycleVisual();
    visual = ((visual + 1) % VISUALS);
    Visualize();
    delay(1000);
}
and see what happens.
Live as if you were to die tomorrow. Learn as if you were to live forever. - Mahatma Gandhi

NaCl19

The counter still gets stuck and the visual sticks to RunningLights() with no update.

However, I was able to cycle completely through the visuals by changing:

Code: [Select]
void RunningLights(byte red, byte green, byte blue, int SpeedDelay) {
  int Position=0;
  for (int i=0; i<LED_TOTAL; i++){
  Position++;
  for(int i=0; i<LED_TOTAL; i++) {
    setPixel(i,((sin(i+Position) * 127 + 128)/255)*red,
               ((sin(i+Position) * 127 + 128)/255)*green,
               ((sin(i+Position) * 127 + 128)/255)*blue);
    }
    strand.show();
    delay(SpeedDelay);
  }
}


To:

Code: [Select]
void RunningLights(byte red, byte green, byte blue, int SpeedDelay) {
  int Position=0;
  Position++;
  for(int i=0; i<LED_TOTAL; i++) {
    setPixel(i,((sin(i+Position) * 127 + 128)/255)*red,
               ((sin(i+Position) * 127 + 128)/255)*green,
               ((sin(i+Position) * 127 + 128)/255)*blue);
    }
    strand.show();
    delay(SpeedDelay);
}


This caused the RunningLights() animation to basically not "move" like it should, but I was able to restart the visual counter. Is it getting stuck in one of those 'for' commands?

westfw

#19
Sep 26, 2018, 06:02 am Last Edit: Sep 26, 2018, 06:03 am by westfw
Quote
Code: [Select]
DDRB &= ~(1 << BUTTON_1);
  PORTB |= (1 << BUTTON_1);


is how you set a pin for INPUT_PULLUP.

Knowledge is never a bad thing, getting hung-up on Arduinoisms, not applicable elsewhere in the real world, is.
Meh.  I'm with TomGeorge.  "pinMode(pin, INPUT_PULLUP)" is clear, obvious, and portable to any device that implements internal pullups in some way (perhaps with a bit of effort.)

Using digitalWrite() while the pin is in input mode, or writing to PORT/DDR registers directly, is utilizing an device-specific and not very elegant property of SOME AVR chips, and it's extremely un-obvious to any non-expert reading the code.

(Did you know that the SAMD chips have an entirely different way to enable pullups, but go to significant expense inside digitalWrite() to duplicate the AVR behavior?  That's one of the reasons that digitalWrite() on the Zero isn't 3x faster than Uno's digitalWrite(), despite the 3x higher clock rate.  Grr.)

I wonder how long we'll have Arduino Libraries doing "things" in the pre-Arduino-1.0 ways :-(



DKWatson

I wonder how long we'll have Arduino Libraries doing "things" in the pre-Arduino-1.0 ways :-(
Until someone gets around to changing? :smiley-sleep:
Live as if you were to die tomorrow. Learn as if you were to live forever. - Mahatma Gandhi

westfw

The problem for library or example authors is that while

Code: [Select]
  pinMode(pin, INPUT_PULLUP);

is much better/clearer than

Code: [Select]
  pinMode(pin, INPUT);
  digitalWrite(pin, HIGH)


it's not so much better than

Code: [Select]
#if (ARDUINO >= 100)
  pinMode(pin, INPUT_PULLUP);
#else
  pinMode(pin, INPUT);
  digitalWrite(pin, HIGH);
#endif



Code with a lot of #if clauses in it is really awful to read :-(

boolrules

#22
Sep 26, 2018, 11:39 am Last Edit: Sep 26, 2018, 11:42 am by boolrules
Code: [Select]
void RunningLights(byte red, byte green, byte blue, int SpeedDelay) {
  int Position=0;
  for(int i = 0; i < LED_TOTAL; i++)      // when did this change from "j" to "i" ?  <<==========
  {
      Position++;                         // Position + Rate;
      for(int i = 0; i < LED_TOTAL; i++) {

NaCl19

Whoops... That was from changing stuff up and not correctly rewriting the previous code

gfvalvo

Meh.  I'm with TomGeorge.  "pinMode(pin, INPUT_PULLUP)" is clear, obvious, and portable to any device that implements internal pullups in some way (perhaps with a bit of effort.)
Right, what's the value added of using some device-specific code just to set the pin to input mode and turn on the pullup? How many times are you going to do that in a program? Who cares how long THAT takes?

Quote
(Did you know that the SAMD chips have an entirely different way to enable pullups, but go to significant expense inside digitalWrite() to duplicate the AVR behavior?  That's one of the reasons that digitalWrite() on the Zero isn't 3x faster than Uno's digitalWrite(), despite the 3x higher clock rate.  Grr.)
I'm more familiar with the freescale chips used in the Teensy family. They have some blindingly fast, device family-specific methods for digital I/O -- if you need it. The direct I/O techniques in the encoder and OneWire libraries come to mind. I assume the SAMD chips have similar device-specific facilities. But, again, if you don't need the speed, go with something easy to understand and portable.

TomGeorge

Hi,
Right, what's the value added of using some device-specific code just to set the pin to input mode and turn on the pullup? How many times are you going to do that in a program? Who cares how long THAT takes?
It makes code easier to read and debug for all the Arduino observers who DIDN'T write the 100s of lines of code.
Get the code working, then think about speeding things up.
If you need to change platform,  INPUT_PULLUP stands out like a dogs b*^$s to anyone experienced in rewriting code.
If you are rewriting for another device, then you will know if that is compatible or not, if not you change it, that is what programmers do.
Tom.. :)
Everything runs on smoke, let the smoke out, it stops running....

gfvalvo

Hi,It makes code easier to read and debug for all the Arduino observers who DIDN'T write the 100s of lines of code.
Get the code working, then think about speeding things up.
If you need to change platform,  INPUT_PULLUP stands out like a dogs b*^$s to anyone experienced in rewriting code.
If you are rewriting for another device, then you will know if that is compatible or not, if not you change it, that is what programmers do.
Tom.. :)
@TomGeorge, I think you misunderstood my comment. My meaning was: "what's the value added of using device-specific code (i.e. direct AVR register manipulation) when there's a general (multi-platform) method available that meets your needs?" And, this is especially true for something like setting the pin mode which will probably be done only once in the program (i.e. speed not important at all).

So, I think I was agreeing with you.

Go Up