I'm currently developing an embedded application on Microsemi Smartfusion 2 using FreeRTOS.
It works with no issue when in Debug Mode and also in Run Mode. However, when I don't start the code using the debug/run buttons Eclipse (i.e. when I turn the power off and on again), it starts normally but resets itself a few seconds later. I feel this issue is related to the debugger but I can't solve it.
Any ideas?
Possibly you have a watchdog timer enabled but not serviced that is held-off when the debugger is attached? I am not familiar with the SoC but there is a note to the answer at http://www.actel.com/kb/article.aspx?id=FQ1025:
SoftConsole will automatically disable the watchdog in Debug mode regardless of whether the code is running from eNVM or eSRAM.
Then the first part of that same answer states:
The Watchdog is enabled at power-up and remains so unless explicitly disabled.
So by guess is that you are not servicing the watchdog timer. I'd like to point you at the documentation that makes this clear, but to be frank - I gave up! YMMV. There is a note of the watchdog here.
Is there an elegant way of doing a hard restart of an actor - i.e. clearing out the mailbox along with internal state?
I know it can be done by calling context.stop and reinitializing upon the DeathWatch / Terminated message, but that's a bit clunky.
No, clearing out the mailbox is exactly what is done by terminating the actor. If you were to try that without the termination semantics, how could you ever be sure that you cleared everything? New messages could come in at any point in time.
So, to do that hard restart you
return the Stop directive from the supervisor strategy
then create a new child once you receive that actor’s Terminated message.
I am working on some kind of communication which might get interrupted once in a while. For this I need some kind of monitor that fires after 5 seconds, if not in the meantime has been reset by any valid communication to start waiting for another 5 seconds, and so on....
Thanks!
Take a look at the NSTimer class.
I have a problem with a CFSocket.
I need to enable and disable the
callbacks from the socket and for this i use
CFSocketEnableCallBacks(cfSocket, kCFSocketReadCallBack);
and
CFSocketDisableCallBacks(cfSocket, kCFSocketReadCallBack);
But, when you wake up the callback I get old messages.
is probably a problem of reset (?)
How do I reset everything before disabling
callback?
Now i face a problem in my porting job, when i need to implement a thread class that will work in not only wince, symbian ,but also unix-like system, like iphone.
I own a suspend/resume interface to implement, anything is ok in wince/symbian except iphone, i use the posix pthread to finish my job, but i search the whole docsets for a resume/suspend-like interface. Things seem to be difficult, pthread in iphone own a pthread_create_suspended_np that can create a thread in a suspend mode. Now how can i resume or suspend a thread after the thread has run to its stuff in anytime.
BTW, i search Google for some help, it seems that someone else also have this problem .
Some guys suggest use the SIGHUP signal, but this will suspend the whole process, that's absolutely not ok .
Many thanks if you guys can tell me some solutions for this problem.
It's actually a bad idea to try and control threads externally. You never know what state they may be in when you suspend them. If they have a mutex lock on a resource that's needed elsewhere, you can easily end up with a deadlock situation.
We had to create a "safe" suspend functionality without resorting to any non-portable pthread extensions a while ago and I'll try to remember how we did it.
It consisted of a suspension mutex for each thread and a variable indicating that threads state. So the thread we wanted to suspend would have a loop (they mostly do) that went something like this:
while true:
set mystate = suspended
claim mymutex
yield
release mymutex
set mystate = running
do some work
and the code to suspend/resume the thread would be:
function suspend (state,mutex):
claim mutex
while state <> suspended:
yield
function resume (state,mutex):
release mutex
while state <> running:
yield
What the suspender would do is basically get a lock on the mutex and wait for the thread to enter suspended state (the writing to mystate was done only by the suspendee and did not have to be protected by another mutex). The suspend function did not return until it was guaranteed that the suspendee would be stopped.
Similarly, resuming the thread released the mutex so the suspendee could restart and then waited until it had restarted before returning.
This allowed suspension to take place but under the control of the thread being suspended. That was much safer since it could ensure it could only be suspended at safe points when it didn't have any locks that could deadlock the application.
To suspend and resume a running thread, I believe you need to use pthread_cond_wait. Basically, that suspends the calling thread until the condition variable becomes true. Of course, you need to also give each thread a way to figure out when to call the function.
you give me a clue to solve this problem , yet this method or pthread_cond_wait just wait/singal when design some kind of situation. How can i suspend the special pthread without know more info. about the thread, we just own a thread id, we suspend it in another thread, when we wanna resume the suspended thread, we just probably run the resume function in anywhere. can we do something like this? or any other idea ?
regards.