Page Comparison

...

To support this, here’s a module breakdown of the project. Note that there are 2 solar boards, one of which has 5 MPPTs and one of which has 6, so firmware must support both.

Hardware schematic: https://university-of-waterloo-solar-car-team.365.altium.com/designs/589A49F1-9DE6-4FB1-B369-12387D122AA0#design

Modules

Generating data:

• sense is a generic module that encapsulates the pattern of “periodically, read X and store the data, then tell the data store that we’re done.”

  • The sense_register() function takes a callback. All of the callbacks passed into this function will be periodically called (at a configurable interval), followed by a call to data_store_done().

  • The callback passed to sense_register() should read voltage/current/temperature (and maybe PWM) data from hardware, then store it in the data store.

• sense_current, sense_voltage, sense_temperature, and sense_mppt provide the callbacks passed to sense_register(). Each calls sense_register() in their init function.

  • sense_current reads the current output of the solar array through an MCP3427 ADC over I2C (via ACS722 current sense, though that shouldn’t be relevant for firmware).

  • sense_voltage reads the voltage from each of the MPPTs via 5-6 MCP3427s over I2C.

  • sense_temperature reads temperature data from GPIO pins PA0-4 (5 MPPTs) or PA0-5 (6 MPPTs) from thermistors.

  • sense_mppt communicates with the (presumably) SPV1020 MPPTs over SPI and reads their current and input voltage (and possibly PWM). It also reads the status register and raises fault events if an MPPT has an overcurrent/overvoltage/overtemperature bit set.

...

• data_store provides an abstraction layer between reading the data and doing something with it. It stores all of the data collected by sense et al., then raises a “data ready” event. Consumers of the data (logger, fault_monitor, etc) can retrieve the data directly from data_store to avoid overloading the event queue. All data is stored as uint16_t.

  • To store and retrieve data, we’ll likely we use a SolarData DataPoint enum with one entry for each data entry point we need (e.g. SOLARDATA_DATAPOINT_VOLTAGE_1, SOLARDATA_DATAPOINT_MPPT_CURRENT_3, etc.).

  • The data_store_enter() function (not sold on the name) takes a SolarData DataPoint parameter to identify which data point it is, as well as the data point as a uint16_t. It’ll overwrite that data point in the module’s storage.

  • The data_store_done() function is called by sense when a batch of data is read. It raises a “data ready” event which is received by the consumers of the data.

  • The data_store_get() function will take a SolarData DataPoint parameter and a uint16_t* and will set the pointer to the value of the data point.

...

• solar_fsm keeps track of the state of the module. It transitions on fault events (and possibly commands from centre console, if those exist) and dispatches “action” events to interface with calls the DRV120 driver to open/close the relay and calls mppt to turn on/off the MPPTs. (This could be split off into multiple FSMs to handle specific fault sequences. Also, we could just call relay from solar_fsm instead of raising an action event if the relay logic is simple enough.)relay will handle opening and closing the relay when it receives an appropriate action event. It will interface with the DRV120 driver.

Other:

• mppt is a thin wrapper over the spv1020_mppt driver which handles dealing with the demux to support addressing multiple SPV1020s. It should provide the same functions as spv1020_mppt, but with an extra argument specifying which MPPT the command should go to; it’ll then set the demux to address that MPPT, then call the corresponding spv1020_mppt function. It should use the existing generic mux driver.

  • This isn’t a driver because the fact that our SPV1020s are behind a demux is an implementation detail of the board which isn’t appropriate for a generic driver to deal with. This module encapsulates the interaction between the MPPTs and the demux.

...