Algorithm - Embedded State Machine

Design for PSoC with Interfacing to a

Windows Application (Part III of III)

AN2333
Authors: Somsak Sukittanon, Ph.D., Stephen G. Dame, MSEE
Associated Project: Yes
Associated Part Family: CY8C21xxx, CY8C24xxxA, CY8C24794, CY8C27xxx, CY8C29xxx
GET FREE SAMPLES HERE
Software Version: PSoC® Designer™ 4.2
Associated Application Notes: AN2329, AN2332

Application Note Abstract

From our previous Application Notes, a small state machine kernel was discussed (part I AN2329) and a graphical code
generator was provided to implement traditional state machine behavior from high-level system architecture (part II AN2332).
In this Application Note, we discuss a more sophisticated state machine design that involves interrupt and polling events. A
new method can simply be viewed as the cascaded state machine. Finally, we show how to build two-way serial
communication between PSoC and a Microsoft Windows® Application. The demonstration is built using Microsoft Visual
Basic® 6.0.

Introduction State Machine

In the first and second parts of this three-part Application
Note series, the concept of an embedded state machine
design and a graphical code generator were given. This
third note concludes the implementation of state machines
for PSoC. It extends the functionality of the ADC
conversion and LCD display example using a combination
of two different state tables, i.e., interrupt and polling
tables. The new method is more complex but also very
efficient in terms of occupied table space when state
tables are redundant.
We then discuss how to build a Visual Basic Windows-
based program that interfaces with PSoC via serial
communications. Microsoft Visual Basic is widely known
as one of the simplest and efficient programming tools for
Windows programming beginners. We show how to set
transmit and receive settings on both PSoC and PC.
Within a short period of time, developers can extend this
demonstration project to very advanced and powerful
applications.
State Machine for Interrupt and Polling
In our previous Application Notes (parts I and II),
implementation of a state machine was discussed.
Basically, it is based on polling and table lookup methods.
Designing events are listed in each state table. In some
cases, the same event can occur in many states. For
example, EVENT_ADCDATA_READY checks if the new
ADC sample is ready. This must be polled regularly
independent of current state. Other typical event examples
requiring regular polling include 1) timer ended, 2) power
key pressed, 3) serial communication sent/received.
These events must be listed in all state tables. To reduce
the size of state tables, we can create two different state
machine tables that handle events based on each mode,
i.e., interrupt mode and polling mode.
As illustrated in Figure 1, for events based on interrupt
mode, we create the state table called
STATE_INTERRUPT. As shown in Figure 2, the event,
action, and exit functions are listed in the same manner
like other polling state tables. For events based on polling
mode, we now remove EVENT_ADCDATA_READY out of
five states, reducing occupied space from 25 bytes to
5 bytes.

January 5, 2006 Document No. 001-26159 Rev. ** 1

[+] Feedback
 AN2333

The core of a state machine function needs to be state table. Referring to the code from Figure 3, if the next
changed. First, the state machine checks the state is listed as STATE_INTERRUPT, the program
STATE_INTERRUPT table. If there is no event occurring, ignores updating the next state. Therefore, the next state
then it checks the current state. in STATE_INTERRUPT can be listed to anything based
on the application. An event such as ADCDATE_READY
If there is one event in STATE_INTERRUPT, the state may not require changing the next state, but an event
machine executes the action and exit functions and leaves such as TIMER_END may require changing to a new
the state machine routine without checking any current state.

Figure 1. State Machine Design for ADC Conversion and LCD Display Project (PSoCEval1 Example Project #1)
Using a New Approach
EVENT_ADCDATA_READY
ACTION_NOP STATE_INTERRUPT
SF_NOP
EVENT _UART_RECEIVE
ACTION_TOGGLELCDTEXT
SF_PRINTLCD_AND_SENDUART

STATE_IDLE

EVENT_ JUMPTOSTATE_0 EVENT_ JUMPTOSTATE_1 EVENT_ JUMPTOSTATE_2 EVENT_ JUMPTOSTATE_3

ACTION_PREPARESTATELCD ACTION_PREPARESTATELCD ACTION_PREPARESTATELCD ACTION_PREPARESTATELCD
SF_PRINTLCD_AND_SENDUART SF_PRINTLCD_AND_SENDUART SF_PRINTLCD_AND_SENDUART SF_PRINTLCD_AND_SENDUART

EVENT_JUMPTO_PREVIOUSSTATE EVENT_JUMPTO_PREVIOUSSTATE EVENT_JUMPTO_PREVIOUSSTATE

ACTION_PREPARESTATELCD ACTION_PREPARESTATELCD ACTION_PREPARESTATELCD
STATE_NUMBER_0 SF_PRINTLCD_AND_SENDUART STATE_NUMBER_1 SF_PRINTLCD_AND_SENDUART STATE_NUMBER_2 SF_PRINTLCD_AND_SENDUART STATE_NUMBER_3

EVENT_JUMPTO_NEXTSTATE EVENT_JUMPTO_NEXTSTATE EVENT_JUMPTO_NEXTSTATE

ACTION_PREPARESTATELCD ACTION_PREPARESTATELCD ACTION_PREPARESTATELCD
SF_PRINTLCD_AND_SENDUART SF_PRINTLCD_AND_SENDUART SF_PRINTLCD_AND_SENDUART

EVENT_STAY_SAMESTATE EVENT_STAY_SAMESTATE EVENT_STAY_SAMESTATE EVENT_STAY_SAMESTATE

ACTION_NOP ACTION_NOP ACTION_NOP ACTION_NOP
SF_ PRINTLCD_AND_SENDUART SF_ PRINTLCD_AND_SENDUART SF_ PRINTLCD_AND_SENDUART SF_ PRINTLCD_AND_SENDUART

Figure 2. State Machine Table for STATE_INTERRUPT

EVENT_NODE_T ENL_INTERRUPT[] = {
{ EVENT_ADCDATA_READY, STATE_INTERRUPT, ACTION_NOP, (pVectorFunc)
SF_NOP},
{ EVENT_UART_RECEIVE, STATE_INTERRUPT, ACTION_TOGGLELCDTEXT, (pVectorFunc)
SF_PRINTLCD_AND_SENDUART},
};

January 5, 2006 Document No. 001-26159 Rev. ** 2

[+] Feedback
 AN2333

Figure 3. State Machine for Interrupt and Polling Modes

void StateMachine(void)
{
//Interrupt checking
if (!StateMachine_Core(STATE_INTERRUPT))
// Polling checking
StateMachine_Core(eCurrentState);
}

BYTE StateMachine_Core(STATE_T statenumber)

{
BYTE bEvents;
EVENT_NODE_T *pENL, *pen;
for(bEvents = 0; bEvents < StateTransitionMatrix[statenumber].bNumEvents;
bEvents++) //1. check events
{
pENL = StateTransitionMatrix[statenumber].pEventList;
pen = &pENL[bEvents];
if(event_Check(pen->Event)) // 2. check which event happens
{
if ((pen->NextState) != STATE_INTERRUPT) // 3. interrupt state ->
ignore the next state eCurrentState = pen->NextState;
Action(pen->Action); //4. action
pen->SpecFunc(); //5. exit function
return(1);
}
}
return(0);
}

PSoC:
Interfacing PSoC to Windows Applications 1. Same functionality as discussed in Application Note
In Application Note part II, we discussed the ADC and part II.
LCD display example using the CY3210-PSoCEval1
board. After we run the project and hook the serial port to 2. Additionally, the UART User Module is able to receive
the PC, the data can be displayed using a simple program and extract messages sent from the PC.
like Tera Term Pro. In this note, we give an example of Windows Application:
how to create a more sophisticated program with PSoC
and a Windows Application. The communication, both 1. Retrieve data sent from PSoC and show that number
transmit and receive mode, between PSoC and the PC is on the display. In the mean time, plot the graph of the
done via serial communication. Microsoft Visual Basic is current number in real-time.
used for building the application. The reader can easily
2. Send data from PC back to PSoC. New message text
extend our example to different applications.
will show on LCD line 1.
Following are the primary responsibilities.

January 5, 2006 Document No. 001-26159 Rev. ** 3

[+] Feedback
 AN2333

Modifying the PSoC Project No changes are required for transmitting UART data. For
receiving data, the EVENT_UART_RECEIVE function
There are parameters that need to be set for the PSoC
periodically checks if the buffer has received anything. If
UART User Module. First, the RxCmdBuffer is enabled.
the PSoC receives message data,
The size of the UART buffer is chosen based on the
ACTION_TOGGLELCDTEXT extracts the ASCII
application, and in our case, it is chosen to be 16.
characters and puts them into LCD buffers. Afterward, the
CommandTerminator is set to ASCII char #13, which is
receive command buffer is reset for the next command.
CR. Space, char #32, is used to separate each command
After compiling the project and downloading it into the
and the UART does not accept NUL, char #0.
evaluation board, we can see that it runs exactly the same
as the project from the previous note (part II AN2332)
because the PSoC has not yet received any data from the
PC.

Figure 4. UART User Module Parameters

Figure 5. Sample Code Snippet of EVENT_UART_RECEIVE and ACTION_TOGGLELCDTEXT

case EVENT_UART_RECEIVE:
if (UART_1_bCmdCheck())
return(1);
break;

case ACTION_TOGGLELCDTEXT:
if(inputstrPtr = UART_1_szGetParam())
{
for (index=0;index<14;index++)
LCDStateText[index] = ' ';
bLength = strlen(inputstrPtr); //length of the data
if (bLength > 14)
bLength = 14;
for (index=0;index<bLength;index++)
LCDStateText[index] = inputstrPtr[index];
}
UART_1_CmdReset();
break;

January 5, 2006 Document No. 001-26159 Rev. ** 4

[+] Feedback
 AN2333

Figure 7a shows a running program after connecting to the

Building a Windows Application
Microsoft Visual Basic is used and readers are assumed
to be familiar with VB programming. Readers will find the
example project along with this note. Double-click
PSoCVBprogram.vbp to open the project.
As shown in Figure 6a, the most important thing is to add
MSComm (a little telephone icon), which is used for UART
communication on the PC. In Figure 6b, the baud rate is
set to be identical to the PSoC UART setup, 19200 bps.
The input and output buffer sizes depend on each
application.
PSoC. After opening the correct serial port, the hex
number is extracted from the message sent by the PSoC.
This number is changed to decimal and printed as a
yellow font on the box. At the same time, it is printed out
as the red line in realtime on the graph. The message
inside the input box will be sent to the PSoC when the
user presses the button. This message is concatenated
with CR (message ending). Figure 7b and 7c show the
LCD on the PSoC before and after the PC sends the
message.

Figure 6. (a) Microsoft Visual Basic Project and (b) UART Setup

(a) (b)

Figure 7. (a) A Running Windows Application Connecting to PSoC; (b) PSoC Before Getting New Message;

(b)

(a) (c)

January 5, 2006 Document No. 001-26159 Rev. ** 5

[+] Feedback
 AN2333

We also discussed how to interface PSoC to PC

applications built on Microsoft Visual Basic. The example
Summary shows how to graphically print and plot data to the display.
We conclude this three-part series discussion of The user can send messages, such as commands or a
embedded state machine design for PSoC. In this note, text string, back to the PSoC. This example can help
we started with the new approach of combining interrupt PSoC developers build more sophisticated applications.
events and polling events for state machine design.
Basically, it can be viewed as the combination of two state
machines. The advantage of the new approach is that we
can significantly reduce the size of state tables when
compared to exclusively using the polling method.

January 5, 2006 Document No. 001-26159 Rev. ** 6

[+] Feedback
 AN2333

About the Authors

Name: Somsak Sukittanon
Title: Principal R&D Engineer
Background: Dr. Sukittanon is a principal R&D
engineer at Virtual DSP Corporation. He
has led several investigations in the
areas of software development of signal
processing and embedded systems. He
is also a part-time lecturer at the
University of Washington. He has taught
many classes, e.g., circuit analysis, DSP
embedded design. He is the recipient of
the 2005 outstanding teaching award for
Electrical Engineering Department at the
University of Washington.
Contact: somsak@virtual-dsp.com
Name: Stephen G. Dame
Title: President and CEO
Background: Mr. Dame is president and founder of
Virtual DSP Corporation, which is a
research and development and
manufacturing company in the area of
digital signal processing, wireless and
internet computing devices. He holds a
masters degree in electrical engineering
and is a successful entrepreneur with
more than 25 years of experience in
developing products in the medical,
aerospace and consumer electronic
markets. He is a recipient of 1994
Technical Fellow award for his work in
Doppler Ultrasound at Advanced
Technology Labs (ATL).
Contact: steve@virtual-dsp.com

In March of 2007, Cypress recataloged all of its Application Notes using a new documentation number and revision code. This new
documentation number and revision code (001-xxxxx, beginning with rev. **), located in the footer of the document, will be used in all
subsequent revisions.
PSoC is a registered trademark of Cypress Semiconductor Corp. "Programmable System-on-Chip," PSoC Designer, and PSoC Express are
trademarks of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are the property of their
respective owners.

Cypress Semiconductor
198 Champion Court
San Jose, CA 95134-1709
Phone: 408-943-2600
Fax: 408-943-4730
http://www.cypress.com/

© Cypress Semiconductor Corporation, 2006-2007. The information contained herein is subject to change without notice. Cypress Semiconductor
Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any
license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or
safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as
critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The
inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies
Cypress against all charges.
This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide
patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a
personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative
works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress
integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source
Code except as specified above is prohibited without the express written permission of Cypress.
Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the
right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or
use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a
malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems
application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges.
Use may be limited by and subject to the applicable Cypress software license agreement.

January 5, 2006 Document No. 001-26159 Rev. ** 7

[+] Feedback