For a dynamic configuration of LEDs, the module needs to be able to receive information about how many LEDs are configured and expose the configuration of the pin numbers.

For the count of LEDs, the module should read if from a parameter, allowing it then to be changed from sysfs's parameters directory.

It should also expose those LEDs on sysfs to allow users to configure the pin number associated with the LED.

Another possibility is to explore the way the kernel fetches the values from the parameters to get the full LED/pin configuration from a single parameter/operation.

DoD: module is able to dynamically create and destroy LED objects and get their pin/number values from user.

Blockers: None

Backlog/Extra work

This would be an extra implementation on the module to allow the socket server to communicate with clients via JSON, allowing a more visual understandable protocol.

The backing linked-list implementation would still work in CSV style.

The suggested way would be to have soft-links on the sysfs of the module, under the same folder leds, with the names of the LEDs linking to the led number. Another way could be to have a separation in the leds folder between names and numbers:

.../leds/
    numbers/
        0/
        ...
    names/
        red_0 (-> ../numbers/0)
        ...

To pass the names of the leds to the module is the challenge, either with a parameter names in the form of <name1>:<index1>,<name2>:<index2>:... or an extra attribute under the LED folder in sysfs named name which would allow setting the name of the LED (creating or renaming the named entry)

DoD: TBD

Blockers: #3

Merging it all together

The Linked List's nodes (from #5) should be of states for GPIO/LED output, setting the state of each output (0 or 1) with a final entry stating the time it should run for. Once the time expires, it should move to the next state, rolling over.

It should also verify that all the GPIO pins are defined (they may be initialized to an invalid value).

The module shall output these states based on the GPIO/LED configuration (from #3 , #4).

Changes added on top of #3 are needed in order to change (or delete) the current linked-list, shall the new GPIO configuration be invalid with the current states.

DoD: module is able to output current following the configured state (to the correct pins), for the correct amount of time.

Blockers: #3, #4, #5

Setup buildroot to build for BeagleBone Black, it should have SSH enabled.

DoD: Build and deploy successful, able to SSH into installation.

Blockers: None

The module, upon receiving a pin number change, should destroy the old configuration and initialize a new one, for the respective LED/GPIO.

DoD: module re-initializes new GPIO configuration after pin change

Blocker: #3

Future work/Backlog

The module should support intermittent GPIO/LED outputs.

In the context of a traffic light implementation, it will sometimes have intermittent lights (pedestrian crosswalk before becoming red again), so support for it should be added.

Suggestion is to allow an extra state (0.5) to the possibilities for LED output (current are 0/1), telling the module that that light should be intermittent.

Another suggestion is that intermittent lights could have a default interval of 1 second, but also configurable.

DoD: module is able to output intermittent lights

Blocker: #6

Simirarly to previously discussed aesdsocket, a socket server shall be created and run on the deployed on the hardware to allow remote/limited access to the capabilities of the module.

Namely, it should only give access to the state/linked-list configuration, allowing to clear, append and read the states from it.

DoD: module's states/linked-list is configurable from a socket server

Blockers: #5

An initial basic module implementation to test the integration on buildroot.

DoD: module is present and loadable on deployed build.

Blockers: #1

Backlog/Extra work

There are situations where an user may interact with the system, in the example of traffic lights, a user may request the crosswalk to go green.

In order for that to happen, the module needs to reach to user input, namely a button.

The button would still have a GPIO interface and should be configurable the same way as the LEDs. It is suggested that the module setups IRQ to handle changes in the button's GPIO.

The module should have 2 more state linked-lists, exposed through files, the same way as the main linked-list. These are for the states to go through to react to the user's input.

One of them is for a immediate response, similar to an infinitely green light and a crosswalk going green upon user's request,

Another for the end-of-loop, similar to Scotland, where, in intersections, at the end of every loop, the crosswalks go green if any user requested it.

DoD: TBD

Blockers: #6

Future work/Backlog

The module should be able to report back its current status, upon reading from a /dev/ file.

It should report the current state of the output pins and the time left on the current state.

DoD: module is successfully able to tell its current state

Blockers: #6

Backlog/Extra work

Here, a state loop (for the lack of better expression) is the states' linked-list the holds the LEDs desired states (it's a loop because it runs for ever).

It is suggested that the module should be able to hold multiple state loops, exposable on devfs and backed by linked-lists and an input to control which one to follow.

This would be similar to when traffic lights go intermittent yellow during the evening

DoD: TBD

Blockers: #6

Similarly to the aesdchar device, the module will need to keep a buffer of states, allowing it to be read and written/appended using a /dev/<something> file. In the case for this module, a Linked List should be used instead of a Circular Buffer.

When the file is opened with O_APPEND flag, it should add a new entry to the linked-list, otherwise it should destroy the current linked-list before appending new items to it.

It should support read operations as in aesdchar driver.

It's basically a file backed by a linked-list

Since this will hold the states for the GPIO output, each line will be a CSV (comma separated values) of N binary values, where N is the number of GPIO/LEDs configured, followed by a positive integer, stating the time it should run to. See #6 for more detail.

DoD: module should be able to create, append, delete and read items from the linked list, using a file on devfs.

Blockers: #3, #4

Backlog/Extra work

Another cool feature would be a client (for the socket server(s)) that would be mounted somewhere (hence the FUSE) to expose file-like interfaces for the remote server (read/write/truncate) similar to the one exposed by the module.

The client could even allow for multiple servers, exposing a file for each server.

DoD: TBD

Blockers: #7