Here is a video that I created for Getting started with PSoC Designer 5.3. View it in 720p or 1080p for higher quality.

Here is a video I made on introduction to PSoC 1 architecture and design flow.

Back to the blog world after a long period of inactivity. In the past few months, I have had a chance to work on a very interesting project for our CEO T.J. Rodgers.  He is donating 152 wine fermenters to the U.C Davis School of Enology and Viticulture.   A couple of articles that talk about the project: Blending Science With Wine, UC Davis claims world’s greenest winery

An important part of the fermenter is a temperature controller that controls the temperature of the fermenting grape juice – also known as “Must” – during the fermentation process.  The stainless steel drum that holds the ”must” is surrounded by a jacket through which cold or warm water is passed.  A PSoC is used to sense the temperature of the “must” using a thermistor, and based on the desired set point, controls the flow of cold or warm water through the jacket to maintain the temperature of the “must”.  The PSoC controls the water flow by operating a solenoid valve connected to the outlet port of the jacket. 

In this blog post, I am going to discuss the valve control section of the temperature controller.  This can be used in many other interesting applications like automatic garden irrigation, bathtub overflow control etc.

The primary design challenge was that the temperature controller was battery operated.  Because of this, a continuously on solenoid valve cannot be used.  The solution was a latching solenoid valve from Orbit.

This valve is used in commercial water sprinklers.  The valve has an inlet port and an outlet port for water.  A plunger opens or closes the valve.  This plunger is operated by two magnetic coils.  Energizing one of the coils with a 15V/20mS pulse opens the valve.  Once on, the valve latches and stays on without any further need for power.  Energizing the other coil with the same pulse closes the valve and the valve latches and stays closed.  The schematic of the valve control is shown below.
 

LT1303 is a charge pump, which is used to step up the 3.5V - 4.5V battery voltage to 15V and charge C6, a 2200uF capacitor.  J3 is a socket for the Orbit valve.  The common is connected to the +ve of the 2200uF capacitor.  The other two pins are connected to the drain of T1 and T2, N Channel MOSFETs.  Applying a pulse to the gate of these transistors will discharge the charge in capacitor through the corresponding coil.  Let us have the look at how the PSoC controls this circuit.

The PSoC controls the charge pump through the CH_PMP_SHDN and VB_FB signals.  CH_PMP_SHDN is a GPIO pin configured as StdCPU/Strong and turns on or off the charge pump.  VB_FB is the feedback signal used to sense the voltage on the 2200uF capacitor.  Figure below shows the PSoC Designer resource placement for the valve control.

 
A comparator is used to compare VB_FB with a fixed threshold generated by a DAC6.  The voltage on the 2200uF capacitor is derived by the formula.

Vout = Vref/10K * 160K

where
Vout = Voltage on the 2200uF
Vref = Comparator reference voltage

When the voltage across the 2200uF cross the desired output, the comparator goes high, and the PSoC turns off the charge pump and generates a 20mS pulse on gate of the respective MOSFET to turn On or Off the Orbit valve.

Following code is used to turn on the valve. 

    // Enable the Charge Pump
    CH_PMP_ENABLE;
   
    /* Set Analog reference power to SC On / Ref Med */
    ARF_CR |= 0x06;
   
    /* Start the CMP and DAC modules */
    CMP_Start(CMP_MEDPOWER);
    DAC_Start(DAC_MEDPOWER);
    DAC_WriteBlind(26);
   
    /* A small delay for the DAC and comparator to stabilize */
    DelayMs(5);
   
    /*     Wait for the comparator output to go high
        When comparator output becomes high, it means Vboost is around 18V */
    while(!(CMP_CR0 & 0x80));
   
    // Disable the Charge Pump
    CH_PMP_DISABLE;
   
    // Set the VALVE_ON GPIO
    VALVE_ON_Data_ADDR |= VALVE_ON_MASK;
   
    /* Switch off the CMP and DAC */
    CMP_Stop();
    DAC_Stop();
   
    /* Set analog reference power to all off */
    ARF_CR &= ~0x07;

    // 20mS Delay
    DelayMs(20);
   
    // Clear the VALVE_ON GPIO
    VALVE_ON_Data_ADDR &= ~VALVE_ON_MASK;

Enable the charge pump, switch on the comparator and DAC, wait for the comparator output to go high, disable the charge pump, turn off comparator and DAC and switch on the VALVE_ON GPIO for 20mS.  This will turn on T1 and discharge C6 through the On coil thus turning on the valve.  Similar code is used for turning off the valve where T2 is switched On.

Stay tuned for more interesting topics on the Fermenter!

The E2PROM user module is a very handy user module for emulating an E2PROM in the Flash program memory.  Here are some key points to remember while using the E2PROM user module. 

My apologies for the very long article.  Wanted to keep it short, but as I kept adding information this grew into a 1000+ word blo(n)g. 

User Module Parameters:

Starting Block: This specifies the flash block number where the E2PROM begins.  Always place the E2PROM in the last blocks of the flash.  For example, in a 32K device, a 256 byte (4 blocks) E2PROM should be placed in blocks 508 to 511.  So, the first block should be 508.  This ensures that maximum space is available for the code memory and prevents clash between code memory and E2PROM.

Remember to modify the flashsecurity.txt file and set the protection level of the flash blocks to “U” or “R”

w  w  w  w  w   w   w   w   w   w   w   w   w   w   w   w ;    Base Address 7800
w  w  w  w  w   w   w   w   w   w   w   w   u   u   u   u ;    Base Address 7C00
; End 32K parts

Length: This parameter sets the size of the E2PROM in bytes.  For the above example, the length parameter would be 256.

E2PROM Write Function:

To write data to the E2PROM, use the E2PROM_bE2Write function.  The prototype of the function is

char E2PROM_bE2Write(WORD wAddr, BYTE *pbData, WORD wByteCount, char Temperature);

wAddr: This is the location in the E2PROM where you would like to write the data.  A very common mistake made is people enter the physical address of the flash location.  The value should be relative location in the E2PROM, not in flash.  For the example mentioned above, to write data to the first location in the E2PROM, the value of wAddr should be 0x0000, not 0x7F00.

*pbData: This is the pointer to the buffer that holds the data you want to write to the E2PROM.  If the data is not in a char buffer, then you use typecasting.  For example, if to write a structure MyStruct, typecast the pointer to (char*)&MyStruct.

wByteCount: This is the number of bytes to be written to the E2PROM.  More about it later.

Temperature: The Temperature parameter is used by the E2PROM API to calculate the flash write pulse width.  At higher temperatures the flash has to be written with a smaller pulse width and at lower temperatures with a longer pulse width.  The flash will meet its maximum endurance and write cycles if it is written with the correct pulse width.  If the device is going to operate within a temperature range of 0 to 50 degrees, it is ok to pass the value of 25 for temperature.  But for operation over the full temperature range, use FlashTemp user module and pass the correct die temperature.  If this is not done, either the data retention or the flash endurance will be compromised.  If the temperature value passed is less than the operating temperature, the flash will be written with a longer pulse width than required.  This will reduce the flash endurance.  On the other hand, if the temperature value passed is higher than the operating temperature, the flash will be written with a lower pulse width than required.  While this does not affect the endurance, the data retention will be less than the guaranteed 10 years. 

The bE2Write function returns the status of the write operation.  A return value of 0x00 means the write was successful.  -1 means error in writing which could be because the flash is write protected. -2 means stack overflow.  Always check the return value in your program to make sure that the write was successful.

Full Block Write vs. Partial Write

E2PROM writes always take place in 64 byte blocks.  When you write less than 64 bytes of data, it is called a partial write.  The flash write API first reads all the 64 bytes from the flash block into RAM, modifies the desired bytes and writes back the 64 bytes of data to Flash.  This results in a heavy RAM overhead requiring 103 bytes of stack space, whereas a full block write takes only 32 bytes of stack.  In devices with only one RAM page, the global variables and stack share the 256 bytes.  If the RAM usage of the globals is high, this could lead to stack overflow errors while performing partial writes.  Under such condition, it is always advisable to perform a 64 byte write.  Even if you are writing say 10 bytes of data, set the ByteCount to 64.  The first 10 bytes will be the actual data followed by data from subsequent RAM locations.  Check out the E2PROM user module data sheet under the section “Efficient Memory Usage” for more details.

Initializing the E2PROM with data:

Many a times you may be using the E2PROM to store calibration data or any other system related data, where you would like to load the E2PROM with some initial values while the device is programmed.  Following method may be used to achieve this.

In C: Use the “#pragma abs_address” directive.  For example, if the E2PROM is placed in the last flash block in a 32K device, and if you wanted to initialize the first 10 bytes with some value:

In assembly:

Let us take a look at a practical E2PROM usage where a calibration structure is stored, read and written in the E2PROM.

Create a typedef for the structure 

RAM variable to store the calibration values 

Initialize the E2PROM with initial values: 

Now to read the value from the E2PROM to the RAM you can use either the E2PROM_Read function:

Or:

To write the values from the RAM to E2PROM

E2PROM_bE2Write(0x0000,(char*)&CalValuesRam, 64, 25);