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.
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
Top Comments