Search results

This would be strange to me, since there's no code changing i other than the i-=100 line: volatile int i; for ( ;; ) { if ( i >= 100 ) { i -= 100; some_task(); } } Volatile is to tell the compiler something that you the programmer know but it doesn't. If you had an...

Its value changes even when you haven't assigned anything new to it. To the user it doesn't matter whether it's the bits inside the object changing or bits elsewhere, it still behaves like a variable whose value changes on its own. This is the point of operator overloading, so things can act...

Interesting, elapsedMillis is an elegant solution. It encapsulates using the correct type, correct casts for comparisons even when millis() overflows, and updating without drift. It's a little odd that it's an active value, but conceptually one can just think of it as being incremented every...

The counters will overflow, but the code will work indefinitely. For example, if switchPinMillis in the code below is 0xFFFFFFFF, and millis() is 0x00000063, the difference is 0x64 (100), and the condition will evaluate to true. unsigned long switchPinMillis = 0; static int switchPinInterval =...

The minor fix was to change static int current; to static int current = THRESHOLD; As for the jitter at zero, you'd have to dump a log of the raw values while you confirm that the jitter is happening. Based on your earlier log, I don't see how it could occur, so I'm concluding that you're...

The jitter makes it harder to tell when it's at the end of the range. From what I can tell, my code limits the raw range of 0-1023 to 0+THRESHOLD to 1023-THRESHOLD, so 14 to 1009. Divided by 8 gives 1 to 126. So you'll want to do map( current, THRESHOLD, 1023-THRESHOLD, 0, 127 ) if I understand...

My take on the ratings is that following recommended maximums means that the device behaves reliably at all times, while merely staying within the absolute maximum ratings means that you won't permanently damage the device, but that it may behave erratically until you reset it.

I see; here's my modification to your loop() to use this code: #define THRESHOLD 14 int update_current( int raw ) { static int current; int delta = raw - current; if ( delta <= -THRESHOLD ) current = raw + THRESHOLD; if ( delta >= THRESHOLD ) current =...

I thought more about the hysteresis code I posted and the nagging detail at the end and I think it could be done better. The way I have it, the reading can only jump in THRESHOLD-sized jumps at minimum. It should move the current value a smaller amount: #define THRESHOLD 14 int current; void...

Clear the port's bit in its PORT register, then output the inverted level to the pin's bit in the DDR register. This way when you write a 0 to the DDR register, the pin becomes an input, and thus high-impedance. When you write a 1 to the DDR register, it becomes an output of a low level...

Hysteresis is just making the current value "sticky". You keep track of the current value, and only change it if the raw reading differs more than a minimum amount. So for your readings, where the reading can go between 1023 and 1001, you might use a threshold of +/- 14 (22 range/2 + a little)...

Just some general ideas (I've never used LED strips): Have you measured the current a given strip draws (if you've never measured current, the meter goes in series, not parallel like with voltage), and determined whether each PSU can handle five strips? If the strips use a voltage converter...

Ugh, finally figured it out; apparently stty sane turns echo on. Should have figured that since I was seeing some of the menu coming back to its input. So $ stty -F /dev/ttyACM0 sane $ stty -F /dev/ttyACM0 raw 57600 cs8 -crtscts -cstopb -parenb -echo Is the way to get binary data (I know that...

Maybe you've improved it, but the above sends updates to the host continuously (up to 500Hz) even when the button's state hasn't changed, unless send_now() detects the lack of any changes and optimizes out the USB update (I can't find Keyboard's source to confirm this). Usually you'd do as your...

Ubuntu 12.04 modem manager still screws with Teensy serial OK, after hours of hair-pulling, I found that even in Ubuntu 12.04, the modem manager screws with Teensy serial, sending it lots of garbage. The 49-teensy.rules made it sound like it was a problem only in much older versions. For the...