1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
/****************************************************************************
**
** Copyright (C) 2011 - 2012 Denis Shienkov <denis.shienkov@gmail.com>
** Contact: http://www.qt-project.org/legal
**
** This file is part of the documentation of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:FDL$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and Digia. For licensing terms and
** conditions see http://qt.digia.com/licensing. For further information
** use the contact form at http://qt.digia.com/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: http://www.gnu.org/copyleft/fdl.html.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\example blockingmaster
\title Blocking Master Example
\ingroup qtserialport-examples
\brief Explains how to create an app using QSerialPort's synchronous API.
The blocking master example shows how to create an application for a
serial interface using QSerialPort's synchronous API in a worker thread.
\image blockingmaster-example.png Screenshot of the blocking master example
QSerialPort supports two general programming approaches:
\list
\li \e{The asynchronous (non-blocking) approach.} Operations are scheduled
and performed when the control returns to Qt's event loop. QSerialPort emits
a signal when the operation is finished. For example, QSerialPort::write()
returns immediately. When the data is sent to the serial port, QSerialPort
emits \l{QIODevice::bytesWritten()}{bytesWritten()}.
\li \e{The synchronous (blocking) approach.} In headless and multithreaded
applications, the wait functions can be called (in this case,
QSerialPort::waitForReadyRead()) to suspend the calling thread until the
operation has completed.
\endlist
In this example, the synchronous approach is demonstrated. The \l{terminal}{Terminal}
example illustrates the asynchronous approach.
The purpose of this example is to demonstrate a pattern that you can use
to simplify your serial programming code, without losing responsiveness
in your user interface. Use of Qt's blocking serial programming API often
leads to simpler code, but because of its blocking behavior, it should only
be used in non-GUI threads to prevent the user interface from freezing.
But contrary to what many think, using threads with QThread does not
necessarily add unmanagable complexity to your application.
This application is the master which demonstrates the work paired with the slave
application \l{blockingslave}{Blocking Slave Example}.
The master application initiates the transfer request via the serial port to
the slave application and waits for response.
We will start with the MasterThread class, which handles the serial
programming code.
\snippet blockingmaster/masterthread.h 0
MasterThread is a QThread subclass that provides an API for scheduling
requests to the slave, and it has signals for delivering responses and reporting
errors. The transaction() method can be called to startup the new master
transaction with the desired request data and other parameters. The result
is delivered by the response() signal. If any error occurs, the error() or
timeout() signal is emitted.
It's important to notice that the transaction() method is called from the main,
GUI thread, but the request data and other parameters will be accessed from
MasterThread's thread. Since the MasterThread data members will be read and
written concurrently from different threads, QMutex is used to synchronize
the access.
\snippet blockingmaster/masterthread.cpp 2
The transaction() function stores the serial port name, timeout and request
data. The mutex can be locked with QMutexLocker to protect this data. Then,
the thread can be started, unless it is already running. QWaitCondition::wakeOne()
will be discussed later.
\snippet blockingmaster/masterthread.cpp 4
\snippet blockingmaster/masterthread.cpp 5
In the run() function, start by acquiring the mutex lock, fetch the
serial port name, timeout and request data from the member data, and then
release the lock again.
Under no circumstance should the method \c transaction() be called simultaneously
with a process fetching these data. QString is reentrant but not thread-safe, and
it is not recommended to read the serial port name from one request,
and timeout or request data from another. The MasterThread can only handle
one request at a time.
The QSerialPort object we construct on stack into run() function before loop
enter:
\snippet blockingmaster/masterthread.cpp 6
This allows us once to create an object, while running the loop, and also means
that all the methods of the object will be executed in the context of the
run() thread.
In the loop, check whether the name of the serial port for the current trans-
action has changed or not. If it has, reopen and reconfigure the serial port.
\snippet blockingmaster/masterthread.cpp 7
The loop will continue to request data, write to the serial port and wait
until all data is transferred.
\snippet blockingmaster/masterthread.cpp 8
\warning The method waitForBytesWritten() should be used after each write()
call for the blocking approach, because it processes all the I/O routines
instead of the Qt event loop.
The timeout() signal is emitted if an error occurs when transferring data.
\snippet blockingmaster/masterthread.cpp 9
After a successful request, wait for a response, and then try to read it.
\snippet blockingmaster/masterthread.cpp 10
\warning The method waitForReadyRead() should be used before each read()
call for the blocking approach, because it processes all the I/O routines
instead of Qt event loop.
The timeout() signal is emitted if an error occurs when receiving data.
\snippet blockingmaster/masterthread.cpp 11
When a transaction has been completed successfully, the response() signal contains
the data received from the slave application:
\snippet blockingmaster/masterthread.cpp 12
Next, the thread goes to sleep until the next transaction has appeared. On
waking, the thread re-reads the new data from the members and runs the
loop from the beginning.
\snippet blockingmaster/masterthread.cpp 13
\sa {Terminal Example}, {Blocking Slave Example}
*/
|
