Closed owenwaller closed 1 year ago
This page exists https://gobot.io/documentation/guides/adding-hardware-support/ but needs a lot more information.
Hi Ron,
Yes, I've seen that page but it doesn't really help :) I'm looking for an explanation of the drivers architecture and a set of steps to create a new driver.
Although all of the existing drivers seem to follow an similar style, it is not actually obvious - at least not to me at the minute :) - what you need to to to create a new driver.
Owen
Actually, I was more pointing out that is the placeholder page for the needed explanation. Right now as you mention, it tells you very little.
@deadprogram I think I am going to need a few hints on this in the coming days.
At the minute the test code I have that I plan to move into the driver can:
Plus the usual Start()
, Halt()
, GetName()
and SetName()
functions.
Also far, as far as I can tell, the code is also go routine safe. If a fade (for example) is called in one go routing to take place over 3 second, that driver will block and prevent any changes to the PiGlows leds until the fade has finished.
So, things are getting close to needing to refactor this into the GoBot driver plan.
Owen
And finally... :)
I've got my skeletal PIGlow driver in a state that I can do an early preview off. The code is in my new PiGlow repo.
Please see the README for details of the current state of play. The code is released under the same Apache 2 license as GoBot. You will need GoBot v1.3.0 or better to use this as the code relies on the fix to issue #372 to function correctly.
Can someone please help me out with converting this to a proper GoBot driver so that the rest of the GoBot community can make use of this. I would very much welcome pull requests for both this and general code review comments.
Once the driver is in the correct form I can start the process of adding it to the root GoBot tree.
In the meantime I need to create a proper set of go test
style tests by converting the demo piglow
program into something more test friendly.
Thanks
Owen
Oops... I accidentally closed the issue. Re-opening it...
The CLI was removed and the documentation was updated. Currently there is a known issue with v2+ modules. For new driver/platform one of the latest driver/platform should be used as a blueprint.
Hi @owenwaller , if you still interested in to get your driver to be part of gobot, please open a PR and I will have a look on it.
Thanks Thomas
@gen2thomas My PiGlow driver has been dormant for a very long time, due to many other life related things getting in the way!
Yes, if no-one else has created a alternative driver in the past 6 years, you are welcome to use my source as a starting point. Last time I looked it was complete - which was when Go added module support.
If you need any help, I can find a Pi and a PiGlow and try rebuilding the source code. I've no idea what has changed in GoBot in the intervening period however.
NB. If you do need help I don't have the bandwidth until the middle if next week at the earliest..
Good luck
Owen
@gen2thomas Sorry, I spoke to soon.
Looking at my code again, it was never a fork from gobot. I built it independently an used gobot. Also, contrary to what I have just said it's not module aware yet.
So, a better idea would be for you to fork my code, and get that into shape, so that:
a) It uses go modules b) It uses the latest gobot c) Split my code into a pair of cmd's one that drives the hw (see mainhw.go) and one for the sim (see mainsim.go) and then change the package of piglow.go away from main to "piglow".
and send me a PR.
We can then set about transforming my piglow.go to refactor it as a gobot driver.
Regards
Owen
Hi @owenwaller , thanks for your fast reply. I can not drive this topic forward, I could just support it. So I would close this issue for now if nobody has enough time for implementing the missing tests and transform it as driver for gobot.
Best regards, Thomas
With regard to issue #372
I'm happy to put together a pull request for the PiGlow but I do need some advice on how best to go about this. It looks like the preferred way to do this might be a new "PiGlowDriver", rooted under the drivers/i2c tree.
However the process of writing a driver seems to be pretty much undocumented. Could someone please walk me though the process, and explain the drivers architecture?
For example what's the Commander and Eventer and why do you seem to need both in the Config. What's the Config supposed to show etc.
I don't think any of this is very hard code to write. I already have large parts of what would be required, but a little explanation would help at this stage.
Thanks
Owen