Thunderstorm Support #60
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
libbsd provides access to arc4random_uniform(), which is a better random number generator than the one defined in POSIX. It also happens to coincide nicely with Darwin. CBSD is a nice wrapper around libbsd on Linux.
Instead of having different tokens for each PWM mode, instead use PWM00-PWM15 naming for each PWM mode. This will make it easier to share schedules in the future.
This enables the use of both sets of hardware PWM pins. 12 and 13 are a little bit easier to use when wiring (they both next to ground pins, unlike 19. Also unlike 19 which is used for SPI, 12 and 13 aren't used for any other purpose than GPIO. Going forward, it might be a good idea to add something to the configuration that allows the user to pick high or low.
Removes an extra step that we don't really need to do separately. 'swift package show-dependencies' will do the resolve for us.
There’s still some work to be done to allow the lights to be configured for the storm and lightning itself, but this is what’s required to start implementing the events themselves.
A good “random” API was added in Swift 4.2, but we can’t use it yet. But it doesn’t mean we can’t use the API with an implementation backed by arc4random_uniform().
This is the first step towards being able to add the events into the light controller, by having a basic implementation of the event controller.
With a tweak to the EventId enum, we can now load each StormEventController into the light controller, while keeping the keys unique, presumably.
Autogenerated hashing and equatable for enums like EventId is only available on Swift 4.1 and later. So we need a custom hasher for Swift 3.1.1 and 4.0.x.
This refactors the layer code that lunar cycles use for storms. At least for now, if a storm starts, the lights will dim for the storm. No lightning implementation yet.
The storm behavior work is required to produce the lightning strike flashes during a storm. It still needs the pieces that allow the Light Controller to have a ‘stack’ of behaviors to completely function, as well as a way to pop old unwanted behaviors off the stack when done.
This work concludes the main development push for Thor, by integrating the storm behavior into the light controller for lighting strikes.
|
This has gotten so old, the PR should be abandoned and revisited later if needed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds thunderstorm support for addressing Issue #18.