ecoapm/simplegpio

A simple, low-ceremony GPIO library for all your IoT needs

simplegpio's Issues

Can I adapt to BananaPi?

https://github.com/BPI-SINOVOIP/RPi.GPIO
https://github.com/BPI-SINOVOIP/BPI-WiringPi2

Windows support

Right now this is Linux-only. I'm not sure if UWP is the only way to access GPIO on the Windows side, but if not, create a new WindowsPinInterface class implementing IPinInterface with the Windows mappings.

If Windows support is UWP only, feel free to create a new SimpleGPIO.Windows project in the solution that references SimpleGPIO and have the WindowsPinInterface live there.

Add more colors to RGB LED component

Once PWM is implemented in #7, the RGB LED can show any RGB color!

• add a TurnColor(Color color) method
• add some more named colors

Add SPI/I2C/UART compatibility

As of v1.0, only GPIO is supported out-of-the-box, though SPI/I2C/UART could be implemented at the consumer-level. It'd be great to have that built into the library, especially since some of the components from #2 will probably require it.

Add reactivity

When input pin X changes, do something to output pin Y.

Pulse Width Modulation

Being able to dim / slow components would be cool. I have no idea how to go about doing it.

Use new /dev/gpiomem interface

The sysfs ABI is deprecated, plus memory mapping would be way faster than writing to the filesystem.

Fix input caching

I think power/voltage values will be cached in memory and never updated from the filesystem. Comment here and I can help talk you through this!

Add new boards

I only have a Raspberry Pi, so if you have something else and want to map the GPIO pins, that would be awesome!

Support more complex hardware wanted? (e.g. MFRC522 RFID Reader)

As a developer, I want to integrate my MFRC522 RFID Reader, so that the lib would provide a nice and clean API to this device.

First I would like to thank you for this lib, my examples are not fully working, but at least it looks promising. Are you willing to extend it to support more complex stuff? Or should this be implemented in another lib?

I'm currently trying to implement support for the MFRC522 RFID Reader, would you like me to submit a PR, if I'm done?

For more information see:

• https://stackoverflow.com/questions/34284498/rfid-rc522-raspberry-pi-2-windows-iot
• https://github.com/mlowijs/mfrc522-netmf/tree/master/Mfrc522

Add register-backed components

#2 provides components where all pins are directly mapped to inputs on the component. To reduce wiring to the device for some components, shift registers can be used.

• 7-segment display
• LED matrix

This could be done as a distinct class from the direct one, abstracting a common base class with 2 implementation, or perhaps use a strategy pattern to call an internal implementation. Regardless, the public API should be consistent between both.

Add advanced bus components

#2 handles simpler components, but some more advanced ones will need a non-trivial protocol from #6 implemented first.

• LCD panel (UART, requires #6)
• accelerometer (I2C, requires #6)

Does it support arm?

I have this: EM3566

Is it possible to use your library with my controller?

Add GPIO components

Create high-level objects for:

• RGB LED
• rotary encoder
• 7-segment display (8-pin direct)
• motor driver
• bit shift register
• timer
• LED matrix (16-pin direct)

The pins required should be passed in as parameters, and the classes should contain high-level helper methods and/or properties.

Requests for additional components should be created as their own issues.