Meeting Notes (2020 10 13)

• Need to figure out a project structure

  • Sibling folder to lib called keyboards. Mix project-like structure.
    • We could have a set of officially supported keyboards this way.
    • It has a lot of issues.
    • All of the systems end up using the same mix.lock file, which causes issues.
      • If we pinned down versions in the mix file could we avoid using the lock file?
    • Had multiple targets working, but they were targeting the same nerves system. They both have to be updated to the same level at the same time.
    • Hook could let us switch out dependencies per target.
    • Do keyboard and LED implementations need to happen in their own project, or is Xebow the top-level project and the implementations are git submodules?
    • RGBMatrix was meant to be its own library.
    • Architecture
      • Web UI (Phoenix) needs to move into the library layer
      • A generic keyboard module should be in the library
    • Plugin model?
    • System layers (diagram)
      • Keyboard and RGBMatrix are optional components of the Xebow library. Either or both could be implemented per keyboard.

• Repos

  • dev-68-firmware

• Keyboard naming

  • "Nerves Keyboard" - The community is already calling it this.

• How do we make development faster/easier considering Phoenix is a dependency?

  • Other libraries are doing this (VintageNet Wizard)

• Dev-68 Firmware

  • v2.8 isn't working; USB gadget isn't coming up. Might be an Elixir 1.11 upgrade issue (application start order + Nerves issues with this).

• LED matrix driver

  • Focus on supporting the PWM mode. Auto-breathe mode can come later if we need it.
  • with statements vs. bang methods
    • Bang methods would be good for pipelining functions together, since the state should be captured after each function is called.
  • A nice thing about holding onto a struct as a ref is that a single GenServer can own all of the driver ICs on the I2C bus.

Resources