...
| Page Properties | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
- We have a custom Makefile that allows us to selectively include headers and source
- We only need to support simulation on Linux (allowing us to use socketcan)
- The FSM will be event-driven
- We use a global event queue
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | Support common peripherals | We want to be able to use hardware peripherals on our boards and simulate them on x86. | Supporting SPI, UART, and the ADC might be a challenge. An alternative option is to simulate the device that uses SPI/UART to communicate. We probably want to display GPIO states as well. | |
| 2 | Support inter-board communication on x86 and STM32 | We want to be able to simulate the entire car on x86. | Board communication should be solely done through CAN. | |
| 3 | FSM | We want an FSM library that is easy to understand and debug. There should be state tracking. | ||
| 4 | Unit tests | We want to have be able to quickly test the library so we can verify changes. |
User interaction and design
...
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
Do we include default configs for boards that use the controller board? | |
| Are we only supporting boards that use the controller board? | |
| How do we display GPIO state? | We could use a curses-based display. This would allow us to reflect GPIO state, LCD output, and other information. |
| How do we handle external ICs? How do we reflect communication over SPI or UART? | |
| Do we support HSMs? Can the event be consumed by more than one FSM? |
Not Doing
- We are not supporting peripherals and features that we will most likely not be using in the foreseeable future.