Discuss future direction #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Author: @david-sawatzke Posted at: 01.01.2019 21:22
From https://github.com/atsamd-rs/atsamd/issues/32.
I'd prefer to have the high-level library and the implementations as separate crates, because there may be better implementations. On AVR, your bit delay stuff is different than on arms, where some people are using gpio pins and dmas, so you can't really do it all (I think).
Author: @david-sawatzke Posted at: 01.01.2019 21:25
I'd also prefer an iterator based approach, so you can do multiple transformation and effects, without having to use much ram and/or doing destructive transformations.
I'd also not keep it ws2812 specific, because there are many (for example the apa ones) that are similar but not the same
Author: @sajattack Posted at: 01.01.2019 21:27
I think adafruit keeps APA102 and WS2812 separate but I could be wrong. I like your ideas of separate backend crates and iterators.
Author: @david-sawatzke Posted at: 01.01.2019 21:34
Yeah, but the API for the driver is pretty much the same. The only difference is that the color bytes are in a different order and a seperate brightness PWM is implemented, but that one isn't recommended by adafruit because the frequency is really low.
We could have a programmable-led-api crate which is used by the backends, which defines the interface of the iterator of the trait, a separate effects crate which implements various iterators, that can consume each other and so on, and last but not least the various backends.
We should also make sure to always implement
size_hint(https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.size_hint), so that it can efficiently work on raspberry pis and the likeAuthor: @david-sawatzke Posted at: 01.01.2019 21:39
I'd ask around on irc
Author: @sajattack Posted at: 01.01.2019 22:19
Maybe smart-led is a better name. Don't want it to be too long.
Author: @david-sawatzke Posted at: 01.01.2019 22:31
Probably a good idea. Maybe under an organization or something?
This is my current plan for the crate structure: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0cb67a7076b9e00d69c7b6e00a1727ac
Author: @sajattack Posted at: 01.01.2019 22:37
I would probably want to have the crate with the Trait to also be the crate with the high-level api.
Author: @david-sawatzke Posted at: 01.01.2019 22:38
I'd export it for end users in the high-level api, but leave it separately for implementers. I think it's more clear where responsibilities and there'll (probably) be less api breakage because of updates
Author: @sajattack Posted at: 01.01.2019 22:40
Ok, that makes sense.