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

AddressableLed() #69

Open
MrRSquared opened this issue Dec 29, 2020 · 6 comments
Open

AddressableLed() #69

MrRSquared opened this issue Dec 29, 2020 · 6 comments
Labels
enhancement New feature or request

Comments

@MrRSquared
Copy link
Contributor

Currently, it seems the AddressableLED() class does not seem to be implemented on the Romi (we do not receive any errors, but we do not get any light out of them either).

We are aware of the limitations here, and thus it may be a choice of the dev team, but it would be neat to have the ability to use addressable LEDs with the Romi through the external PWM pins.

Obviously, the current draw could be an issue here, but there are ways to mitigate that (limit the number in setLength() perhaps. Alternatively, we are investigating the use of a polyswitch instead of a jumper between the 5v pin and power rail).

Certainly, this is not an immediate priority, but Addressable LEDs are an incredible programming instructional tool as is the Romi, so they seem to be a logical fit. :)

@zhiquanyeo zhiquanyeo added the enhancement New feature or request label Dec 30, 2020
@zhiquanyeo
Copy link
Member

We don't currently send any AddressableLED HAL messages over the wire (so the Romi never gets them). We will need to do a decent amount of firmware refactoring to be able to support this (mainly because of the way the configurable IO pins are implemented).

We probably won't get to this in the near term, but we'll do a little bit of research to see how we can best support this in future.

@MrRSquared
Copy link
Contributor Author

Thanks. I was looking too, and I did not realize how difficult the timing is with the Addressable LEDs as opposed to typical PWM applications (motors and servos). I did not know it needed an entire firmware refactor, but it makes sense. I totally understand that it is not a near-term enhancement.

@zhiquanyeo
Copy link
Member

One potential way this could be done is to introduce a different IO channel mode for AddressableLEDs. This way, they could appear as a PWM port to robot code, but use something like the Adafruit NeoPixel Library under the hood to actually control the LEDs

@MrRSquared
Copy link
Contributor Author

That is a good point. I was thinking of that too. It may complicate the hardware (so using the same 5 pins would of course be preferable), but I did notice that it seems the magical pin#18 of the pi is exposed. However, it is possible that using the Adafruit library could interfere with i2c communication (or the converse), but the freenove rover does manage to use both successfully.

@zhiquanyeo
Copy link
Member

Right that was what I had in mind, reusing one of the 5 pins, but adding a new option in the Web UI that would allow you to configure the pin as one of [DIO, Analog In, PWM, AddressableLED]. We'll need to do a bit of research into which timers are being used by the NeoPixel library to see if it interferes with any of the ones already in use by the Romi (Motors are on timer1 and PWMs are on timer3)

@MrRSquared
Copy link
Contributor Author

That would indeed be cool. I understand that there are more pressing enhancements though. I may be able to find the timer interface. If so, I will add it to this thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants