Peter, Jon and Jan are building a programmable electronic load. This document is the common design sheet.

It's obviously work in progress. And fun.

We're building a programmable DC load. The focus is on making a real world working instrument.

Hardware and firmware are open source.

• 20 V, 6 A
• SCPI controlled

To keep this document readable, this main post gives an overview of the design.

All detailed explanations are broken out in separate posts.

Hardware

The load design is modular.

Two out of box modules:

• MSP432 LaunchPad
• LCD Shield (optional)

3 new designs

• DAC-ADC module
• Analog control module
• Power module

DAC-ADC BoosterPack

This module is a generic, isolated DAC / ADC boosterpack. It's the interface between the analog controller and the microcontroller.

It can also be used outside this project, for your other analog - digital conversion needs.

The board design is broken out in a separate post: Programmable Electronic Load - DAC / ADC BoosterPack.

Analog Controller and Driver Board

This is the core of the analog constant current block. Here lives the circuit that will translate desired constant current into the driver signal for the power MOSFET.

It integrates the feedback coming from that power board. This is a closed analog control loop.

There are also components to provide the on-off functionality and buffers/amplifiers for the analog data-points that fly back to the ADC module.

The board, schematics and BOM are documented in Programmable Electronic Load - Analog Controller and Driver Board.

Power Module - the MOSFET Board with Fan

For details  of the design of the power stage, check Programmable Electronic Load - Power Stage.

BoosterPack Header Use and Pin Allocation

This info is broken out in a separate post: Programmable Electronic Load - BoosterPack Header Use.

Firmware

Prerequisites:

• CCS 8 with MSP432 compiler TI v 16.12.0.STS or >
• TI-RTOS for MSP43X, any SimpleLink version
• MSP432 LaunchPad (not the black pre-prod because it's out of support)

GITHUB location: https://github.com/jancumps/msp432/tree/master/MSP432_SCPI_ElectronicLoad

download latest source files as a zip : https://github.com/jancumps/msp432/archive/master.zip

doxygen generated API documentation: https://jancumps.github.io/msp432

GIT artifacts don't contain CCS project files, only sources - get a zip with CCS project from the attachments at the end of this document.

SCPI interface and Error Handling

The SCPI commands are documented in this breakout post: SCPI interface.

UART Configuration

Together with SCPI, UART is the programming interface of this instrument.

The approach, and how to compile for USB or TTL, is documented in this breakout: UART.

RTOS and Posix Configuration

The TI-RTOS documentation is in breakout post RTOS Config.

LCD Display

Check here for a detailed explanation: LCD Display

The firmware supports SHARP LCD display,

ADC

I've broken out the ADC description to a separate post, because I'm working on improvements:

Programmable Electronic Load - ADC Firmware

DAC

DAC output is set on command, using RTOS MailBox and messaging.

The payload for a DAC message contains the DAC channel that needs to be set, and the value.

typedef struct MsgDAC {
    uint8_t module;
    uint16_t value;
} MsgDAC;

The DAC task is started by RTOS. It inialises the DAC settings, then waits until it receives a message.

void *threadDAC(void *arg0) {


    MsgDAC d_msg;
    d_daci2cTransaction.writeBuf = d_dactxBuffer;
    d_daci2cTransaction.readBuf = d_dacrxBuffer;
    d_daci2cTransaction.slaveAddress = DAC_I2C_ADDR;
    d_daci2cTransaction.writeCount = 3;
    d_daci2cTransaction.readCount = 0;


    mqd_t mq;
    struct mq_attr attr;


    attr.mq_flags = 0;
    attr.mq_maxmsg = 1;
    attr.mq_msgsize = MSGDAC_SIZE;
    attr.mq_curmsgs = 0;
    mq = mq_open(QUEUE_NAME_DAC, O_CREAT | O_RDONLY, 0644, &attr);


    while (1) {
        ssize_t bytes_read;
        bytes_read = mq_receive(mq, (char *)&d_msg, MSGDAC_SIZE, NULL);


        /* wait for mailbox to be posted by writer() */
        if (bytes_read) {
// ...

The waiting doesn't take processor time. RTOS takes care that it will only get a slice of clock cycles when there is a message.

Two things in the RTOS configuration make this happen:

The mailbox with room for exactly one message, and a receive event.

Because there is usually no message in the mailbox, the execution of the DAC logic becomes inactive at this line:

        bytes_read = mq_receive(mq, (char *)&d_msg, MSGDAC_SIZE, NULL);

When we send a DAC message somewhere else in the code (e.g.: when the user requests a new setting of the electronic load), RTOS reactivates the process and hands over the payload message.

The DAC task sets the output of the requested channel and returns to the point where it waits for a new message.

   while (1) {
        ssize_t bytes_read;
        bytes_read = mq_receive(mq, (char *)&d_msg, MSGDAC_SIZE, NULL);


        /* wait for mailbox to be posted by writer() */
        if (bytes_read) {
            d_dactxBuffer[0] = getAddressFromModule(d_msg.module); // set value direct
            d_dactxBuffer[1] = d_msg.value >> 8; // MSB
            d_dactxBuffer[2] = d_msg.value; // LSB
            if (! I2C_transfer(i2c_implGetHandle(), &d_daci2cTransaction)) {
//                System_printf("I2C Bus fault\n");
//                System_flush();
            }
        }
    }

You select the DAC channel by setting bit 2 and 1 in the control byte (tx_buffer[0]). There's a helper function that gives a correct control record.

// address 7 - 6: 0, load mode 5 - 4: 01 direct from i2c, 3: reserved 0, 2 - 1: channel select, 0: pwr down 0
#define DAC857X_CFG_H0 0b00010000
#define DAC857X_CFG_H1 0b00010010
#define DAC857X_CFG_H2 0b00010100
#define DAC857X_CFG_H3 0b00010110

static const uint8_t array_DAC857X_CFG_H[4] = {DAC857X_CFG_H0, DAC857X_CFG_H1, DAC857X_CFG_H2, DAC857X_CFG_H3};

/**
 * get the hex address for the requested DAC module
 */
uint8_t getAddressFromModule(uint8_t module) {
    return array_DAC857X_CFG_H[module];
}

Bits 7 - 3 and 0 are all fixed.

Input Enable

The functionality to activate and deactivate the load is documented here: Programmable Electronic Load - Input Enable Functionality .

Control Strategies

The firmware uses strategies to handle the different types of load operation (e.g. constant current, constant, voltage, ...).

A strategy is a set of functions that you can plug in, and that together run that particular operation type (this is a c version of the Gang of Four's Strategy Design Pattern).

The goal is to avoid that the firmware is riddled with if or switch statements whenever different behaviour is needed depending on the instrument's mode.

Each operation strategy will have the same set of functions that run the instrument in that mode.

The price to pay is not expensive - speed and memory burden is low. It is a little more complex to understand than the c++ version. Once you step trough it with a debugger, things become clear.

The code also tries to hide that we're using strategies

Currently starting to implement constant current strategy. The more difficult operation types can be added later, one by one, with not too much impact on the existing code across the firmware.

. Only the eload API (see below) knows about it. All code goes via that eload API.

API for the stategies is minimal now:

    controlFunction;
    getMode;
    getChar;

eload API

The eload API offers an abstraction layer for the strategies, so that the rest of the firmware doesn't have to know about it. It simplifies switching operation mode and driving the instrument.

Example: The eload API offers a simple function eloadGetMode() to check what the instrument's current mode is.

eload_mode eloadGetMode() {

    return getControlStrategy()->getMode();

}

In the background, it uses the strategy mechanism to fetch the mode from the currently active strategy and call the implementation function.

return getControlStrategy()->getMode();

The eload API also has the common eload functions that don't need a strategy because they are always valid, regardless of mode.

Calibration and Configuration Data

The functionality to store calibration and configuration data in Flash is described in a separate article: Programmable Electronic Load - Calibration Data in Flash.

The calibration and configuration procedures are documented in Programmable Electronic Load - Calibration Steps

Changes To Standard MSP_EXP432P401R.c

The standard file generated by the TI-RTOS application wizard has defaults for peripherals.

The following has changed: none - I removed this section because with the external ADC/DAC board and the SimpleLink RTOS version, everything is kept standard.

Remote Software

Teminal

Serial communication to the USB UART port.

9600/8/1/None

SCPI is a non-echoing protocol. To make the characters you type show in the Terminal, set Local echo to Force on.

If you also set Local line editing to Force on, you have the opportunity to correct characters in the current line before they are sent to the serial port.

Test:

*IDN?;SYST:ERR:COUN?

Should return

THEBREADBOARD,ELECTRONICLOAD,0,01.00;0

Windows GUI

There are two . A .NET made by Peter, a Java version made by Jan.

The .net GUI supports reading the 4 ADCs, setting one of the DACs abd shoot any SCPI command.

There's a window for SCPI output and a status window that shows SCPI errors.

Source and binary available from https://github.com/thebreadboard/SCPI_DC_LOAD_WIN

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

Programmable Electronic Load

Poster

Upload Preview

Ok

Cancel

The Java GUI is made as a POC that cross-platform instrument GUIs are possible.

It allows for switching the load on and off, set constant current and replicate the LCD values.

Additionally, you can requesst error status and run arbitrary SCPI commands.

Programmable Electronic Load - Java GUI Part 1: Basic Functionality

LabVIEW

The instrument comes with a LabVIEW library: Programmable Electronic Load - Write a LabVIEW Library part 1: Initialise Block

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

Programmable Electronic Load

Poster

Upload Preview

Ok

Cancel