Defining project steps

When analyzing the specifications, defining the required steps, and assigning priorities, several factors may have to be taken into account. Consider having to design an air quality monitor device, with a PM10 air quality serial sensor, which collects the measurements done hourly into the internal flash, then transmits all the statistics daily to a gateway using a wireless transceiver. The target system is a custom board based on Cortex-M MCU, which is adequately sized to run the final software. The final hardware design will not be available until some real-life measurements are done on the transceiver transmitting data to the gateway.

The list of steps to be performed to reach the final goal, resulting from these specifications, may look like the following:

1. Boot a minimal system on the target (empty main loop)
2. Set up serial port 0 for logging
3. Set up serial port 1 for the communication to the sensor
4. Set up a timer
5. Write the PM10 sensor driver
6. Application that wakes up every hour and reads from sensor
7. Write flash submodule to store/restore measurements
8. Set up an SPI port to communicate to the radio chip
9. Write the radio driver
10. Implement protocol to communicate with the gateway
11. Every 24 measurements, the application sends daily measurements to the gateway

Note that some of the steps may depend on others, so there are constraints on the order of execution. Some of these dependencies can be removed by using simulators or emulators. For example, we might want to implement the communication protocol without having a working radio only if there is a way to test the protocol against the agent running on the gateway by using a simulated radio channel on the gateway itself. Keeping the modules self-contained and with a minimal set of API calls exposed to the outside makes it easier to detach the single modules to run and test them on different architectures, and under a controlled environment, before integrating them on the target system.