GPIO Module refactoring

[sjpark608]

I'm starting to implement the DIN and DOUT feature of EdgePiGPIO. These two feature requires to use GPIO character device. All pins of DIN (DIN1~DIN8) are attached on RPI CPU and requires direct pin access. For DOUT pins, DOUT1 and DOUT2 are attached on the CPU but rest of the pins are attached on the expander chip( i2c device). In order to access both pin groups on different hardware, I'm planning to refactor the EdgePiGPIO module as follows:

┌──────────────────────────┐               ┌─────────────────────────────┐
│                          │               │                             │
│                          │               │                             │
│  edgpi_gpio_expander.py  │               │  edgpi_gpio_chip.py         │
│                          │               │                             │
│                          │               │                             │
└──────────────────────┬───┘            ┌──┴─────────────────────────────┘
                       │                │
                       │                │
                       │                │
                       │                │
                 ┌─────▼────────────────▼────┐
                 │      edgpi_gpio.py        │
                 │                           │
                 └───────────────────────────┘

The current EdgePiGPIO class will be moved to a separate file and changed its name to edgepi_gpio_expander. This class only takes care of gpio pins on the expander chip. And a new class is generated in a separate file edgepi_gpio_chip. This will take care of direct control of pins on the CPU. Then the current edgepi_gpio will inherit both classes and instantiate one or both of them depending on the module config.

• Get rid of configuration parameter passing
  • start with implementing the new generic instantiation and use case first #154
  • once all functionality is implemented, start removing outdated methods #155
  • Check pin numbers
  • Configs being used for testing

[farzadpanahi]

I think we can have a quick discussion about this but I think EdgepiGPIO class should be the user facing class which uses enums to access DINs and DOUTs. I mean user does not need to know if there is a expander or not behind the scenes.

[sjpark608]

I think we can have a quick discussion about this but I think EdgepiGPIO class should be the user facing class which uses enums to access DINs and DOUTs. I mean user does not need to know if there is a expander or not behind the scenes.

quick refactor here, the user doesn't need to know about the nature of the GPIO structure. This issue is about how EdgePiGPIO class handles the inheritance of its parent classes. Users will interact with pin names using Enums.

In fact, the user never directly interacts with the GPIO module, it is encapsulated by other modules like DIN, DOUT, ADC, DAC, etc

[sjpark608]

GPIO Class shouldn't know about each configuration of modules. It should have information of all GPIO-related information when it is instantiated. Therefore, when encapsulating modules, such as DAC, ADC, etc., call the method to interact with GPIO, the encapsulating module only needs to send a specific pin they are interested in. GPIO class handles necessary functions in itself.

During the instantiation, encapsulating module should not need to send configuration as a parameter to the GPIO class.