| Age | Commit message (Collapse) | Author |
|---|
|
I haven't even compile-tested Linux and OSX-specific bits.
|
|
|
|
|
|
We heavily used "volatile bool" to check if the thread
loop should stop. But this functionality is already
provided by Qt5's QThread::requestInterruption.
In other cases, "volatile" is wonderfully
underspecified so it's better to ditch its usage in
favor of std::atomic<t>. At the time we don't appear to
be using the "volatile" keyword except when calling
win32's Interlocked*() family of functions as
necessary.
In freetrackclient's header the "volatile" qualifier
was used as part of a typedef. This doesn't work. Use
it as part of data declaration.
|
|
|
|
|
|
|
|
Adjust usages.
|
|
We no longer have this recurring problem since I enabled
ignoring executable bit changes on the Windows workstation.
|
|
|
|
|
|
It's not used anywhere.
|
|
|
|
We can't have async io on the main thread because QSerialPort's
readyRead() signal can fire constantly, thus consuming all CPU time.
We can't sleep in the main thread either as that blocks too many things.
We can't ignore readyRead() invocations over a threshold as that'll make
us lose some of data notifications.
Refactor hatire to put IO on a thread. Since this is a separate Qt event
loop, we may sleep in there.
Further, add a debug mode reading data from a file, as if it came from a
serial-attached device.
Issue: #327
|
|
Closes #224
|
