Hello Everyone! I'm currently working on an intelligent and flexible power supply controller using a PSoC5 with VoltageSequencer and PowerMonitor components. The power board is designed to highly configurable to provide multiple, high-current voltage rails. Each rail is programmable and the power sequence could change from one application to another. Instead of having a different build for each configuration that may be needed (nearly impossible with 10 different rails that are programmable to output any voltage between about 0.6V and 3.3V), I am attempting to read an EEPROM on the main board then re-program the Power Monitor and Voltage Sequencer at run time based on the data pre-programmed into the EEPROM. I define run time as the time when the PSoC powers up and starts executing code.

I believe I'll be able to reprogram the Power Monitor by modifying the Warn and Fault struct's as they are visible to my code in main.c; the VoltageSequencer is posing a bit of a coding challenge for me though. Many of the settings in the Voltage Sequencer are constants and hard coded in the sequencer.c file.

Has anyone had experience or have any insight into how I can work around the hard coded constants?

Usually constants set at design-time propagate into verilog or c-APIs and there is no chance to change their value at run-time.If there is a real need for that as you state here, I would suggest you to get in contact with cypress directly and show them where to improve their components.There are several ways to do that:File a technical case at the cypress-home-page (unser Support->Technical Support...)Look for the author of Appnotes who usually is deeply involed in the component and contact him / her by email directly.

Thanks for the feedback. I will pursue this directly with Cypress, but was hoping that someone out there might have already gone through this before and would be willing to give me some pointers based on personal experience.

I realize that changing constants at run-time is not an option else they wouldn't be very constant would they Hence the question regarding a work around; but, perhaps my question could have been better stated as, "Has anyone had experience with or have any insight into how I can reprogram the Voltage Sequencer at run-time?"

Well, there is always the chance to create a new component out of the old one, replacing the APIs with new ones etc. Not to be done swiftly and easy, but it can be done.Have some looks into the "Components Author Guide"

One of my pet peeves when it comes to message boards like this one is that many people don't provide closure to questions that they post. This is a reflection on me and not aimed at any one person or group of people here on the PSoC Developer Forum

So to provide closure, here's what (in a nutshell) I ended up doing:

After placing the voltage sequencer (VSeq) component;1.) Configure the VSeq with a base configuration2.) Build the project3.) Copy C:\design_name\design_name.cydsn\Generated_Source\PSoC5\VSeq.c, VSeq.h, VSeq_PVT.h and VSeq_INT.c to my C:\design_name directory4.) Open the Configure 'VoltageSequencer' dialog, select "Built-in" tab and change CY_SUPPRESS_API_GEN to true. Causes Creator to remove the files it had previously generated which is why the originals have to be copied to the working directory.5.) In the Workspace Explorer, add the local copies of VSeq*.* to the project.6.) Modify VSeq.c to change the CONST's to variables so I can change them via the code.7.) Wrote functions to allow me to change the operating parameters for the Voltage Sequencer and Power Monitor components. These functions carefully examine the settings and and do a whole lot of error checking before I allow the Voltage Sequencer and Power Monitor to resume operation.8.) Build the project.

The main drawback to this approach is that the Voltage Sequencer component can not be easily updated if Cypress publishes an update for it. This process should allow you to modify any API you like but keep in mind that if you do something wrong and destroy your PSoC device, Cypress is not liable for your mistakes.

Thank you, Keith, for keeping us informed.Another choice (which I did with some other component) is to copy and rename all the sources to get a component running with a different name but the same functionality.In a second step I applied the wanted changes to that newly generated component.Of course this lacks the update-problem as well, but it will save the original.