Go Down

Topic: Arduino Shield for programmable DIY bench power supply with SCPI support (Read 604 times) previous topic - next topic

prasimix

Hi everyone,

This is my first post in which I'd like to present an Arduino Shield designed for controlling dual channel DIY bench power supply.
My colleague and I are working on it for some time to provide all hardware and software functionality that we hope could be beneficial to anyone who'd like to follow our power supply design or use it with their own.

History
A whole thing starts as just an another attempt to build bench power supply, an essential tool for experimenting and prototyping.
Idea was to build something in between commercial "heavy weights" that comes from brands such as Keysight (ex. Agilent, ex. HP) or Keithley and many others (that recently starts to got Chinese counterparts like Rigol or Siglent) and DIY projects based frequently about small MCU that indeed include some of Arduino boards and designs. The gap between mentioned solutions is huge both in hardware and software sense. When we talk about hardware then commercial solutions leads in e.g. power capacity, long term precision and reliability. On the software side at least one feature is distinctive and comes almost without exception with commercial powers supplies: that is remote control/programming and monitoring based on SCPI command set that use IEEE488, Ethernet or USB as communication layer.
DIY projects that uses MCU for digital control is mostly based around low-end MCU what sounds logical since there is no big deal in setting voltage and current and read it back. 4x4 keypad or incremental encoder as an input and two line LCD display on the output and   that's all you need especially when there is readily available code when one decide to use Arduino sketches.
Following that logic our first attempt was to use Atmel ATmega32U4 that is in the core of the now retired Leonardo board. We enrich it with few things that lacking such as external EEPROM for more capacity, RTC and Ethernet controller. We started building power supply firmware and relalize very soon that 32K (-4K) of flash memory is far too low. Just adding Ethernet library was enough to exceed mentioned limit. Yes, most of DIY power supply do not utilize Ethernet since USB is on the disposal and therefore why to use it? But USB cable length cannot be compared with Ethernet one.

Arduino Shield
That was a moment for redesigning everything. Instead of adding more capable MCU to a new digital control PCB we made decision to build an Arduino Shield. In that time only two boards fit in our requirement for (much) more memory: Mega2560 and Due. Their form-factor dictated the size of the new board, together with enclosure that was chosen previously that we found affordable and of nice quality that comes from Hi-fi 2000/Modushop.biz.
Hopefully Arduino will continue to offer mentioned and new boards using the same form factor (even newcomers such as Zero or MKR1000 does not support that claim).
When decision about form factor was made, another was about supporting architecture because Mega and Due comes from different clans: 8-bit AVR and 32-bit ARM that is programming-wise made transparent thanks to the Arduino IDE but on the hardware levels require different supply and logical level voltages: 5V and 3.3V. That decision simplify existence of really versatile Texas Instruments bus transceiver: SN74LVCC3245. Now we could continue with development taking into account some already used features that such digital control board should have.

Feature overview
  • Outputs and remote sense inputs protection using TVSs, MOVs and SAR
  • LED indications for output enable, remote sense and Stand-by mode
  • Power relays for making serial or parallel connection of two outputs
  • Signal relays for remote or local voltage sense
  • Connectors for hosting Arduino Mega/Due board
  • On-board 3.3V/1A LDO powering all peripherals
  • Analog input for temperature sensor
  • Soft-start/Stand-by control for the Auxiliary power supply module
  • Level shifters for 3.3V ↔ 5V (3.3V ↔ 3.3V is also supported)
  • Digital isolators for two SPI-bus/port for output channels control (power supply's post-regulator module)
  • Buzzer
  • External EEPROM
  • Real-time clock (RTC) with supercap back-up
  • Ethernet controller
  • TFT color display with touch-screen
  • LED CV/CC mode indicators
  • Optional V/F (Voltage-to-Frequency) converters for isolated temperature sensors (NTCs) that can be used for battery temperature monitoring


Few pictures

Rear side without Arduino board


Read side with Arduino board plugged in


Front side with binding posts mounted

In the few posts that follows I'll present in more details hardware and software aspects of this shield and some plans for the future changes and improvements.

prasimix

Let's continue with schematic. It is organized in five sheets and I'll describe it as it appears in Eagle files that could be found on the GitHub.

Binding posts section
This section is added to simplify wiring of power outputs, remote sense inputs and serial and parallel connection of two channels without external wires. The is another maybe not so obvious advantage of such wiring: it does not leave a room for erroneous wiring and programming, e.g. that polarity are mismatched or that channels connected in parallel are programmed with different output voltages.
Output terminals and remote sense input terminals are protected against reverse polarity and over-voltage spikes using TVS (ZD1 - ZD4), MOV (VR1 - VR8) and SAR (SAR1, SAR2) components.



Serial connection is established through power relay K_SER while for parallel connection the K_PAR power relay is used. Both relays is rated for 8A and should withstand 50VDC switching without load connected. When driving serial or parallel relay the following things has to be taken into consideration:
Voltage and current has to be set to zero before channels are connected or disconnected. The easiest way to do that is to disable output (OE is off) but it's also recommended to also program output values to zero.
Parallel connection could follows only if programmed output voltages are the same on both channels
Optionally down-programmer circuit could be disconnected on one of the channels that are connected in parallel
Mentioned recommendations should be taken seriously otherwise it is possible to damage either the PSU and/or connected load. For example when we tested outputs connection in serial with connected load and OE was switched on when total voltage became higher then 60V, the K_SER relay was irreparably damaged during disconnection! Contacts were simply melted down and left shorted.
Since separate power relays is used for outputs connection is serial and in parallel it is possible to activate it simultaneously by software. If that case the outputs of the both channels will become shorted that could be dangerous if e.g. over-current protections was not set. To avoid such situation a hardwired blockage is added (the Q4 mosfet) to inhibit parallel power relay (K_PAR) when serial power relay (K_SER) is activated.
Two tiny signal relays (K_S1, K_S2) are used to control voltage sense that could be local or remote. By default (when relay is not polarized) sense inputs are connected locally - to the power outputs. When load is remote and voltage accuracy is critical for the connected load, sense inputs become connected to a separate pair of binding posts.
All relays are controlled by TLC5925 that is a 16-channel constant current LED driver that is intentionally selected because we wants to add a LED indications of biding posts states and makes them in that way more obvious to the user. Therefore one LED is added above each of eight binding posts. When channel's outputs are enabled a pair of green LEDs are illuminated. Remote sensing is backed with illumination of yellow LEDs. Connection of output channels in serial or parallel is also indicated thanks to bi-color LEDs used above channel one power outputs. In that case LEDs are illuminated in red.
All allowable binding posts connections with LED indications and programming codes that can be used for controlling TLC5926 are listed below.



Arduino board interface
Arduino Mega and Due have seven female headers used for interfacing with I/O pins, power, reset, etc. They are located at the three board sides and we learned that such arrangement is quite impractical when board has to be removed. A close attention is required to not bend one or more pins on the Arduino Sketch side. Interfacing with the Arduino board is done using SN74LVCC3245A as a level shifter. Five (IC2, IC3, IC4, IC5, IC7) are used for pins that will be programmed as digital outputs and an another one (IC8) is used for digital inputs. IC3 and IC5 are handling LCD 16-bit data bus and rest of the outputs controls various "chip selects", SPI bus output signals (SCLK and MOSI) and similar signals.
Input level shifter (IC8) is passing SPI bus input (MISO) and interrupt requests from the installed peripherals. Pin mapping of all used pins is described in the attached document (PSU Arduino pin mapping r1B12b.pdf).
Main power comes to the pin 5V (MCU_POWER header) that is also applicable in the case of Due since it has on-board LDO to step down to the working 3.3V.



SPI ports isolators
The Arduino Shield has to control two PSU channels that are electrically isolated by default and they have to stay isolated when are connected to the shield. That means that digital control signals cannot share the common ground. If such connection exists it could be even dangerous when e.g. channel outputs are connected in serial or when the PSU is used as a symmetrical source (positive output from one channel is connected to the another channel negative output). Digital channel isolation is accomplished using Silabs high speed digital isolators.



The SPI bus port pin mapping is compatible with the ICSP 10-pin header:



Eight lines in total has to be isolated for each channel and both input and output directions is needed. Six line isolators (IC9, IC12) are used for outputs and two line isolators (IC10, IC11) for input signals. MISO input require special attention. Used isolators are not 3-state what is a requirement for the MISO signal since only one device could send data to the MCU at the time. Lack of 3-state outputs on the isolators is fixed with additional buffer gate (IC10C, IC10D) that can provide 3-state output.

On-board peripherals
The SPI bus used for isolated communication with peripherals that resides on two PSU channels is also used for making connection with few other SPI peripherals located on the shield itself. They are added to "equalize" features on both Arduino board variants. EEPROM (IC15) and RTC (14) are added because Due is lacking former and Mega is lacking later. The RTC is also powered with a 1F Supercap that should be enough for running for a couple of weeks when the main power is not present.
On top of that SPI Ethernet controller (IC16) is added and socket (LCD1) for hosting TFT display. Display controller use parallel 16-bit data bus, but touch screen controller also need SPI.
Few other things that are directly connected to the MCU pins are also included:
  • Buzzer driven with digital output (via Q8)
  • Temperature sensor connected directly to an ADC input and
  • Display back light adjustment driven with PWM output (via Q9)


prasimix

CC/CV indicators and optional temperature sensing
Channel output mode of operation is indicated using two LEDs: Yellow for constant voltage or CV (LED_CV1, LED_CV2) and red for constant current or CC mode (LED_CC1, LED_CC2). Most of the time the channel output will be in one of that two modes. But there is also the third mode that is called unregulated or UR when output is possibly under influence of both CV and CC control loops. This mode is indicated by switching off both LEDs.



Finally the shield contains one optional circuit that could be used for isolated measurement of the outside temperature. That could be a battery NTC sensor used for monitoring battery during fast charging or discharging cycles. Temperature sensor connector (X10, X12) is located near the channel's binding posts. Its output is analog, a variable resistance that depends of the temperature. It has to be isolated for the same reason that is mentioned for SPI buses: to avoid connection of their grounds to the same potential. Analog isolator circuit is not used here because it's in general more complex or expensive for the same precision. Therefore the sensor output is first converted to a digital signal by mean of V/F (voltage-to-frequency) conversion using popular 555 timer. For better linearity NTC is not connected directly to the timer but a current mirror circuit is used (IC17, IC19). Timer output signal could be now digitally manipulated. We had two possibility here to forward it to the available Arduino digital pin programmed as input or to connect it to the I/O expander that is located on the post-regulator module and  which has few unused digital pins. Advantage of the later over the former is that it does not require additional isolation if the whole V/F converter is also powered from the post-regulator module. We decide to use such type of connection.
Complete idea about monitoring temperature of the connected load is still in the early phase. It remains to be seen how it will works in practice. Eventually it could be replaced with an analog isolator when the analog signal will be forwared to the one of Arduino ADC (analog) inputs.

prasimix

A two layer PCB (200 x 105 mm) is used with clearly separated analog (output protections, relays and V/F converters) and digital section. Binding posts (nine of them) can be directly mounted on the PCB from the PCB rear side (that is enclosure front side). The same is valid for all LED indicators (12 mm spacers are used to simplify montage).
The Ethernet RJ-45 jack is also hosted on the PCB. Therefore additional short (30 cm) adapter cable is required to make it reachable from the enclosure rear panel.
The Arduino is positioned in the way that neither part on the shield or Arduino board touch each other.


Arduino Shield for bench power supply PCB layout (both side)


Arduino Shield for bench power supply PCB layout (top layer)


Arduino Shield for bench power supply PCB layout (bottom layer)

prasimix

#4
Dec 30, 2015, 06:33 pm Last Edit: Dec 30, 2015, 06:47 pm by prasimix
This shield could be further developed in various ways. Here is some ideas that should be feasible within existing PCB dimensions:

  • Add support for more output channels; at least one to have under control some kind of "aux" low voltage/high current output e.g. 0-8V/0-5A
  • Add automatic recognition of board using Arduino IOREF pin (jumper JP2 could stay on the PCB if one don't want to solder components required for IOREF monitoring)
  • Replace or complement the Ethernet with wireless (e.g. module such as Microchip's MRF24WG0M)
  • Add two more signal relays to cover remote sensing case when two channels are connected in serial
  • Rearrange binding posts to have in one row power outputs and in another remote sense inputs that uses much smaller connectors
  • Somehow combine LED indicators from the BP section with CC/CV indicators
  • Dedicate more inputs for NTC temperature sensors
  • Add digitally isolated inputs for external triggering
  • Add digitally isolated outputs for e.g. relays control
  • Add isolated and clamped analog input (i.e. 0-2.5V) for direct control of output voltage or current. That can be used in scenario when e.g. the channel output acts as an pre-regulator that track output voltage of the connected D.U.T.

The shield could be sized down both physically and "logically/electrically" when budget is tighter. If smaller PCB is required a complete BP section that contains output protections and convenient connection between two channels without extra wires could be removed and cut PCB size in half. "Electrical" reduction will decrease circuit complexity and parts count. That can be done by removing support for the Mega board when all level shifting logic (IC2, IC3, IC4, IC5, IC7 and IC8) are not needed anymore.

Finally, such shield could host complete power part i.e. pre-regulator and post-regulator. One idea is to use SMPS pre-regulator based on TI's TPS54560 that in theory (or with massive air flow) could deliver up to 5A and withstand up to 60V on the input. It requires minimum additional parts for functional solution. As an post-regulator we are thinking about power operational amplifier OPA548 (TI again, actually ex. Burr-Brown) that can provide continuously 3A and withstand up to 60V and requires few parts for functional solution. I think that is reasonable to expect 0-30V/0-3A range with mentioned combination.
Also, with such approach and if precision/resolution is not critical it's possible to deploy ADC and DAC/PWM built in MCU on the Arduino board.

prasimix

Please find below few pictures of the shield mounted in the power supply enclosure that is almost finished (only acrylic front panel mask is missing that I'm going to order from the service such as formulor.de) ...











prasimix

Firmware for this shield is an Arduino sketch that can be without limitation run on both Mega and Due boards. In addition to that we also made a software simulator and thanks to that one can test all currently implemented functionality on e.g. Windows, Linux or OS X. Precompiled version for Windows and instruction how to compile it on Linux and OS X are available here, but I'd like to suggest to read this post to the end before doing it.

The firmware is still under development and the first milestone is reached recently. That release is called M1 (from Milestone one) and is also available on the GitHub. It comes with SCPI commands that allows remote control of most power supply functionality (a whole list is presented in Section 12 of the SCPI reference guide). Communication is possible using USB port that resides on Arduino board or over Ethernet that is included on the shield. Actually, currently is possible to simultaneously use both of them but in the future when local user interface is enabled it will be possible to switch between local or one remote interface at the time.
The good thing about SCPI commands is when you become familiar with them you can used it with almost any high-class instruments that comes from names such as Keysight, Keithley, Rohde & Schwarz, etc. Also SCPI controllers

Set basic power supply's parameters
Supported SCPI commands are listed and described in more details in SCPI reference guide which exists in PDF/ODT and online form. SCPI commands are text-based and it can be send using serial terminal or telnet session. For example, if we want to set voltage to 10V and max. current to 150mA on the currently selected channel one has to type in the following commands:

VOLTage 10
CURRent 150ma

SCPI commands are not case sensitive, and mix of upper and lower cases is intentional and it's regularly used to make distinction between allowed shorter and longer command format. Therefore the following commands will have the same effects:

volt 10
curr 150ma

When voltage and current are programmed it remains only to enable output what can be done using any of the following command on the first channel:

OUTPut, CH1 ON
outp on
outp 1

If we want to do something on the second channel we have to use INSTrument command to select it, since according to SCPI nomenclature each power supply channel represent one instrument. The following example sets 40V, 2A and enable output of the second channel:

inst ch2
volt 40
curr 2
outp 1

VOLTage and CURRent actually belongs to SOURce command subset but since the power supply is by default sourcing device that command is not mandatory but it could be useful since it allows selection of instrument. Therefore if we want to program channel two voltage to 3.3V without changing selected channel we can use the following:

sour2:volt 3.3

Both VOLTage and CURRent could be also use for query currently programmed values. For that question mark (?) is used:

volt?
10.00

Command that is not (yet) included in the SCPI standard but is widely available is APPLy. It can be used for quick programming of both voltage and current on the channel of choice. If we want to programm 12V and 600mA on the first channel we can simply type:

appl ch1, 12, 0.6

The same command is also query command, therefore it can be used to find out currently programmed values, but also allowed ranges. For example:

appl? ch1

could return:

CH1:40.00 V/5.00 A, 12.00, 0.60

Where 40V is max. voltage and 5A max. current that can be programmed on the channel. In this post I'd like to mention just one (two) functionality that is already supported in M1 firmware that can be useful: over-voltage (OVP) and over-current protection (OCP).

The current PSU design do not include dedicated OVP and OCP circuits. Therefore voltage and current protection is implemented by monitoring programmed output values (VOLTage and CURRent) and mode of operation (CV or CC) combined with delay time required for "tripping". For example if we'd like to activate over-current protection what has to trip after 50ms we'll monitor the moment when channel changes from CV to CC mode of operation. If channel stays in that mode for more then mentioned 50ms the output will be turned off (OUTPut OFF) and we'll have indication that OCP was tripped.

Over-voltage protection (OVP)
the following SCPI commands for over-voltage protections is now supported:

[SOURce[<n>]]:VOLTage:PROTection:STATe
[SOURce[<n>]]:VOLTage:PROTection:DELay
[SOURce[<n>]]:VOLTage:PROTection:TRIPped?


The first one is used for enabling OVP, the second one for defining required time delay before OVP will "tripped" and the last one can be used to check if OVP is tripped. Again, since we don't have dedicated OVP circuit we cannot define level higher then that is programmed with VOLTage command. I don't know if make any sense to eventualy provide OVP voltage level setting that is below programmed voltage. If such case exists please let me know and we can add appropriate command that is [SOURce[<n>]]:VOLTage:PROTection:LEVel <voltage>.
Activating such protection before connecting load does not make sense because it will trip immediately after programmed DELay expire. For example we will set output voltage to 25V and current to 1A that is low enough that with connected load channel will immediately enters CC mode of operation. If load resistance is increased or loaf is disconnected that voltage reach programmed 25V for more then 50ms, the OVP will trip:

volt 25
volt:prot:stat on
volt:prot:del 50ms
outp on

The channel output will looks like this:



We can check output and OVP function state using the following sequence:

outp?
0
volt:prot:trip?
1

If OVP or any other protection was activated (tripped), it is not possible to turn on channel output before clearing "trip" state. We can see that in the following example when OUTPut ON attempts will generate an error that is queried with the SYSTem:ERRor[:NEXT]? command:

outp on
outp?
0
syst:err?
201,"Cannot execute before clearing protection"

Trip reset of OVP but also OCP and OPP (over-power protection) require execution of the following command:

OUTPut:PROTection:CLEar

The following sequence shows that channel output successfully is activated again when it is executed:

outp:prot:cle
outp on
outp?
1

Over-current protection (OCP)
Command set for over-current protection is similar to that for OVP and the working principle is the similar:

[SOURce[<n>]]:CURRent:PROTection:STATe
[SOURce[<n>]]:CURRent:PROTection:DELay
[SOURce[<n>]]:CURRent:PROTection:TRIPped?

In this case the output current programmed by the CURRent command and change of operation mode to the CV mode is used as a trigger. If such condition exists on the channel for more then a programmed delay the OCP will "trip". During OCP initialization it is not necessary to have load connected, and if it's connected it has to be low enough that channel remain in the CV mode of operation. Here is an example how to initiate OCP on 1A with 5ms delay:

curr 1
curr:prot:stat on
curr:prot:del 5ms
outp on

OCP trip will cause the following changes on the channel output:



The following command sequence can be used to check OCP activation, clear/reset protection and make output active once again:

curr:prot:trip?
1
outp?
0
outp:prot:cle
outp on
outp?
1

Software simulator
All above mentioned actions require live harware: Ardino shield and other modules. But you don't need to build a whole system to test how SCPI is working thanks to software simulator. It is currently a command line application that when started looks like this:



It can be used directly to enter SCPI commands and get query results or you can also test remote access with telnet session on the port 5025:








polymorph

Steve Greenfield AE7HD
Drawing Schematics: tinyurl.com/23mo9pf - tinyurl.com/o97ysyx - tinyurl.com/q7uqnvn
Multitasking: forum.arduino.cc/index.php?topic=223286.0
gammon.com.au/blink - gammon.com.au/serial - gammon.com.au/interrupts

prasimix

I want to thanks to everyone who were already downloaded the M1 firmware and invite all other to try it and post here comments and suggestions.

Firmware in version M1 still do not allows that some of the PSU parameters can be set and read using the SCPI commands nor using the local console that is not supported at all in this version. That issue is addressed to some extent by using few configuration files with parameters that could be altered during the compilation time. This post describe the content of the following configuration files:

  • conf.h
  • conf_advanced.h
  • conf_channel.h
  • conf_user.h

We would not like to recommend changing any of the parameters defined in the first three of above mentioned files. Instead of that conf_user.h should be used to override existing values with a new one.
conf.h
Basic firmware parameters are defined in conf.h. That includes definition of SPI peripherals installed on Arduino shield board but also used channel's types defined with their programmable voltage and current ranges. The over-temperature protection (OTP) default values for the MAIN sensor are also defined here.
The SERIAL_SPEED is the only parameter that is used for serial communication configuration. Default is 9600 baud and it can be changed to any of the following speed: 300, 1200, 2400, 4800, 19200, 38400, 57600, 74880, 115200, 230400 or 250000.

conf_advanced.h
This header file contains most of the parameters that are used for firmware configuration. That also includes the power supply's identification used in *IDN? query (PSU_SERIAL, MANUFACTURER and FIRMWARE), DAC and ADC parameters, calibration parameters and over-temperature protection (OTP) values.
SCPI parser input buffer length (SCPI_PARSER_INPUT_BUFFER_LENGTH) is by default set to 48 and it can be increased to e.g. up to 255 but please note that will consume twice as much SRAM memory with each increment because two buffers was implemented: one for serial and one for Ethernet communication. That can generate problem during compilation on Arduino Mega in first place because it has only 8 Kb of SRAM.
The following three constants requires additional attention:

  • CONF_WAIT_SERIAL - defines does serial communication is required to start firmware execution. It's disabled by default. Keep in mind that if you enable it then nothing will happened when power is switched on without USB cable connected and a serial console (e.g. Arduino Serial Monitor) is up and running.
  • CONF_DEBUG - determines if additional debug messages will be send to the serial console as an assistance in the development process since no real-time debugger is available in Arduino IDE. All debug messages started with ** and some examples are shown on picture below. This constant that is currently enabled by default could be disabled to decrease compiled sketch size.
  • CONF_DEBUG_LATEST - represents additional condition for generating debug messages and it's usually used as an assistance in debugging code that is recently added when additional reporting is required.




conf_channel.h
Channel specific information such as pin mapping used for each channel is defined in conf_channel.h. Additionaly all possible variations of channel's capabilities are listed here. Original file contain three voltage ranges (up to 30, 40 and 50 V) and two current ranges (up to 3.12 and 5 A) that has to match capabilities of the post-regulator board for proper operation. If one wants different voltage and current ranges e.g 0 - 25 V or 0 - 2 A it can be done here simply by adding new channel profile following the defined structure.
Together with mentioned voltage and current ranges that are represents with three values (MINimum, DEFault and MAXimum), channel profile contains information about voltage and current STEP change (see SOURce[<n>]]:VOLTage:STEP and [SOURce[<n>]]:CURRent:STEP), calibration LEVels (see CALibration:VOLTage:LEVel and CALibration:CURRent:LEVel), OVP and OCP parameters.
Finnaly over-power protection (OPP) profiles are also defined here as a mix of above mentioned voltage and current profiles.

conf_user.h
An example how to override channel's profiles defined in conf.h is added into conf_user.h:
Code: [Select]

#pragma once
// Example: redefine channels
/*
#undef CHANNELS
#define CHANNELS \
    CHANNEL(1, CH_PINS_1, CH_PARAMS_50V_3A), \
    CHANNEL(2, CH_PINS_2, CH_PARAMS_30V_3A)
*/


Procedure is simple: parameter that we want to change first needs to be undefined (#undef) when a new definition follows using the #define operator.
Above mentioned change can be checked with *IDN? or APPL? query:

*IDN?
EEZ,PSU 1/50/03-1/30/03 (Simulator),123456789,M1

APPL? CH1
CH1:50.00 V/3.12 A, 0.00, 0.00

APPL? CH2
CH1:30.00 V/3.12 A, 0.00, 0.00

TonyD

As polymorth, very impressive project +1.

Is this the same project as seen on eevblog?

prasimix

Yes, I started it concurrently on EEVblog and diyaudio before and didn't want to bother members of this forum with past mistakes, misunderstandings, death ends, etc. But I'd like to post information about current progress and get your opinions about ideas that we are currently digesting.
I hope that many interesting thing will be ready soon on the software side. On the hardware side it's currently battle in progress how to make a whole thing more modular and simpler and still be capable of running serious chunk of software that we already started to develop using the Arduino IDE. Eventually we will end up with one board that can provide "no-nonsense" power supply functionality and capability that is already achieved. There is many obstacles and here are some of them:

  • Which MCU board to use? Here we have to think about availability, price and capacity (e.g. Due looks like a perfect fit but it's now obsolete, or will be soon).
  • "Open form" design as many Arduino shields are or enclosured one? Enclosure looks mandatory for stand alone units especially if one wants to go with 50VDC range that is proclaimed dangerous and require safe operation
  • What's about connectivity: USB and Ethernet is here but what's about "wireless"? In that case what platform to use and what protocol? Wifi, Bluetooth, ...? What's e.g. about ESP8266 that already got decent support for Arduino IDE?
  • Local presentation: we are working on adding support for TFT with touch screen, but do we really need it? Maybe everything could be simply forward to smartphone or PC screen? Does it make sense to have a programmable power supply module that by default require remote console?
  • main(s) supply: shall we proceed with using mains transformer or maybe we should add at least as an option DC input from external AC/DC adapter regardless of the type (open/closed frame for internal mounting or as stand alone unit regularly used with notebooks)

Your input is appreciated.

prasimix

We are working on adding support for local console that is in our case 3.2" TFT color display with touch screen. The touch screen functionality is provided using XPT2046 controller and UTouch library is used to communicate with it via Arduino IDE. And it works ... and after next power up is stops to work,... etc.   :smiley-roll-sweat:
We spent two days before we finally realized that initiation function UTouch::InitTouch(byte orientation) missing an important first time control byte setup!

So if anyone else currently experience similar erratic behavior it has to add the following code at the end of above mentioned function:

Code: [Select]

    cbi(P_CS, B_CS);
    // command for reading X position, but only bit 0 and bit 1 are relevant
    // and have to be set to zero (see table 8. in datasheet)!
    touch_WriteData(0x90);
    sbi(P_CS, B_CS);


The XPT2046 datasheet seems to have also some minor errors so I'm sending a version with my correction in the attachment.


Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy