Yes, on first start gui is not active, but once it's opened it will be remembered. A whole thing about gui is in embryonic state in M1 but that will be major addition in M2 since simulator will follows all functionality added for working with the local TFT/touch-screen.
Hm, that's strange and I didn't test ...
Code:
clone https://bitbucket.org/eez-open/psu-firmwareEspressif ESP8266 support in Arduino IDE
Don't know how many of you are aware of what's going on with ESP8266. I'm quite pleased and impressed with its features and price. It was also nice to learned that it could be also visible/programmable via Arduino IDE that we are using for developing this firmware. More information about Arduino IDE support can be found here.
Just for a test, we tried to compiled firmware for that Wi-Fi SoC and with success
. Of course, that still doesn't mean that it could be used as a direct replacement for Arduino boards, but some of you maybe will got an idea about what one of the possible future path/branch could be .
Don't know how many of you are aware of what's going on with ESP8266. I'm quite pleased and impressed with its features and price. It was also nice to learned that it could be also visible/programmable via Arduino IDE that we are using for developing this firmware. More information about Arduino IDE support can be found here.
Just for a test, we tried to compiled firmware for that Wi-Fi SoC and with success
. Of course, that still doesn't mean that it could be used as a direct replacement for Arduino boards, but some of you maybe will got an idea about what one of the possible future path/branch could be .
Playing with M1 firmware configuration parameters
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:
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_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:
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
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:
#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
Last edited:
Working with touch screen
The touch screen really has a central place in this project. Therefore predictable behavior with high level of precision is of paramount importance.
We spent (or wasted) considerable amount of time guessing what going wrong with touch screen control. Possibly we just discover hot water by finding that working with touch screen is not straight forward. Maybe the problem laying in unfortunate match of resistive sensor and touch controller (XPT2046). At the beginning a Utouch library is taken for granted as "the solution" for small displays and comes with Arduino support that we need.
But, after some time my colleague realized that Utouch missed many things and that simply blaming hardware is not fair. Actually it's possible to completely change situation from frustrating and completely unusable to precise and predicable solution. He started with tweaking existing utouch, and finally gave up completely from it and in addition deploy tactics that David Beer presented here (thank you very much David!).
I prepared two short demos, first one with simple filtering and second one with new approach:
https://www.youtube.com/watch?v=_mrBomMLKiI
https://www.youtube.com/watch?v=BP_5paHGkL8
The touch screen really has a central place in this project. Therefore predictable behavior with high level of precision is of paramount importance.
We spent (or wasted) considerable amount of time guessing what going wrong with touch screen control. Possibly we just discover hot water by finding that working with touch screen is not straight forward. Maybe the problem laying in unfortunate match of resistive sensor and touch controller (XPT2046). At the beginning a Utouch library is taken for granted as "the solution" for small displays and comes with Arduino support that we need.
But, after some time my colleague realized that Utouch missed many things and that simply blaming hardware is not fair. Actually it's possible to completely change situation from frustrating and completely unusable to precise and predicable solution. He started with tweaking existing utouch, and finally gave up completely from it and in addition deploy tactics that David Beer presented here (thank you very much David!).
I prepared two short demos, first one with simple filtering and second one with new approach:
https://www.youtube.com/watch?v=_mrBomMLKiI
https://www.youtube.com/watch?v=BP_5paHGkL8
Output settings using touch-screen
Finally all required coding, testing and tweaking required for programming output parameters are finished and I made a short video about that. This first video covers all 3 input modes: Slider, Step and Keypad. The first two also have interactive/non-interactive option that gives us 5 possible input modes.
The 40 V/5 A prototype is used controlled with Arduino Due. As you can see many options are still missing but the biggest obstacle - having usable screen-touch control is resolved. As you can see I didn't use stylus during the whole presentation just my finger (that is maturely thick). Now we can continue more comfortably to add everything that is already available over remote console (using SCPI commands) to the local interface and I'll try to cover progress with more videos.
Your comments are highly welcomed.
https://www.youtube.com/watch?v=jofIdGx2gTg
Finally all required coding, testing and tweaking required for programming output parameters are finished and I made a short video about that. This first video covers all 3 input modes: Slider, Step and Keypad. The first two also have interactive/non-interactive option that gives us 5 possible input modes.
The 40 V/5 A prototype is used controlled with Arduino Due. As you can see many options are still missing but the biggest obstacle - having usable screen-touch control is resolved. As you can see I didn't use stylus during the whole presentation just my finger (that is maturely thick). Now we can continue more comfortably to add everything that is already available over remote console (using SCPI commands) to the local interface and I'll try to cover progress with more videos.
Your comments are highly welcomed.
https://www.youtube.com/watch?v=jofIdGx2gTg
Support for multiple revisions
An important feature is added in M2 firmware that allows us to support various types of power boards and control boards (Arduino shields). That was required since we have now two designs that we are planning to support in the future. This functionality will enables us and 3rd party to add support for new revisions.
The power board variant is defined in conf.h. A mix and match of various variants is allowed. For example default configuration defines two rev.4 boards:
If I'd like to mix rev.4 board with 0-50 V/3 A (Ch#1) capability with newest one with 0-40 V / 5 A (Ch#2) capability I need to use the following declarations:
The Arduino shield is defined in conf_user_revision.h:
Additionally a new set of SCPI commands are added that helps identifying what is declared in firmware.
SYSTem:CHANnel
SYSTem:CHANnel[:COUNt]? returns the number of output channels.
SYSTem:CHANnel:MODel? returns the channel model identification, for example:
SYST:CHAN:MOD?
"Power_r5B6b"
For output voltage, current and power capability you can use SYSTem:CHANnel:INFOrmation:VOLTage?, SYSTem:CHANnel:INFOrmation:CURRent? and SYSTem:CHANnel:INFOrmationOWer? (please note that max. power is not necessary simply multiplication of max. voltage and current).
Interesting info could be queried with SYSTem:CHANnel:INFOrmationROGram? that returns a list of all programmable features of the channel. For example for R5B6B it will returns:
SYST:CHAN:INFOROG?
"Volt, Current, Power, OE, DProg, LRipple, Rprog"
where DProg denotes Downprogrammer, LRipple a "low ripple" mode of operation when SMPS pre-regulator is pushed in 100% duty-cycle mode and Rprog allows remote (external) voltage programming.
SYSTem:CPU
SYSTem:CPU:INFOrmation:TYPE? Returns the type of CPU and SYSTem:CPU:MODel? returns the control board model identification:
SYST:CPU:MOD?
"Arduino, R2B6"
SYST:CPU:INFO:TYPE?
"Due"
SYSTem:CPU:INFOrmation:ETHernet:TYPE? returns the type of Ethernet controller:
SYST:CPU:INFO:ETH:TYPE?
"W5500"
SYSTem:CPU:OPTion? returns information about installed options on the Arduino shield. Currently on the R2B6 we have the following situation:
SYST:CPU:OPT?
"BPost, EEPROM, RTC, Display"
An important feature is added in M2 firmware that allows us to support various types of power boards and control boards (Arduino shields). That was required since we have now two designs that we are planning to support in the future. This functionality will enables us and 3rd party to add support for new revisions.
The power board variant is defined in conf.h. A mix and match of various variants is allowed. For example default configuration defines two rev.4 boards:
Code:
/// Channels configuration.
///
#define CHANNELS \
CHANNEL(1, CH_BOARD_REVISION_R4B43A_PARAMS, CH_PINS_1, CH_PARAMS_40V_5A), \
CHANNEL(2, CH_BOARD_REVISION_R4B43A_PARAMS, CH_PINS_2, CH_PARAMS_40V_5A) \If I'd like to mix rev.4 board with 0-50 V/3 A (Ch#1) capability with newest one with 0-40 V / 5 A (Ch#2) capability I need to use the following declarations:
Code:
#define CHANNELS \
CHANNEL(1, CH_BOARD_REVISION_R4B43A_PARAMS, CH_PINS_1, CH_PARAMS_50V_3A), \
CHANNEL(2, CH_BOARD_REVISION_R5B6B_PARAMS, CH_PINS_2, CH_PARAMS_40V_5A) \The Arduino shield is defined in conf_user_revision.h:
Code:
/// Selected EEZ PSU revision, possible values are:
/// EEZ_PSU_REVISION_R1B9 or EEZ_PSU_REVISION_R2B6
#define EEZ_PSU_SELECTED_REVISION EEZ_PSU_REVISION_R2B6Additionally a new set of SCPI commands are added that helps identifying what is declared in firmware.
SYSTem:CHANnel
SYSTem:CHANnel[:COUNt]? returns the number of output channels.
SYSTem:CHANnel:MODel? returns the channel model identification, for example:
SYST:CHAN:MOD?
"Power_r5B6b"
For output voltage, current and power capability you can use SYSTem:CHANnel:INFOrmation:VOLTage?, SYSTem:CHANnel:INFOrmation:CURRent? and SYSTem:CHANnel:INFOrmation
OWer? (please note that max. power is not necessary simply multiplication of max. voltage and current).Interesting info could be queried with SYSTem:CHANnel:INFOrmation
ROGram? that returns a list of all programmable features of the channel. For example for R5B6B it will returns:SYST:CHAN:INFO
ROG?"Volt, Current, Power, OE, DProg, LRipple, Rprog"
where DProg denotes Downprogrammer, LRipple a "low ripple" mode of operation when SMPS pre-regulator is pushed in 100% duty-cycle mode and Rprog allows remote (external) voltage programming.
SYSTem:CPU
SYSTem:CPU:INFOrmation:TYPE? Returns the type of CPU and SYSTem:CPU:MODel? returns the control board model identification:
SYST:CPU:MOD?
"Arduino, R2B6"
SYST:CPU:INFO:TYPE?
"Due"
SYSTem:CPU:INFOrmation:ETHernet:TYPE? returns the type of Ethernet controller:
SYST:CPU:INFO:ETH:TYPE?
"W5500"
SYSTem:CPU:OPTion? returns information about installed options on the Arduino shield. Currently on the R2B6 we have the following situation:
SYST:CPU:OPT?
"BPost, EEPROM, RTC, Display"
"Low ripple" mode of operation
The [SOURce[<n>]]:LRIPple command can be used to enable (ON, 1) or disable (OFF, 0) this mode of operation. Command also has query form that allows us to find out the current status of the selected channel. For example, if mode is off:
LRIP?
0
or if we want to specify the first channel:
SOUR1:LRIP?
0
Another command is [SOURce[<n>]]:LRIPple:AUTO that maximize this functionality by pushing channel to stay in low ripple mode as much as possible. That means that once AUTOmatic selection is enabled channel will switch back and forth from low to "high" ripple mode of operation depending of programmed output parameters and connected load. When AUTOmatic mode is activated you can use [SOURce[<n>]]:LRIPple? to obtain current status:
LRIP:AUTO ON
LRIP?
1
Entering low ripple mode of operation require monitoring of the max. output power. The maximum output power is limited by the first of the following conditions that is met:
If output voltage is set to 36 V with the same SOA values as in example above the max. output current cannot exceed 0.8 A (limited by SOA_PREG_CURR) regardless of the fact that max. power dissipation of 20 W allows output current of up to 1.428 A or 20/(50-36).
Please let me know if we missed or miscalculated here something.
Any attempt to set low ripple mode (LRIP ON) will generate an error. The AUTOmatic mode should be used to avoid error conditions. Also if AUTOmatic mode disables low ripple, an attempt to enable it, will also generate an execution error (-200).
Of course, this functionality as all other can be tested using firmware simulator with the latest firmware build. Quick video about how to use simulator is here:
https://www.youtube.com/watch?v=hhGT8GlrUEk
The [SOURce[<n>]]:LRIPple command can be used to enable (ON, 1) or disable (OFF, 0) this mode of operation. Command also has query form that allows us to find out the current status of the selected channel. For example, if mode is off:
LRIP?
0
or if we want to specify the first channel:
SOUR1:LRIP?
0
Another command is [SOURce[<n>]]:LRIPple:AUTO that maximize this functionality by pushing channel to stay in low ripple mode as much as possible. That means that once AUTOmatic selection is enabled channel will switch back and forth from low to "high" ripple mode of operation depending of programmed output parameters and connected load. When AUTOmatic mode is activated you can use [SOURce[<n>]]:LRIPple? to obtain current status:
LRIP:AUTO ON
LRIP?
1
Entering low ripple mode of operation require monitoring of the max. output power. The maximum output power is limited by the first of the following conditions that is met:
[li]The pre-regulator regulation element (switching mosfet) capability is limited with max. allowed continuous current (SOA_PREG_CURR value) for the applied input voltage (SOA_VIN value). The set output current cannot exceeds this value in any moment.[/li]
[li]The post-regulator regulation element (pass mosfet) could dissipate finite power (SOA_POSTREG_PTOT value) while load is connected. Therefore output power cannot exceed product of voltage difference (SOA_VIN and output voltage) and output current.[/li]
If output voltage is set to 36 V with the same SOA values as in example above the max. output current cannot exceed 0.8 A (limited by SOA_PREG_CURR) regardless of the fact that max. power dissipation of 20 W allows output current of up to 1.428 A or 20/(50-36).
Please let me know if we missed or miscalculated here something.
Any attempt to set low ripple mode (LRIP ON) will generate an error. The AUTOmatic mode should be used to avoid error conditions. Also if AUTOmatic mode disables low ripple, an attempt to enable it, will also generate an execution error (-200).
Of course, this functionality as all other can be tested using firmware simulator with the latest firmware build. Quick video about how to use simulator is here:
https://www.youtube.com/watch?v=hhGT8GlrUEk
Output voltage remote programming
Remote programming of output voltage is also now implemented in the firmware as new SCPI command: [SOURce[<n>]]:VOLTageROGram[:SOURce] that accept INTernal or EXTernal parameter if output voltage has to be programmed "localy" (by MCU) or "remotely" applying analog signal (2.5 V for full scale). The same command has query form that returns 0 (internal/local) or 1 (external/remote). For example:
VOLTROG EXT
VOLTROG?
1
An additional indication that channel entered remote programming mode is red LED above "push-in" connector on the front panel (Arduino shield PCB).
When output voltage programming source is set to EXTernal OVP is also enabled. Before we implemented selection of output voltage programming source, enabling OVP means that OVP will trip automatically if PSU enters CV mode. There was no possibility to set "trip" threshold. While remote programming is selected MCU cannot set the output voltage so we added a new [SOURce[<n>]]:VOLTageROTection[:LEVel] command that define when OVP will trip. By default it's set to max. value (e.g. 40 V in case of 0-40 V model), but you can decrease it to desired value. The following command sequence check OVP status, OVP level and change level to 12 V:
VOLTROT:STAT?
1
VOLTROT?
40
VOLTROT 12
When OVP tripped channel will be automatically change output voltage programming mode back to INTernal (as a precaution). That we can check if the following sequence:
VOLTROT:TRIP?
1
VOLTROG?
0
While channel is in remote programming mode, the actual voltage could be acquired as in the local mode. For example if 1.25 V is applied on remote programming input the MEASure[:VOLTage]? will returns 20 V for 0-40 V model (half scale):
MEAS?
20.00
Remote programming of output voltage is also now implemented in the firmware as new SCPI command: [SOURce[<n>]]:VOLTage
ROGram[:SOURce] that accept INTernal or EXTernal parameter if output voltage has to be programmed "localy" (by MCU) or "remotely" applying analog signal (2.5 V for full scale). The same command has query form that returns 0 (internal/local) or 1 (external/remote). For example:VOLT
ROG EXTVOLT
ROG?1
An additional indication that channel entered remote programming mode is red LED above "push-in" connector on the front panel (Arduino shield PCB).
When output voltage programming source is set to EXTernal OVP is also enabled. Before we implemented selection of output voltage programming source, enabling OVP means that OVP will trip automatically if PSU enters CV mode. There was no possibility to set "trip" threshold. While remote programming is selected MCU cannot set the output voltage so we added a new [SOURce[<n>]]:VOLTage
ROTection[:LEVel] command that define when OVP will trip. By default it's set to max. value (e.g. 40 V in case of 0-40 V model), but you can decrease it to desired value. The following command sequence check OVP status, OVP level and change level to 12 V:VOLT
ROT:STAT?1
VOLT
ROT? 40
VOLT
ROT 12When OVP tripped channel will be automatically change output voltage programming mode back to INTernal (as a precaution). That we can check if the following sequence:
VOLT
ROT:TRIP?1
VOLT
ROG?0
While channel is in remote programming mode, the actual voltage could be acquired as in the local mode. For example if 1.25 V is applied on remote programming input the MEASure[:VOLTage]? will returns 20 V for 0-40 V model (half scale):
MEAS?
20.00
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.