Restructure EmotiBit examples to use PIO scripts

[nitin710]

Description

• Currently using .ini files defined for stock firmware in EmotiBit examples causes breaking paths.
• A fix would be create a more standardized directory organization to use shared scripts

Current Directory Structure (as of v1.8.1)

directory structure template

EmotiBit FeatherWing
├── EmotiBit_stock_firmwares
│   ├── EmotiBit_sotck_firmware
│   │   ├── EmotiBit_stock_firmware.ino
│   │   └── platformio.ini
│   └── EmotiBit_sotck_firmware_PPG_100Hz
│       └── platformio.ini
├── examples
│   └── EmotiBit_examples
│       ├── charlieplex_heartbeatOnSleeve
│       │   └── charlieplex_heartbeatOnSleeve.ino
│       ├── input_digitalPinLogging
│       │   ├── input_digitalPinLogging.ino
│       │   └── platformio.ini
│       ├── input_digitalPinLogging_PPG_100Hz
│       │   └── platformio.ini
│       └── sevenseg_displayTemperature
│           └── sevenseg_displayTemperature.ino
├── testing
│   ├── boardTests
│   ├── EmotiBitWifiTest
│   └── MemoryController
├── pio_scripts
│   └── renameFw.py
├── board_feather_m0.ini
├── board_feather_esp32.ini
├── library.properties
├── *.h
└── *.cpp

Problems

• Inability to use global scripts in platformIO
  • Example, the stock firmware uses rename script, renameFw.py to change the name of the built binary from firmware.bin to <something_more_appropriate>
  • This script is called by the board_feather_m0.ini/board_feather_esp32.ini extra config files. These extra config files use relative path to renameFw.py and are executed from the root directory of the project (where the original platformIO.ini is located)
  • We would ideally want this file to be used by all our examples and stock firmwares
  • However, since the examples are on a different level than stock firmware, the relative path breaks and the extra scripts are not invoked.
  • This can be fixed if all projects ino files (and by extension all platformIO.ini files) are on the same level under the root FeatherWing repo

[nitin710]

directory structure template

EmotiBit FeatherWing
├── _EmotiBit_stock_firmwares (leading underscore keeps the directory at the top)
│   ├── EmotiBit_sotck_firmware
│   │   ├── EmotiBit_stock_firmware.ino
│   │   └── platformio.ini
│   └── EmotiBit_sotck_firmware_PPG_100Hz (All variants reference the original .ino file)
│       └── platformio.ini
├── EmotiBit_examples
│   ├── charlieplex_heartbeatOnSleeve
│   │   └── charlieplex_heartbeatOnSleeve.ino
│   ├── input_digitalPinLogging
│   │   ├── input_digitalPinLogging.ino
│   │   └── platformio.ini
│   ├── input_digitalPinLogging_PPG_100Hz (All variants reference the original .ino file)
│   │   └── platformio.ini
│   └── sevenseg_displayTemperature
│       └── sevenseg_displayTemperature.ino
├── testing
│   ├── test1
│   │   ├── test1.ino
│   │   └── platformio.ini
│   ├── test2
│   │   ├── test2.ino
│   │   └── platformio.ini
│   └── test3
│       ├── test3.ino
│       └── platformio.ini
├── pio
│   ├── scripts
│   │   └── renameFw.py
│   └── extra_configs
│       ├── board_feather_m0.ini
│       └── board_feather_esp32.ini
├── library.properties
├── *.h
└── *.cpp

• Pros

  • All projects are on the same directory level relative to root
  • Bounds directory level growth in any one category. Currently, the testing directory has many sub directories, which creates "many buckets" to keep a test in
  • We can re-use pio scripts since they share the relative path from all examples
  • Creates 3 primary categories, which can cover most examples
  • Creates a location to bundle all future pio scripts
  • immune to adding sub-categories in pio folder. (gives room for PIO to grow creating a demarcation between projects and pio dependency)

• Cons

  • Breaks if we ever need to create sub-categories within the 3 primary categories. (will this situation ever arise?)
  • We need a extra _ in stock firmware folder name to bring it to the top
  • may present problems when number of tests grow and need re-categorization
  • can be prevented by adding category name to the test name, but may create another problem of long test names.