Version 194

    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)

     

    The firmware is for the MSP432 microcontroller. But the harware can be driven from any controller, processor, PSoC or computer that can deliver i2c and power between 3V3 and 5V.

    That includes Arduino, Raspberry Pi, BeagleBone, Warp7, IOT20xx, the ST Neo family, ... As long as they match that voltage range and have I2C master, it 'll work.

    The ADC/DAC board takes care that the logic side is galvanicaly isolated from the power side (that is, if you leave the P1 and P2 jumpers open).

     

    The only requirement is that you have a positive supply between 3V3 and 5V, a ground, and I2C signals (the board has I2C pull-ups that connect to the positive supply that you provide. If you don't want that (maybe your dev board already has 'm), leave R1 and R2 off.

    ADC, DAC and Enable are all I2C driven.

     

    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.

    eload003.jpg

     

    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

     

     

     

    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

     

     

     

     

    Related blog

    Programmable Electronic Load - Input Enable Functionality
    Programmable Electronic Load - Power Stage
    Programmable Electronic Load - Temperature Protection
    Programmable Electronic Load - DAC / ADC BoosterPack
    Programmable Electronic Load - Analog Controller and Driver Board
    Programmable Electronic Load - SCPI interface and Error Handling
    Programmable Electronic Load - UART
    Programmable Electronic Load - RTOS Config
    Programmable Electronic Load - Calibration Data in Flash
    Programmable Electronic Load - Calibration Steps
    Programmable Electronic Load - LCD Display
    Programmable Electronic Load - ADC Firmware
    Programmable Electronic Load - Current Sense Circuit
    Programmable Electronic Load - BoosterPack Header Use
    Programmable Electronic Load - ToDo and Done
    peteroakes articles:
    Electronic DC Load - Design and Build to test PSU Project
    youtube: Electronic DC Load Design and Testing
    youtube: Full Build Analogue DC Load
    youtube: Electronic DC Load - Performance Improvements
    Raspberry PI 2, Fun with I2C DACs and ADC's
    jc2048 articles:
    Programmable Electronic Load: Dynamic Behaviour: Part 1 Overview
    Programmable Electronic Load: Dynamic Behaviour: Part 2 The Servo Loop
    Programmable Electronic Load: Dynamic Behaviour: Part 3 Effect of Output Inductance
    Programmable Electronic Load: Dynamic Behaviour: Part 4 Effect of Output Voltage Change
    Programmable Electronic Load: Dynamic Behaviour: Part 5 Stability
    Programmable Load Build
    jancumps articles:
    Programmable Electronic Load - ADC and DAC BoosterPack test
    Programmable Electronic Load - Analyse the Summing Node Zero Point
    Programmable Electronic Load - Measurements Part 1: Control Circuit
    Java GUI
    Programmable Electronic Load - Java GUI Part 1: Basic Functionality
    Programmable Electronic Load - Java GUI Part 2: Support for Current Mode, Input On/Off, Error Log
    LabView
    Programmable Electronic Load - Write a LabVIEW Library part 1: Initialise Block
    Programmable Electronic Load - Write a LabVIEW Library part 2: Read Output Block
    Programmable Electronic Load - Write a LabVIEW Library part 3: Close Block
    Programmable Electronic Load - Write a LabVIEW Library part 4: Function Set Block
    Programmable Electronic Load - Write a LabVIEW Library part 5: Input Control Block
    Programmable Electronic Load - Write a LabVIEW Library part 6: Raw DAC Block
    Programmable Electronic Load - Write a LabVIEW Library part 7: Raw ADC Block
    Programmable Electronic Load - Automating a DC Switcher Efficiency Test with LabVIEW
    Programmable Electronic Load - LabVIEW Test Automation: Characterise the Instrument
    Programmable Electronic Load - LabVIEW Test Automation: Characterise the Instrument Pt 2: Oscilloscope Measurements
    Example LabVIEW Scenario: test a design with a Rigol PSU and a Keithley DMM
    TI-RTOS: Switching to the SimpleLink Distribution
    Switch from TI-RTOS to SimpleLink POSIX: Threads and Semaphores
    Switch from TI-RTOS to SimpleLink POSIX: EEPROM API
    Switch from TI-RTOS to SimpleLink POSIX: From MailBox to Message Queue
    Switch from TI-RTOS to SimpleLink POSIX: LCD Display Driver
    Switch from TI-RTOS to SimpleLink POSIX: Sleep when Idle