Page Comparison

...

To support this, here’s a preliminary, not-fully-fleshed-out module breakdown. Note that there are 2 solar boards, one of which has 5 MPPTs and one of which has 6, so firmware must support both.

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.

...

• logger is a very simple module: when it receives a data ready event, it logs the data from data_store to console in a human-readable way. (Don’t log the 6th MPPT’s data if there are only 5 MPPTs.)

• Once telemetry has been designed, we’ll implement a telemetry_tx module (not sold on the name) whichdata_tx, similar to logger, will take data from data_store on data ready events and TX it over CAN to telemetry. Telemetry or other systems can then use the data.

• fault_monitor encapsulates all the rules for what data levels make a fault. On data ready events, it takes data from data_store and raises a fault event if anything is at a fault level.

...

• 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” “action” events to deal with faults - e.g. events to open the relay or commands to interface with relay and calls the SPV1020 driver 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 open handle opening and close closing the relay when it receives an appropriate action event. mppt_commander (not sold on the name) will issue “SHUT” and “turn ON” commands over SPI to the SPV1020 MPPTs when it receives the appropriate action eventsIt will interface with the DRV120 driver.

Drivers

• mcp3427_adc - driver for the MCP3427 analog-digital converter. Reportedly already exists in the MSXII codebase (project solar_slave) and can be reused.

• spv1020_mppt - driver for the SPV1020 maximum power point tracker and DC-DC converter. Communicates over SPI with the SPV1020s and issues commands (a list can be found in the SPV1020 datasheet). Should provide a separate function for calling each command.

  • Datasheet: https://media.digikey.com/pdf/Data Sheets/ST Microelectronics PDFS/SPV1020.pdf, more info: https://media.digikey.com/PDF/Application Notes/ST Microelectronics Application Notes/SPV1020 AN3392.pdf

• mc74lvx_demux - driver for the MC74LVX138 3:8 demultiplexer (decoder).

  • Datasheet: https://www.onsemi.com/pub/Collateral/MC74LVX138-D.PDF

• drv120_relay or similar - driver for the DRV120PWR relay driver, also used in BMS Carrier.

Comments

• We will have three types of events.

  • Action events will cause something to physically happen - like opening the relay or shutting down an MPPT. They have EVENT_PRIORITY_HIGHEST.

  • Fault events are raised when a fault is detected. They have EVENT_PRIORITY_HIGH.

  • Data ready events are raised by data_store when new data is available. They have EVENT_PRIORITY_NORMAL.

• ICs we don’t need drivers for include:

  • ACS722 current sense: nothing configurable, hidden behind an MCP3427

  • DRV120PWR relay driver: too simple to need a driver (just turning a GPIO pin on and off)

• From a separation-of-concerns standpoint it might make sense to move the MPPT fault detection logic out of sense_mppt to its own module since it isn’t strictly related to data collection, but that would be more complex and would require duplicating the soft timer logic (though that could be desired if we wanted to check faults more or less frequently). We could do it either way.If solar needs to communicate with centre console over CAN then we’ll need can_rx and can_tx modules to send data and receive commands.