I am trying to write a simple program in TinyOS to implement 2 timers, one a periodic timer, and the other a oneshot timer. The periodic timer has to fire every 2 seconds and the oneshot timer should fire at 5th, 7th and 9th second respectively. I have written the program, but the oneshot timer doesn't work. Please help me find the issue.
#include "Timer.h"
module MyTimerC #safe()
{
uses interface Timer<TMilli> as Timer0;
uses interface Timer<TMilli> as Timer1;
uses interface Leds;
uses interface Boot;
}
implementation
{
event void Boot.booted()
{
call Timer0.startOneShot( 5120 );
call Timer0.startOneShot( 7168 );
call Timer0.startOneShot( 9216 );
call Timer1.startPeriodic( 2048 );
}
task void TogLed0()
{
dbg("MyTimerC", "LED 0 Toggle \n");
call Leds.led0Toggle();
}
task void TogLed1()
{
dbg("MyTimerC", "LED 1 Toggle \n");
call Leds.led1Toggle();
}
event void Timer0.fired()
{
dbg("MyTimerC", "One shot Timer 0 fired # %s \n", sim_time_string());
call Leds.led2Toggle();
}
event void Timer1.fired()
{
dbg("MyTimerC", "Periodic Timer 1 fired # %s.\n", sim_time_string());
post TogLed0();
post TogLed1();
}
}
You're only supposed to call startOneShot once on a timer - you should only call startOneShot again on the same timer after it has fired. I would suggest either using 3 separate timers for your one shots, or call startOneShot(5 seconds) on boot, then when it fires, call startOneShot again for 2 seconds, then a third time. Use a counter to keep track of how many times it has fired.
Related
I am using QSound to play audio file. Audio file duration is 10 sec.
I have some task after playing the complete 10 sec audio file. So for this I am using QSound::isFinished method, but this always returns false instantly. example
Based on the current wording of the question, I'm assuming you're checking isFinished immediately, which will indeed return false.
I think you're best bet is to use QTimer and connect it's timeout signal to some slot which will check isFinished. You would start the timer when the sound starts playing. When isFinished returns true, you can stop the timer and do whatever it is that needs doing. If it returns false, wait for the next timeout.
// In the .h
// ...
private slots:
void onTimeout();
private:
QTimer* timer;
QSound sound;
// ...
// In the .cpp
// In your constructor
// ...
timer = new Timer();
connect( timer, SIGNAL( timeout() ), this, SIGNAL( onTimeout() ) ),
// ...
// Starting the sound
// ...
sound.play();
timer.start( 10 ); // In milliseconds.
// ...
// onTimeout slot
void MyClass::onTimeout()
{
if( sound.isFinished() )
{
timer.stop();
// Do some things.
}
}
I chose 10 milliseconds in the assumption that the audio file's of different length could be played. QSound is also not guaranteed to start playback immediately.
If you know for a fact that the audio played will always have the same length, you could forgo the isFinished check and change the Timer to a single shot with a duration the same length of the file (plus a bit to account for variable start times). This will result in it only timing out once, and should do so after the file has finished. That's not my preferred method, but it is a possibility.
Use a QSoundEffect instead and connect to the playingChanged signal.
http://doc.qt.io/qt-5/qsoundeffect.html#playing-prop
I have a qt program. I have CAN requests that I want to send in sequential order.
I want to wait for answers, before sending other requests.
SendReadLatchCommand(fam,prod,addr,0x00000000, 4); // 1st request
// wait for answer and analyze it??
SendReadLatchCommand(fam,prod,addr,0x00000002, 4); // 2nd request
I have a receiveData() method, called by my thread of reception, where I save the received message.
I want to sleep in my main program and we awake when receiving answer.
I can't use signal/slot because in the slot, I don't know what is the last request I sent, so I can't continue emitting requests.
How can I do this?
thanks
If i understand you properly, you wanted to process the request synchronously.
Look into the QEventLoop in the qtdoc, you can do it this way:
QEventLoop wait_loop;
// 1st request
connect(request_1, SIGNAL(sig_answer_arrived()), &wait_loop, SLOT(quit()));
request_1->send_request();
wait_loop.exec();
// here we already got the answer
analyze_answer();
// the 2nd request does the same
I'm not sure whether it is a good idea to block your main thread, however it can be done by using a binary semaphore, which is the same as a counting semaphore with a maxCount of 1. Therefore one can use a counting semaphore QSemaphore
Typically, a QSemaphore is implemented in terms of QWaitCondition (refer Qt help). One could block on a wait condition until the CAN thread signals the wait condition. One can hide the blocking on the wait behind some interface e.g:
//--- Very simple implementation - concept only
QWaitCondition cond_;
QMutex mutex_;
void rxThreadHandler( /*args*/ )
{
while( !quitCalled() )
{
waitOnReceivedData();//Blocks, I assume...
handleReceivedData();
answerRxd();
}
}
void answerRxd()
{
QMutexLocker lock( mutex_ );
cond_.wakeAll();
}
void sendNext( const Buffer& buffer )
{
QMutexLocker guard( mutex_ );
//Waits/Blocks until condition signalled, then locks mutex
// to prevent further signalling (might block rx thread)
cond_.wait( lock.mutex() );
//Unlocking mutex explicitly to allow receipt of data
guard.unlock();
//Now send as result of previous receive. This does not
// prevent receiving thread...
sendNextImpl( const Buffer& buffer );
}
I have a QPushButton, and a slot connected to its "pressed" signal like that:
connect( &m_oBtnSnapshot, SIGNAL( pressed() ), this,
SLOT( SnapshotClicked() ) );
The Slot is implemented like that:
void
GUI::SnapshotClicked()
{
m_oBtnSnapshot.blockSignals( true );
m_oBtnSnapshot.setDisabled( true );
m_oBtnBenchmark.repaint();
m_oBtnBenchmark.update();
emit( DoSnapshotWork() );
m_oBtnSnapshot.setDisabled( false );
m_oBtnSnapshot.blockSignals( false );
}
So as you can see, i disable the button when i click it, and re enable it when everything is done.
Let's assume the DoSnapshotWork() function takes 5 seconds... While this 5 seconds the button is disabled, but if i click it, the SnapshotClicked() Slot will be called afterwards. Why does disabling a button not prevent me from clicking it?
i alread tried disconnecting the signal on entering the slot and reconnecting it afterwards, but nothing helped.
GUI::SnapshotClicked() is a part of GUI thread, which means, while it runs, your GUI is unaccessible. I assume, signal DoSnapshotWork() is connected with a slot, running in another thread with Qt::QueuedConnection (or Qt::AutoConnection). In that case emitting this signal is asynchronous, which means GUI::SnapshotClicked() is finished long before your slot is done. I guess you should do something like this:
gui.h
public slots:
void onReleaseButton();
gui.cpp
void
GUI::SnapshotClicked()
{
m_oBtnSnapshot.setDisabled( true );
m_oBtnBenchmark.repaint();
m_oBtnBenchmark.update();
emit( DoSnapshotWork() );
}
void
GUI::onReleaseButton()
{
m_oBtnSnapshot.setDisabled( false );
}
Somewhere else:
connect(shapshotWorker, SIGNAL(releaseButton()), gui, SLOT(onReleaseButton()));
...
DoSnapshotWork()
{
...
emit releaseButton();
}
P.S: You need a good reason to use QPushButton::pressed() signal. In most cases you would prefer QPushButton::clicked().
Because the mouse press events are on placed onto the event loop, and wait until your SnapshotClicked() method is complete, by which time the button is enabled again.
A simple solution is to call QCoreApplication::processEvents() immediately after the emit, this will cause the press events to processed whilst the button is still disabled. Or you can have the DoSnapshotWork() method emit a signal when it's finished, and have that enable the button and unblock the signals.
Also,
m_oBtnBenchmark.repaint();
m_oBtnBenchmark.update();
repaint()redraws the widget forcibly, whilst update() calls repaint() via the event loop - do not call them both.
Environment: Ubuntu, Qt Creator
In my Qt app, I found that sometimes Qt doesn't respond to my key press event immediately, but if I wait a while, it eventually responds.
I think something is blocking the UI.
As I know, if a Qt's component (QWidget etc.) is being destroyed, the Qt UI will be blocked. I have checked my code, there is no component being destroyed at the time I'm pressing the up/down key.
I really want to know is there any other things can block Qt UI.
{
...
connect(webViewWidget, SIGNAL(loadfinished()), this, SLOT(addItem()));
...
}
void addItem()
{
delete webViewWidget; // will this delete block UI?
mListWidget = new ScrollWidget();
mScrollArea = new ScrollArea(this);
for(int i=0; i<Datalen; i++)
{
mListWidget->addSubItem(itemWidget);
}
}
void keyPressEvent(QKeyEvent *event)
{
switch(event->key)
{
case UP_KEY:
scroll up;
break;
case DOWN_KEY:
scroll down;
break;
default:
break;
}
}
In general, your key press event will not be processed before all other events which were put into the application's event queue before pressing your key are processed.
Therefore it could be any kind of event which has not finished processing. Maybe you can figure out if there are any events, e.g. by using QApplication::hasPendingEvents or by inheriting from QApplication and adding debug output whenever an event is added or fully processed.
Destruction of objects is usually not a concern, unless you are doing a lot of work in the destructor. Destroying a webview may take long. You probably should not be destroying it like you do. Instrument that delete (see code below) and see how long it takes.
Your own code may be calling APIs that block. Are you calling any third party libraries? Are you calling any wait... methods in Qt's own API?
If you're unsure, you can instrument every slot and every reimplemented virtual method like xxxEvent(...). You'd need to instrument only slots and reimplemented QObject/QWidget methods, not every method in your code.
You may be producing an event storm, perhaps by posting lots of events in a loop, or by sending a lot of signals that are hooked up to slots connected via a Qt::QueuedConnection. Make sure you're not calling repaint() from within paintEvent() for example.
The instrumentation example below uses RAII and is very easy to apply. Alternatively, you can use a profiler.
#include <QElapsedTimer>
#define INSTRUMENT() Instrument instr__ument(__FUNCTION__)
#define INSTRUMENTLIM(lim) Instrument instr__ument(__FUNCTION__, (lim))
class Instrument {
QElapsedTimer timer;
int limit;
const char * function;
public:
Instrument(const char * name, int timeLimitMs = 20) :
function(name), limit(timeLimitMs) { timer.start(); }
~Instrument() {
if (timer.elapsed() > limit) {
qDebug("%s was slow, took %d ms", function, timer.elapsed());
}
}
}
void slot(...)
{
INSTRUMENT();
...
}
void addItem()
{
INSTRUMENT();
delete webViewWidget; // will this delete block UI?
mListWidget = new ScrollWidget();
mScrollArea = new ScrollArea(this);
for(int i=0; i<Datalen; i++)
{
mListWidget->addSubItem(itemWidget);
}
}
When using glib to dispatch signals through emit, are all the "listeners"/handlers called back-to-back or is control relinquished to the event loop after each listener/handler?
The callbacks are all called back-to-back without relinquishing control to the main loop.
Actually, as far as I know, g_signal_emit() does not even return control until all handlers are called, so there is no opportunity for the main-loop to kick-in.
So to answer the question in the title of this post: no, glib signals are not asynchronous.
GLib signals can be handled synchronously or asynchronously. GObject signals are always synchronous, i.e. when you emit a signal it does not return until the signal is handled.
To have a signal asynchronously handled with GLib, (I am using vala for brevity - use the vala compiler to convert the code into plain C) you must define a signal Source, or use a predefined one, as for example IdleSource or TimeoutSource (when I/O is out of question). For example assume that you have a function
void my_func() {
stdout.puts("Hello world! (async)\n");
}
and you want to call it asynchronously (from the same thread!) from
void caller() {
// Here you want to insert the asynchronous call
// that will be invoked AFTER caller has returned.
// Body of caller follows:
stdout.puts("Hello world!\n");
}
Here is how you do it:
void caller() {
// Code for the asynchronous call:
var ev = new IdleSource();
ev.set_callback(() => {
my_func();
return Source.REMOVE; // Source.REMOVE = false
});
ev.attach(MainContext.default());
// Body of caller follows:
stdout.puts("Hello world!\n");
}
You will get the following output:
Hello world!
Hello world! (async)
The my_func() function will be executed when MainLoop is idle (i.e. it has no other signals to process). To trigger it after a specific time interval has elapsed use the TimeoutSource signal source. A MainLoop must be running, otherwise this will not work.
Documentation:
https://valadoc.org/glib-2.0/index.htm
https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html