Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Neopixel #62

Closed
justinledwards opened this issue Aug 21, 2013 · 4 comments
Closed

Neopixel #62

justinledwards opened this issue Aug 21, 2013 · 4 comments

Comments

@justinledwards
Copy link

I want to be able to control my neopixel stick using dino, but I really don't know how to get started on it.

https://github.com/adafruit/Adafruit_NeoPixel

I don't fully understand how my arduino is using this library. I'm only using one pin to control it. It's easy to code for in arduino using the library, but I have no idea how to merge it with dino.

http://www.youtube.com/watch?v=sL0p3a0yB6k

Any ideas? I'd be willing to setup a remote connection so that someone could play with it if need be. Or if you're in the states I could order you a stick?

http://www.adafruit.com/products/1426

@kd-2020
Copy link

kd-2020 commented Aug 22, 2013

Anyone feel free to chime in and correct me if I'm wrong on anything here.

You'll need to modify the dino library a bit. If it were me I'd add a few commands to duino.cpp. As it stands, dino's serial protocol is capable of having 256 different commands, numbered 0 through 255. It only uses 0-9, 90, 97 and 98. So you could pick any of the remaining numbers to add your own custom commands to call the neopixel library's functions.

On the ruby side, I would make a new component that sends the proper commands you created in your sketch. Also you'd have to add your new commands to the Board class. You can use the existing component classes as templates/examples for making your new one for the neopixel.

Also another tip, you may want to learn how to take advantage of ruby's Array.pack function to send the necessary parameters to your new custom commands in as few messages as possible.

@vickash
Copy link
Collaborator

vickash commented Aug 22, 2013

@TheBoozler, that's the general approach, yes.

One thing I'd like to add, is that you should enclose your library inside a single top level command. If you look at how the DinoLCD library in 0.12 is done:

The "cmd" part of the message that Ruby sends is just "10", which tells the board to call the handleLCD() method in Dino.cpp. This invokes a case statement inside DinoLCD.cpp. Here the "val" part of the message is interpreted as the "command" sent to the library. The actual values or data the library needs get stored in the "aux" part of the message.

We could probably improve on this message structure, but that's how it works for now. Try to avoid cluttering up the top level "cmd" space, since all commands at that level have to get added to board.rb.

If you just set up one command to access the entire library, then you only need one entry in board.rb, and your component's ruby file can take care of composing most of the message. It's also easier to maintain, since long case statements lilke https://github.com/austinbv/dino/blob/0.12.0-wip/src/lib/DinoLCD.cpp#L21, end up inside YourLibrary.cpp instead of Dino.cpp.

@kd-2020
Copy link

kd-2020 commented Aug 22, 2013

Ah some nice improvements in 0.12! I hacked away at the library before to implement my own "auxmsg". Good work.

@vickash
Copy link
Collaborator

vickash commented Mar 25, 2023

Added in 4be7ed for most chips.

@vickash vickash closed this as completed Mar 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants