Beginners Questions Again regarding Debounce and Vu-Meter

Status
Not open for further replies.

sevEnil2

Active member
Hi

So i have two more questions.

I'm running out of buttons so my question is if i probably can add more functionalities to it by detecting the duration of the press. So a single press is function one and a long press calls function two. Did anyone tried to add this. I see some troubles comming because a long press can combine with a short press because i'm looking for the falling edge etc. probably also issues i didn't think off.

The second thing whats the easiest way to make a vu meter led strip with a teensy 3.2 with a microphone or wathever needed (but no sound signal through teensy). Is there a "extension" available which will allow me tho do that with a teensy which already has a Octows2811 shield and 5 Additional pins occupied?

regards Severin

by the way thanks for the previous help the buttons are working now ;)
 
The interesting questions of using the length of the press to determine what to do with the button. This is doable, but you sometimes have to figure out how you wish things to work. That is, do you wish for anything to happen when the button is pressed or only when it is released?

If only when it is released. you can do things like:
Code:
   unsigned long timepressed;
  ...
   mybutton.update();   // make sure to get the 
   ...
   if (mybutton.fallingEdge()) {
      // This assumes falling edge on push, could be other way depending on wiring
      timepressed = millis();
   }
   else if (mybutton.risingEdge()) {
      unsigned long deltaTime = millis() - timepressed;

      if (deltaTime < LONG_PRESS_TIME) {
          // do short time stuff
      }
      else {
          // do long time stuff
      }
   }
...
The above could also be done using interval timer instead of millis directly. Also could setup to do multiple different things depending on time...

But if instead you wish to start some operation when it is pressed and switch over to something else if the press is longer than some duration, you can also do that...

Again something maybe like:
Code:
   unsigned long timepressed = 0;
  ...
   mybutton.update();   // make sure to get the 
   ...
   if (mybutton.fallingEdge()) {
      // This assumes falling edge on push, could be other way depending on wiring
      timepressed = millis();
      // maybe startup some operation.
   }
   else if (timepressed  && !mybutton.read()) {  // Again this may depend on PULL up versus PULL down. 
      unsigned long deltaTime = millis() - timepressed;
      if (deltaTime > LONG_PRESS_TIME) {
         // maybe stop the short push operation
         // start the long push operation 
         timepressed = 0;   // set to zero to keep from doing it again... 
      }
   }
...
As for meter code...
 
Hi

i would go for the first example but i like both thank you very very much...that was very helpfull.
can you pls tell me what this does? (timepressed && !mybutton.read())
i have troubles to read it due to my lack of syntax knowledge... but my guess is that this is something (long and not boolean) and i don't seems hard to do a and on it to get a boolean out of...

is there a reason why i don't see a lot of object oriented code in examples? because i did use OO and wanted start using inheritance in my code.

sev
 
can you pls tell me what this does? (timepressed && !mybutton.read())
i have troubles to read it due to my lack of syntax knowledge... but my guess is that this is something (long and not boolean) and i don't seems hard to do a and on it to get a boolean out of...
Sorry, In the above code I could have written this a little more long which may have been clearer:
Code:
else if ((timepressed  != 0)  && (mybutton.read() == 0)) {
That is, I only what this branch of the code to run if timepressed is not zero. It is initialized to zero and is set back to zero within this code. It was set to millis() when the button was first pressed. This allows us to then only call mybutton.read() and check to see if it is still down. Again note == 0 is assuming the button value is zero when pressed. If it is wired differently you may then need to change which transition is which and this may be checking again != 0

is there a reason why i don't see a lot of object oriented code in examples? because i did use OO and wanted start using inheritance in my code.
Depends on what you call object oriented code. In the above mybutton is an object of the bounce class...

As for using more advanced OO stuff like multiple inheritance and run time casting of objects... I typically try to avoid that, especially on smaller setups as it can really bloat the code... But others may do so.
 
okay that meens everything > 0 gets interpreted as true... not only 1.. that i wasn't expecting ;)

What i ment was more that the first thing i did (after understanding how the syntax works) was creating my own object just to get out of the global context and getting the visibility features. so i have now a class with a update function which get called every loop.

But now i should start storing multiple states and indexes for different strips. so to do so i would start doing a Tablepart class. which i can pass into my ledplayer so the leds get updatet with a certain pattern. The other thing would be to do a variable

int tablePart1Index;
int tablePart2Index;
int tablePart3Index;
int tablePart4Index;
int tablePart5Index;
int tablePart1forward ;
int tablePart2forward ;
int tablePart3forward ;
int tablePart4forward ;
int tablePart5forward ;
int tableParthue1... and so on.
tablePart1Index

so i just would prefer the OO stuff and i wanted to ask if there is a issue writing your own code like that because i didn't see a lot code (beside libaries) written in classes. But it sound like there is no general concern about writing OO code.
 
Last edited:
I have done a bigger refactoring of my code and i get now following compiler messages:

Code:
09:33:31 **** Incremental Build of configuration Release for project CoolTable ****
"E:\\ide\\sloeber2\\sloeber\\arduinoPlugin\\tools\\make\\make" all 
'Building file: ../CoolTable.cpp'
'Starting C++ compile'
"E:/ide/Teensyduino/arduino-1.8.1/hardware/teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O1 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -fno-exceptions -felide-constructors -std=gnu++0x -fno-rtti -mthumb -mcpu=cortex-m4 -fsingle-precision-constant -D__MK20DX256__ -DTEENSYDUINO=134 -DARDUINO=10609 -DF_CPU=96000000 -DUSB_SERIAL -DLAYOUT_GERMAN_SWISS  -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\cores\teensy3" -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\libraries\OctoWS2811" -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\libraries\Bounce" -I"C:\Users\sleipnir\Documents\Arduino\libraries\FastLED-3.1.3" -MMD -MP -MF"CoolTable.cpp.d" -MT"CoolTable.cpp.o" -D__IN_ECLIPSE__=1 -x c++ "../CoolTable.cpp" -o "CoolTable.cpp.o"  -Wall
In file included from ../CoolTable.h:3:0,
                 from ../CoolTable.cpp:3:
C:\Users\sleipnir\Documents\Arduino\libraries\FastLED-3.1.3/FastLED.h:17:21: note: #pragma message: FastLED version 3.001.003
 #    pragma message "FastLED version 3.001.003"
                     ^
'Finished building: ../CoolTable.cpp'
' '
'Building file: ../LedPart.cpp'
'Starting C++ compile'
"E:/ide/Teensyduino/arduino-1.8.1/hardware/teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O1 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -fno-exceptions -felide-constructors -std=gnu++0x -fno-rtti -mthumb -mcpu=cortex-m4 -fsingle-precision-constant -D__MK20DX256__ -DTEENSYDUINO=134 -DARDUINO=10609 -DF_CPU=96000000 -DUSB_SERIAL -DLAYOUT_GERMAN_SWISS  -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\cores\teensy3" -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\libraries\OctoWS2811" -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\libraries\Bounce" -I"C:\Users\sleipnir\Documents\Arduino\libraries\FastLED-3.1.3" -MMD -MP -MF"LedPart.cpp.d" -MT"LedPart.cpp.o" -D__IN_ECLIPSE__=1 -x c++ "../LedPart.cpp" -o "LedPart.cpp.o"  -Wall
In file included from ../LedPart.h:8:0,
                 from ../LedPart.cpp:8:
C:\Users\sleipnir\Documents\Arduino\libraries\FastLED-3.1.3/FastLED.h:17:21: note: #pragma message: FastLED version 3.001.003
 #    pragma message "FastLED version 3.001.003"
                     ^
'Finished building: ../LedPart.cpp'
' '
'Building file: ../SingleStripeAnimationPlayer.cpp'
'Starting C++ compile'
"E:/ide/Teensyduino/arduino-1.8.1/hardware/teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O1 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -fno-exceptions -felide-constructors -std=gnu++0x -fno-rtti -mthumb -mcpu=cortex-m4 -fsingle-precision-constant -D__MK20DX256__ -DTEENSYDUINO=134 -DARDUINO=10609 -DF_CPU=96000000 -DUSB_SERIAL -DLAYOUT_GERMAN_SWISS  -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\cores\teensy3" -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\libraries\OctoWS2811" -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\libraries\Bounce" -I"C:\Users\sleipnir\Documents\Arduino\libraries\FastLED-3.1.3" -MMD -MP -MF"SingleStripeAnimationPlayer.cpp.d" -MT"SingleStripeAnimationPlayer.cpp.o" -D__IN_ECLIPSE__=1 -x c++ "../SingleStripeAnimationPlayer.cpp" -o "SingleStripeAnimationPlayer.cpp.o"  -Wall
In file included from ../SingleStripeAnimationPlayer.h:7:0,
                 from ../SingleStripeAnimationPlayer.cpp:8:
C:\Users\sleipnir\Documents\Arduino\libraries\FastLED-3.1.3/FastLED.h:17:21: note: #pragma message: FastLED version 3.001.003
 #    pragma message "FastLED version 3.001.003"
                     ^
'Finished building: ../SingleStripeAnimationPlayer.cpp'
' '
'Starting combiner'
"E:/ide/Teensyduino/arduino-1.8.1/hardware/teensy/../tools/arm/bin/arm-none-eabi-gcc" -O1 -Wl,--gc-sections,--relax,--defsym=__rtc_localtime=1488531296 "-TE:/ide/Teensyduino/arduino-1.8.1/hardware/teensy/avr/cores/teensy3/mk20dx256.ld" -mthumb -mcpu=cortex-m4 -fsingle-precision-constant -o "E:/ws2/CoolTable/Release/CoolTable.elf"   .\Airpump.cpp.o .\CoolTable.cpp.o .\LedPart.cpp.o .\SingleStripeAnimationPlayer.cpp.o  .\libraries\OctoWS2811\OctoWS2811.cpp.o  .\libraries\FastLED-3.1.3\FastLED.cpp.o .\libraries\FastLED-3.1.3\bitswap.cpp.o .\libraries\FastLED-3.1.3\colorpalettes.cpp.o .\libraries\FastLED-3.1.3\colorutils.cpp.o .\libraries\FastLED-3.1.3\hsv2rgb.cpp.o .\libraries\FastLED-3.1.3\lib8tion.cpp.o .\libraries\FastLED-3.1.3\noise.cpp.o .\libraries\FastLED-3.1.3\power_mgt.cpp.o .\libraries\FastLED-3.1.3\wiring.cpp.o  .\libraries\Bounce\Bounce.cpp.o   arduino.ar   "-LE:/ws2/CoolTable/Release" -larm_cortexM4l_math -lm
.\CoolTable.cpp.o: In function `__gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\CoolTable.cpp.o: In function `__gnu_cxx::new_allocator<int>::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\CoolTable.cpp.o: In function `__gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\CoolTable.cpp.o: In function `__gnu_cxx::new_allocator<int>::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\CoolTable.cpp.o: In function `__gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\CoolTable.cpp.o:e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: more undefined references to `std::__throw_bad_alloc()' follow
.\LedPart.cpp.o: In function `std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >::_M_check_len(unsigned int, char const*) const':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\bits/stl_vector.h:1339: undefined reference to `std::__throw_length_error(char const*)'
makefile:82: recipe for target 'CoolTable.elf' failed
.\SingleStripeAnimationPlayer.cpp.o: In function `__gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\SingleStripeAnimationPlayer.cpp.o: In function `__gnu_cxx::new_allocator<int>::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\SingleStripeAnimationPlayer.cpp.o: In function `__gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\SingleStripeAnimationPlayer.cpp.o: In function `__gnu_cxx::new_allocator<int>::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
collect2.exe: error: ld returned 1 exit status
make: *** [CoolTable.elf] Error 1

09:33:35 Build Finished (took 3s.995ms)

So far i googled its telling me that im calling a c method out of c++ is this correct? i have troubles finding the right place... my code is there a trick to find the right place?
 
Last edited:
i figured it out by better reading the console... the problem is my 2dimensional vector


/*
* TablePart.h
*
* Created on: 02.03.2017
* Author: sleipnir
*/
#include <vector>
#include<FastLED.h>

#ifndef LEDPART_H_
#define LEDPART_H_

class LedPart {
public:
virtual ~LedPart();
LedPart();
LedPart(struct CRGB *ledsToAssign, int numOfLedsInArray);
int numOfLeds=0;
int loopIndex = 0;
int saturation = 255;
int delay =20;
int TOP_INDEX=0;
int EVENODD=0 ;
int loopIndexA=0;
int loopIndexR=0;
int loopIndexB=0;
int tcount=0;
int ibright = 0;
std::vector< std::vector<int> > ledsX;
int Hue = 0;
bool directionReverse =1;
CRGB * getLedArray();
int getnumOfLeds();
struct CRGB *leds;



private:
int BOTTOM_INDEX = 0;

};

#endif /* LEDPART_H_ */

/*
* TablePart.cpp
*
* Created on: 02.03.2017
* Author: sleipnir
*/

#include "LedPart.h"

LedPart::LedPart(){

}

LedPart::~LedPart() {
// TODO Auto-generated destructor stub
}

LedPart::LedPart(struct CRGB *ledsToAssign, int numOfLedsInArray) {
leds = ledsToAssign;
numOfLeds = numOfLedsInArray;
delay = 20;
TOP_INDEX = int(numOfLedsInArray / 2);
EVENODD = numOfLedsInArray % 2;
ledsX.resize(numOfLedsInArray);

}

CRGB * LedPart::getLedArray() {
return leds;
}

int LedPart::getnumOfLeds() {
return numOfLeds;
}

but can someone tell me how i initialize the vector right? it should be a array of int with a array size 3 of int
 
i tried now to use the construction initializer list (weird thing ;))

LedPart::LedPart(struct CRGB *ledsToAssign, int numOfLedsInArray) : ledsX(4, std::vector<int>(3)) {
leds = ledsToAssign;
numOfLeds = numOfLedsInArray;
delay = 20;
TOP_INDEX = int(numOfLedsInArray / 2);
EVENODD = numOfLedsInArray % 2;
ledsX.resize(numOfLedsInArray);

}

but i still get

12:01:59 **** Incremental Build of configuration Release for project CoolTable ****
"E:\\ide\\sloeber2\\sloeber\\arduinoPlugin\\tools\\make\\make" all
'Building file: ../LedPart.cpp'
'Starting C++ compile'
"E:/ide/Teensyduino/arduino-1.8.1/hardware/teensy/../tools/arm/bin/arm-none-eabi-g++" -c -O1 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -fno-exceptions -felide-constructors -std=gnu++0x -fno-rtti -mthumb -mcpu=cortex-m4 -fsingle-precision-constant -D__MK20DX256__ -DTEENSYDUINO=134 -DARDUINO=10609 -DF_CPU=96000000 -DUSB_SERIAL -DLAYOUT_GERMAN_SWISS -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\cores\teensy3" -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\libraries\OctoWS2811" -I"E:\ide\Teensyduino\arduino-1.8.1\hardware\teensy\avr\libraries\Bounce" -I"C:\Users\sleipnir\Documents\Arduino\libraries\FastLED-3.1.3" -MMD -MP -MF"LedPart.cpp.d" -MT"LedPart.cpp.o" -D__IN_ECLIPSE__=1 -x c++ "../LedPart.cpp" -o "LedPart.cpp.o" -Wall
In file included from ../LedPart.h:8:0,
from ../LedPart.cpp:8:
C:\Users\sleipnir\Documents\Arduino\libraries\FastLED-3.1.3/FastLED.h:17:21: note: #pragma message: FastLED version 3.001.003
# pragma message "FastLED version 3.001.003"
^
'Finished building: ../LedPart.cpp'
' '
'Starting combiner'
"E:/ide/Teensyduino/arduino-1.8.1/hardware/teensy/../tools/arm/bin/arm-none-eabi-gcc" -O1 -Wl,--gc-sections,--relax,--defsym=__rtc_localtime=1488542432 "-TE:/ide/Teensyduino/arduino-1.8.1/hardware/teensy/avr/cores/teensy3/mk20dx256.ld" -mthumb -mcpu=cortex-m4 -fsingle-precision-constant -o "E:/ws2/CoolTable/Release/CoolTable.elf" .\Airpump.cpp.o .\CoolTable.cpp.o .\LedPart.cpp.o .\SingleStripeAnimationPlayer.cpp.o .\libraries\OctoWS2811\OctoWS2811.cpp.o .\libraries\FastLED-3.1.3\FastLED.cpp.o .\libraries\FastLED-3.1.3\bitswap.cpp.o .\libraries\FastLED-3.1.3\colorpalettes.cpp.o .\libraries\FastLED-3.1.3\colorutils.cpp.o .\libraries\FastLED-3.1.3\hsv2rgb.cpp.o .\libraries\FastLED-3.1.3\lib8tion.cpp.o .\libraries\FastLED-3.1.3\noise.cpp.o .\libraries\FastLED-3.1.3\power_mgt.cpp.o .\libraries\FastLED-3.1.3\wiring.cpp.o .\libraries\Bounce\Bounce.cpp.o arduino.ar "-LE:/ws2/CoolTable/Release" -larm_cortexM4l_math -lm
.\CoolTable.cpp.o: In function `__gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\CoolTable.cpp.o: In function `__gnu_cxx::new_allocator<int>::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\CoolTable.cpp.o: In function `__gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\CoolTable.cpp.o: In function `__gnu_cxx::new_allocator<int>::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\CoolTable.cpp.o: In function `__gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\CoolTable.cpp.o:e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: more undefined references to `std::__throw_bad_alloc()' follow
.\LedPart.cpp.o: In function `std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >::_M_check_len(unsigned int, char const*) const':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\bits/stl_vector.h:1339: undefined reference to `std::__throw_length_error(char const*)'
.\SingleStripeAnimationPlayer.cpp.o: In function `__gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
makefile:82: recipe for target 'CoolTable.elf' failed
.\SingleStripeAnimationPlayer.cpp.o: In function `__gnu_cxx::new_allocator<int>::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\SingleStripeAnimationPlayer.cpp.o: In function `__gnu_cxx::new_allocator<std::vector<int, std::allocator<int> > >::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
.\SingleStripeAnimationPlayer.cpp.o: In function `__gnu_cxx::new_allocator<int>::allocate(unsigned int, void const*)':
e:\ide\teensyduino\arduino-1.8.1\hardware\tools\arm\arm-none-eabi\include\c++\4.8.4\ext/new_allocator.h:102: undefined reference to `std::__throw_bad_alloc()'
collect2.exe: error: ld returned 1 exit status
make: *** [CoolTable.elf] Error 1

12:02:00 Build Finished (took 1s.236ms)
 
actually that was the reason why i wanted to use a vector is due the fact that i don't know how big my array will be on declaration time. And i wanted to use the array as field...
 
For what it is worth, I looked up at least one of the cases I remember seeing in the ROS hexapod code base to see how the init was done then...

Code:
        std::vector<int> axes_index_map_;            // Map actual joystick axes to logical lx, ly, rx, ry maybe more later
        ...
        // Did not read in any override so use default PS3 mapping
        static const int axex_index_default[] = {0, 1, 2, 3};   // DS3

        axes_index_map_.assign(axex_index_default, axex_index_default + ((sizeof(axex_index_default)/sizeof(axex_index_default[0]))));
Hopefully that is as clear as mud ;)
 
na thats not clear for me XD but i hope for a old colegue at work it will help ;)



but i'm strugelling right now with a different problem which i don't understand.

if you look at the LedPart class i postet previously there is a simple int field called loopIndex.

somehow i'm unable to increas the int and keep it saved in the class from outside....even if i use a setter method.

if i do something like:
part.loopIndex++ its only increased for one execution in the method. The second thime i enter the method again its again 0 and not 1 like expectet. Why? It seems like its constant...
 
edit, okay i fugred it out it was passing a copy of my object into the method and not the reference.... thats explaining alot ;)
 
Just for completation and i just see that i didn't say that in the first place, my actual goal was an two dimensional array of int. As i strugled and googled i went on to the vector because someone was writing it was impossible with a standard array.

But the way to do a two dimensional and it right is following:
Code:
int **ledsX; // declaration in h file
---------
    ledsX=new int*[numOfLedsInArray]; // making a int array of pointers.
   for (int var = 0; var < numOfLedsInArray; var++) {
	   ledsX[var] = new int[3]; // adding the int array to the other array... 
   }

For the question about whats needed for a vu meter with microphone or if there is a finished sensor to do that there was no answer until now... should i ask the fastled community?
 
so i tested my code for the long button press but somehow its not working right.... i have this checkButtonState method in my main loop, so it get checked every loop.
So i didn't test what happens if i pass a Pointer to the button instead of the value to the stack. (its kind of a java weakness in my brain assuming every complex object gets passed by reference by default. )But it shouldn't change the behaviour in this case in my opinion. any ideas what i'm doing wrong?



Code:
int Table::checkButtonState(Bounce button) { //should i use by ref instead of by value?
	if (button->update()) { //assuming true means some update did happen so the state changed...
		if (button.fallingEdge()) {
			Serial.println("falling edge");
			buttonTimePressed = millis();//buttonTimePressed is defined in the header file.
		} else if (button.risingEdge()) {
			if (buttonTimePressed != 0) { //added this line because i kept entering this part. which should be handlet from the first if in my opinion.
				unsigned long deltaTime = millis() - buttonTimePressed;
				buttonTimePressed = 0; //If entered once reset the variable to 0 to not enter again.
				Serial.println("rising edge");
				if (deltaTime < 500) {
					// do short time stuff
					Serial.println("short");
					return 1;
				} else {
					// do long time stuff
					Serial.println("long");
					return 2;
				}
			}
		}
	}
	return 0;
}


this is how i call this method:

Code:
switch (checkButtonState(&buttonNextAnimation)) {
	case 0:
		break;
	case 1: // shortclick means change to next animation
		animationMode++;
		Serial.println("Next knopf . animation:");
		Serial.print(animationMode);
		break;
	case 2: //Longklick means  change to previous animation
		animationMode--;
		Serial.println("Zurück knopf . animation:");
		Serial.print(animationMode);
		break;
	}
 
Sounded like you already had an idea of what is sort of wrong from your description... That is what happens if pass a pointer to the button instead?

Remember I am old time C programmer so using references is semi foreign to me ;)

But what I see here did not make sense to me... That is:
Code:
int Table::checkButtonState(Bounce button) { //should i use by ref instead of by value?
	if (button->update()) { //assuming true means some update did happen so the state changed...
		if (button.fallingEdge()) {
			Serial.println("falling edge");
			buttonTimePressed = millis();//buttonTimePressed is defined in the header file.
		} else if (button.risingEdge()) {
			if (buttonTimePressed != 0) { //added this line because i kept entering this part. which should be handlet from the first if in my opinion.
				unsigned long deltaTime = millis() - buttonTimePressed;
				buttonTimePressed = 0; //If entered once reset the variable to 0 to not enter again.
				Serial.println("rising edge");
				if (deltaTime < 500) {
					// do short time stuff
					Serial.println("short");
					return 1;
				} else {
					// do long time stuff
					Serial.println("long");
					return 2;
				}
			}
		}
	}
	return 0;
}
From here it looks like you are passing a Bounce object to this method, not a reference nor a pointer. So my guess is calling this will copy the state of the button into it when called and then the updated values are tossed when this function returns. Again I wonder how this compiles?

That is in one case you have button->update() which looks like button is a pointer... But in the next case you have
button.fallingEdge()... which looks like you have the object or reference to object...

My gut tells me that if you wish to use reference, you would do:
Code:
int Table::checkButtonState(Bounce &button) {

And you would not use the & in the call... Which I would think would give you a compiler error or at least warning... As again you aren't passing a pointer?
 
Oh i'm so sorry to misslead you with my code... the problem i have is that i only can access the hardware once in a week. Its a 30 min Drive away from me... So i do a lot of coding home when the kids are asleep and test it in short amount of time. I didn't figure out what the issue was in that evening but startet to code at home. I wanted to show you the code which i tested.

The call was made without & in the switch. and the button->update() should be a button.update(); i should have compiled it sorry...


So but now u got me confused ;)

Code:
int Table::checkButtonState(Bounce &button) { <- i didnt know that one i was thinking the & gets the pointer of a object to pass it. You are saying this is by reference...
int Table::checkButtonState(Bounce *button) { <- pointer ? so same as by ref in my opinion ?
int Table::checkButtonState(Bounce button) { <- by value  so a copy of my bounce object. You said some values can get tossed away and it's not a proper copy then.?

So * is the actuall pointer and can be reasignet to something else? and & is the reference and can not? o gosh i googled a bit and just recognized that my whole life as programmer i never really understood the difference between pointer and reference... i'm shocked... and need to refactor my code o_O i'm using pointers everywhere i wanted to use a reference...
 
Last edited:
Personally if it were me, I would have a spare Teensy like a 3.2 $20 https://www.pjrc.com/store/teensy32.html (can get cheaper one at OSHPark),
Breadboard: $7.50 https://www.pjrc.com/store/breadboard.html
Some simple hardware pieces to experiment with, like maybe: $5 https://www.pjrc.com/store/tutorial_kit.html

That way you can for about: $32.50 debug lots of your stuff, while your kids are sleeping.... And you will hopefully make up the costs pretty quickly as driving 1 hour to try stuff out adds up cost wise pretty quickly.

Sometimes easiest to do query on things like reference vs pointers... You find lots of links to data, like: https://www3.ntu.edu.sg/home/ehchua/programming/cpp/cp4_PointerReference.html

Again some of the others can give more complete data, but, I believe:

------

Function that takes a reference: int Table::checkButtonState(Bounce &button)
The & here says that this function takes a reference to a Bounce object. Then to call this you would I believe be: checkButtonState(myButton);
Inside this function you can change what Bounce object you are using and you would reference things by . ===> button.update();
If the object has members you can set like lets say it has a state member if you do something like: button.state = 3... That updated value will still be there
outside of this call. That is the values inside myButton will be updated.

-----

The case of passing by pointer: int Table::checkButtonState(Bounce *button)
The * here says a pointer is passed to this function. So to call it you would say checkButtonState(&myButton) Where in this case the & says take the
address of myButton and pass it... Inside the function, you can check for null and update which button you are using like:
button = &someOtherButton. To access member variables and/or call methods you do it like ===> button->update();
Again member variable: button->state = 3; --- That state will be be there outside of this call. That is the state of myButton is updated.

-----

If you pass an actual object: int Table::checkButtonState(Bounce button)
When you call this with something like: checkButtonState(myButton)
The system will allocate a button object on the stack and assuming that the object class has a way to do assignments/copy: mybutton = anotherbutton.
It will make a copy of that object into the stack version....

to call stuff inside of this function, you would do it like outside the function: button.update()
But here is the catcher: Any changes you make to this object is local to this object inside of this function. That is things like
button.update() which update internal state variables. Or things like button.state = 3 is local to this object.
That is calling by object here the myButton object will never be updated.

Hope that helps
 
Hi yes, so the thirdway was kind of what i expected.. but someone else told me the copy would be complete...
The thing with the spareparts woulden't be such a bad thing now. Before i had the parts at home and tested them before i started to build them into my Table...but since the delivery fee is so high i do actually have the spare parts (buttons, leds, resistors,capacitors etc.) except for a powersupply and a spare teensy... you have right it probably would be the right time to invest the 30 bucks.

Funny i wouldn't have recognized it without you because i was full in the process of building all that stuff, learning C++, troubleshooting electricity, finding the right parts which was i bigger thing than i ever expected when i started my project a year ago ;)

so talking of can i ask you a question about capacitors? ;) somewhere i read about putting them as close to the ledstripe as possible. So in my case that would be 1cm away from the supply and probably 1,5m away from the leds... what are the effects?
 
Last edited:
As for Caps, probably someone else can give better answers... I would probably do as they suggest and see how well it works...
 
somewhere i read about putting them as close to the ledstripe as possible.

I'm guessing you saw this advice on Adafruit's site?

So in my case that would be 1cm away from the supply and probably 1,5m away from the leds... what are the effects?

For smaller LED projects (less than addressable 50 LEDs) with far-away power supplies, this helps quite a lot when the current changes.

For large LED projects, the current is very high, so you need short large wires to handle so much current.
 
Hi Paul

Thanks for your response... no it was not on adafruit's site,
i readed it more than once and once was here:
https://learn.sparkfun.com/tutorials/ws2812-breakout-hookup-guide#hardware-hookup (scrool down until the big picture of a cap apears)
But the first time i read about it while searching ws2812 leds to buy in a shop, there was a yellow box with the same instructions, for the moment i don't find right google search terms again to land on this site.

But in the end all tell the same, but a resistor in the dataline and put a big cap up to 1 Farat as close to the leds as possible.

So the wires seems to fine.. nothing burnd until now ;) and i reduced the brightness now to the half.
I had problems if i was running them add full brightness for long time they started to die. The seller was very friendly and replaced my 15m.
Since i'm done more or less with the testing and the relais has now a protection curcuit i wanted replace the "old" leds with the new one. Since i have to resolder every led Stripe i wanted to add the resistor and the cap. but the cap would be much easier to place directly in front of the power supply then to the end of the leds... also because i have 2 times 1,5mm cables comming out there instead of every led.... and i have also a space problem on the led end since the 1f caps are quite big...

Another thing is that wenn i power the hole table up the leds gets some data noises i think and some of the leds start to light. i think this should go away with the resistor right?
And still my question is why does the distance to the consumer matter for a capacitor?
So u tell me now it doesn't matter if i put the 1 farat cap between or not?


Regards Sev
 
And still my question is why does the distance to the consumer matter for a capacitor?

Wires have a small resistance and inductance. Normally these are not much of a problem, but large LED projects are not "normal". You can end up with very large currents in the wires, and the currents can change very rapidly as the controller chips inside the LEDs use PWM to create the colors you've set.

That is why.
 
You can end up with very large currents in the wires, and the currents can change very rapidly as the controller chips inside the LEDs use PWM to create the colors you've set.

That is why.

I thanks for your answer but its not as dummy proof as you might wish ;)
So this quote seems to be true for me without or with a capacitor.
The wires are big enought since i use four 1,5mm wires for the main transportation.

So probably i have to ask my question differently.
What changes if i place the 1farat capacitor closer or more far away from the leds? Is it "just" the loss of of the induction in the longer wire part? If yes can i ignore it by 1,5m 1,5mm coper wire or is this allready a big deal?
If no what else changes?

Regards Sev
 
What changes if i place the 1farat capacitor closer or more far away from the leds?

High frequency currents have to flow though more wire, which had a small resistance and inductance.

Look, you're asking very vague questions and expecting specific answers. That's not how things work. The effects seen can vary quite a lot. Many different power supplies exist. They are connected by different lengths and types of wire. Even the LEDs can vary. Not all capacitors are created equal either, even when they have the same rated capacitance. Internal resistance and inductance inside the capacitor can be a factor, where really high values in small packages often compromise high frequency performance.

These general "rule of thumb" guidelines tend to work for common cases. But the exact details vary, and for large numbers of LEDs this common guidance isn't enough. For many hundreds to thousands of LEDs, the currents are huge.
 
Status
Not open for further replies.
Back
Top