Short story. I am making an led hula hoop.

Archive FastLED Archive
,
21

Write one program that does the animation you want, without being able to change it, then write another program which accepts button input (maybe even without the led strip, just serial), when that works expand it to loop through “modes”, when that works then try to combine the original animation into it.

Also momentary buttons don’t conduct when not pressed, so the input is technically “undefined” but is often interpreted by the chip as a HIGH (technically, high impedance), but not reliable. So I hope the other end of your button is attached to ground, or this won’t work at all.

Finally, try holding down the button for a while for it to change modes, because you have to get through a loop before it will be read.

Once your program is fast enough you might need debounce logic or your chip will might interpret one button press as many.

22

His code expects the button to go LOW when pressed, which means it should be pulled up, not down (to ground.)

23

By the “other end” of the button I mean not the pin connected to the micro. So when pressed the micro pin is connected to ground, otherwise unconnected. You can get away without a pullup resistor, for a prototype at least. But yes, it should be pulled up on the micro side, or down with the logic reversed.

24

I guess I really need to get on the c++ learning

25

Hey @Josh_Dulcich , I know zip about c++. Everything I write, I learned from others guiding me and from looking at other people’s code and examples. As much as I’m trying to learn proper c++ technique and how to write my own code, it’s a very (VERY) slow process. So, don’t feel bad or discouraged. We’re all here to help each other. Keep the questions coming …

26

Arduino programs are typically written in C, though it does support C++ and many libraries are written in C++, there’s no need to complicate things further by using C++ features; C is simpler. Moreso think about program design :slight_smile: try writing your program on paper in simple English steps, and then step through the program manually and keep track of the variables changing in each loop. This is going to pay off more than learning a particular language, and programming starts to make more sense in future :slight_smile:

27

in C good to know. so what is this?
uint16_t i, j, x, y ;
uint32_t c, d;
universal interger?
what does the 16, 32 and _t mean?

28

_t = cross platform implementation of a standard type, meaning it’s the same whether you’re on *nix (OSX included) or Windows

As for the numbers, it’s how large the type is. There’s int8, int16, int32, and int64 as well as their uint (unsigned) counter parts. This might help:
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html

Keep in mind that the Arduino software implements these slightly different. Arduino implements an ‘int’ and ‘uint’ as a 16-bit number. However, for the Due platform, an int/uint is a 32bit number.

Personally, to keep my own sanity, I use the actual compiler types, being int8_t or uint8_t when all I need is an 8-bit variable. That way, whether I’m on a Due platform or not, it won’t matter, as the size will always be an 8bit.

29

Ashley’s right, but just to clarify:

There are signed and unsigned integers, which essentially means they can be negative (if signed), or not. There are also different numbers of bits which affects how big the number can be. For instance 8 bits unsigned (uint8_t) has a maximum of 256 values (2^8), which means 0 - 255. This can be very important to understand when dealing with something that can only take 8 bit integers, such as the LED values. If you try to use the wrong data type, undefined things happen.

Also, if you use a signed integer and increment it beyond its capacity, the effect is that it wraps around to its most negative value…! So for 8-bit signed, it goes from -127 to 127 (I think). If you increment 127, you get -127. Fun!

It’s somewhat platform dependent, but a “byte” type is considered to be an unsigned 8-bit int. This seems to hold in Arduino.

I think the default arduino “int” type is a signed 32-bit integer, so it holds lots more values than uint8. The compiler will try to tell you if you are passing the wrong type of value, but in some cases it will try to “guess” what you want and accept an int where you wanted a byte or uint8_t. If the int is larger than 255, it might crash, or it might give you the lower 8 bits of the int, which for 256 would be 0, so your leds won’t light up.

In order to explain that, uh… learning binary counting helps… this is getting complicated :stuck_out_tongue:

at 8 bits:
0 is represented as 00000000.
1 is 00000001.
2 is 00000010.
255 is 11111111. (see how it’s the max?)

at 16 bits, 255 is 0000000011111111
256 is 0000000100000000. See, the lower 8 bits are all 0.

That’s a little tangent, but a lesson in keeping your values only as large as they need to be or as will be accepted where they are going. I’ve personally made the mistake of looping up to 256 and having no leds light up.

And let’s not get started about big endian and little endian…

30

Arduino int is 16bits (-32,767 to 32,767 or 0 to 65,535 if unsigned), except on the Due where it’s 32bits ( -2,147,483,648 to 2,147,483,647).

31

what does the % notate?
switch(mode%MAX_MODES)

32

See: http://arduino.cc/en/Reference/Modulo