-
Notifications
You must be signed in to change notification settings - Fork 1
Arduino LED Driver Design
We want to use one Arduino to drive multiple independent strands of NeoPixels. This implies that we can’t orchestrate LED patterns synchronously (i.e., using delay calls between updates). Instead, we’ll need to implement an animation loop where update each strand to a new ‘frame’ periodically. Robert’s code framework already does roughly this at 100ms periodicity.
However, that timing is too slow for smooth animations. I see a couple of options:
-
Create a faster frame rate, empirically minimizing the frame period by seeing how quickly we perform our processing. I.e., the pattern generation routines would expect to be called at a fixed rate, so each call would update the strand to the next discrete step in the animation. [easy, just change the constant that controls the update rate - it was set to 100ms as a starter. it only take 1ms to update the NeoPixel String, and with 8 strings, we can operate with a 10ms period.]
-
Have the loop simply update LED states as fast as it can, and have our animation algorithms be reactive to the current time (so that the appropriate state is drawn based on current time, whenever the method is called) [there's a data structure for each string, save the animation states in that structure, and reference them in the update loop]
Option 2 might be more difficult to code, but is more flexible and leads to the smoothest possible animations with less possibility for jumpiness, so it’s my preference. You could accommodate routines that want to be called at a fixed rate by wrapping them in a function that checks the current time and only calls them every 10ms or whatever.
The portal core/each resonator can be implemented as a state machine. E.g., for the core, there are a few state variables that should affect appearance:
- Portal owner
- Portal level
- Average resonator charge
Each permutation of those state variables represents a state, which would correspond to an animation pattern on 1+ LED strips. These steady-state animation patterns might be fairly lengthy (e.g., a slow pulsing effect over a period of some seconds).
Transitions between these states might involve transition animations, followed by a new steady-state animation. (E.g., a portal going from ‘owned’ to ‘neutral’ should show a flash of red followed by a steady-state white state.
- Animations need to be interruptable at arbitrary points in time (i.e., we don’t wait for a 10s animation to complete before transitioning state).
- Upon state transitions, we need to queue 1 (or more?) transitional animations, followed by a new steady-state animation. Barring further state change stimulus, we should complete a full cycle of the transitional animation(s) and then repeat the steady-state animation indefinitely.
The trick for transitioning, is to have an standard intermediate state, that takes three parameters:
- the next state to transition too
- the start color of the new state
- the time to get to the new state (optional could simple be standardized)
The transition state performs a linear interpolation from the "current color" at the start of the transition, to the new color using the time/transition-time as a fraction. That way the interrupted/ended old state transitions smoothly to the new state.