How can I write a timer in mac80211 to periodic send a Frame?
And how can I call the other function by transmit the corresponding parameters ?
Thanks all!
Checking my Ubuntu's clock sources:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm
As possibly the outdated RTC, these are all the possible clock sources available.
the mac80211 hardware does not have the timer functionality - NORMALLY.....cannot generalize for all.
Anyway, given these available clocksource, just have to a register an event with the timer to wake periodically to send out data via mac80211.
For example, use this as a base:
http://blog.fpmurphy.com/2009/07/linux-hpet-support.html
Related
Can I wake up task before vTaskDelay expires?
I have code like this:
In the task (hnd_uart_task) code:
transmit_frame();
vTaskDelay(100); // task should wait 100 ticks or be woken up by uart ISR
parse_response();
UART Interrupt:
// if byte was received
BaseType_t xYieldRequired = xTaskResumeFromISR(hnd_uart_task);
portYIELD_FROM_ISR(xYieldRequired);
Instead of using vTaskDelay(), you can use task notifications with timeout.
USART Interrupt:
// if byte was received
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
vTaskNotifyGiveFromISR(hnd_uart_task, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
Task Code:
transmit_frame();
ulTaskNotifyTake(pdTRUE, 100);
parse_response();
ulTaskNotifyTake(pdTRUE, 100) returns when a task notification is received from the ISR, or when 100 tick timeout period elapses.
But as #Jacek Ślimok pointed out, a byte-by-byte parsing may not be good idea. The exact method depends on the protocol used. But in general, you set up your DMA or interrupts to fill a reception buffer with incoming bytes. For example, when parsing Modbus frames, you can use idle line detection hardware interrupt and give notification to a task which parses the RX buffer.
No, because that's not what vTaskDelay was meant to be used for.
The closest solution to yours would be to create a semaphore that you attempt to take inside the task with a 100ms delay and that you give from ISR. This way the task will block for a maximum of 100ms waiting for semaphore to be given, after which it'll unblock and resume execution anyway. If it's given earlier, it'll unblock earlier, which is what I assume you want.
However, from what you've written I assume you want to achieve something like the following:
Send some data over UART
Wait for response
As soon as response is received, do something with the response
In this case, doing both blocking and parsing in the same task is going to be hard (you reaaaalllly don't want to do any sort of parsing inside of your ISR). I'd therefore recommend the following "layout" of two tasks, an interrupt and one shared smepahore between the two tasks:
"High level" task (let's call it ApplicationTask) that can do the following:
Construct whole frames and request them to be sent over UART (add them to some kind of queue). This "construction of whole frames" and sending them over to the other tasks would usually be wrapped into some functions.
Will block waiting for response
Will receive already parsed data (full frame or object/structure holding that parsed data)
"Byte level" task (let's call it ByteTask) that can do the following:
Has a queue for transmitted data (queue of frames or queue of raw bytes)
Has a queue for received data
"Pushes" data from "data to be transmitted" queue into UART
Parses UART data that appears in "received data" queue and gives semaphore to unblock the ApplicationTask
UART Interrupt:
Only transmits data that it's told to transmit by ByteTask
Pushes received data into ByteTask receive queue
Shared semaphore between ApplicationTask and ByteTask:
Whenever ApplicationTask wants to "wait to receive response", it attempts to take this semaphore. Maximum blocking time can be used as a "response receiving timeout".
Whenever ByteTask receives and parses enough data to decide that "yes, this is a complete response", it gives this semaphore.
This above is a super simple example of something that should be easy enough to scale to more tasks as you develop your application. You can get a lot more fancy than that (e.g. ByteTask handling multiple UARTs at the same time, have a pool of semaphores used for blocking for multiple tasks, do some more sophisticated message dispatching etc.), but the example above should hopefully give you a better idea of how something like this can be approached.
The deprecated UpdateSystemActivity() works by "notifying the Power Manager that activity has taken place and the timers used to measure idle time should be updated to the time of this call."
The documentation recommends using IOPMAssertionCreateWithName(...) but this method doesn't reset the timer for the idle time; it prevents the machine from sleeping forever until IOPMAssertionRelease(...) is called. Using IOPMAssertionCreateWithName(...) is unsuitable for my current codebase.
Are there any non-deprecated methods that reset the timer for measuring idle time?
Thanks!
"it prevents the machine from sleeping forever until IOPMAssertionRelease(...) is called"
I don't observe this behavior with macOS 10.15, not for IOPMAssertionCreateWithName(...) . In contrast to documentation IOPMAssertionDeclareUserActivity(...) seems to behave like UpdateSystemActivity() and needs to be called periodically.
See snippet of Screen Saver timer event
examples/common/ScreenSaver.cpp
I ran into this same problem and discovered this closely related question which points to the IOPMAssertionDeclareUserActivity function.
You can use this:
IOPMAssertionID assertionID;
IOPMAssertionDeclareUserActivity(CFSTR(""), kIOPMUserActiveLocal, &assertionID);
Here is the answer in Swift 3.x:
var assertionID : IOPMAssertionID = 0
_ = IOPMAssertionDeclareUserActivity("TeslaWatcher" as CFString, kIOPMUserActiveLocal, &assertionID)
Here is my network handler:
https://gist.github.com/anonymous/22fc110ad126ef3a2c5f
The problem is that when data is received it blocks my animiation (I have a wheel spinning when data has been requested) so it looks like the app have crashed and then after 1 second or 2, when the data has been received, it works like a charm.
This line seems to make sure that when waiting for an answer the app doesn't freeze:
local input,output = socket.select( { self.sock }, nil, 0 ) -- this is a way not to block runtime while reading socket. zero timeout does the trick
Here is another timeout setting:
self.sock:settimeout(0)
I have tried to change them to 0.01 and 0.001 but with no luck. I'm not really sure how to make it so the animation doesn't freeze.
Maybe I should change to one of Coronas built in async network handler (with callback functions) or is it possible to modify this network handler so that the animation doesn't freeze?
If you can use Corona's network.* api, it's async so you won't have any blocking calls.
Documentation link: http://docs.coronalabs.com/daily/api/library/network/index.html
I have a reminder functionality using signal R in asp.net mvc
I have userinterface to set the reminder time, If the current time matches the reminder time , it invokes a popup.
I successfully implemented this functionality with Signal R by checking the database once in every 30 seconds by using javascript timer. If current time does not match, it gives '0'.If it matches, it return '1' and the popup is shown across all browsers. But can this checking the db for every 30 seconds can be replaced by signal R ? is there any way to bring this whole thing to signal R?
You can use System.Threading.Timer to create a periodical method call to both client and server side. According to Sample project created for stocks
_timer = new Timer(UpdateStockPrices, null, _updateInterval, _updateInterval);
It creates and Event-Delegate and calls UpdateStockPrices event timely with period of __updateInterval.
In This event(code given below) you can broadcast the remainder message from server to all clients or clients who are associated with that remainder.
You can write code as :-
Clients.All.updateStockPrice(stock);
You can refer to Timer from link:-
http://msdn.microsoft.com/en-us/library/system.threading.timer.aspx
Yes, you can use Timer in the appdomain scope, application scope or at the hub level. Just get the sample from nuget, called "Microsoft.AspNet.SignalR.Sample". It implements stock timer that periodically broadcasts changes to all clients.
NSRunLoop has two apis:
- (BOOL)runMode:(NSString *)mode beforeDate:(NSDate *)limitDate
and
- (void)acceptInputForMode:(NSString *)mode beforeDate:(NSDate *)limitDate
I mean they are same except return value, or there are other differences?
As #DarkDust hints at, it used to have to do with timers. See Chris Kane's discussions on the Cocoa mailing list. At one point, runMode:beforeDate: was a wrapper around limitDateForMode: and acceptInputForMode:beforeDate: (since acceptInputForMode:beforeDate: didn't fire timers). My reading of the docs, headers, and crash stacks suggests that today, they behave identically (calling CFRunLoopRunInMode(), which does fire timers). But I haven't built a test app to confirm.
If you read the original NeXT ObjC manual, acceptInputForMode:beforeDate: used to explicitly not fire timers:
Blocks awaiting input from the ports in the port list for the input mode mode until the time specified by limitDate. Use the limitDateForMode: method to calculate limitDate. If input arrives, it is processed using the NSPort delegates. This method does not check the timers associated with mode, thus it does not fire timers even if their scheduled fire dates have passed.
Timers were explicitly handled as a side effect of limitDateForMode:
Polls mode's input sources for their limit date (if any) and returns the earliest limit date for this mode. Uses the NSPort delegate method limitDateForMode: to determine the limit dates of ports. Fires timers if their limit dates have passed. Polls ports for activities appropriate for mode. Returns nil if there are no input sources for this mode.
Which is why runMode:beforeDate: was added as a convenience (see NSRunloop.h):
#interface NSRunLoop (NSRunLoopConveniences)
- (void)run;
- (void)runUntilDate:(NSDate *)limitDate;
- (BOOL)runMode:(NSString *)mode beforeDate:(NSDate *)limitDate;
#if (TARGET_OS_MAC && !(TARGET_OS_EMBEDDED || TARGET_OS_IPHONE))
- (void)configureAsServer NS_DEPRECATED(10_0, 10_5, 2_0, 2_0);
#endif
See also from NeXT:
The method limitDateForMode: returns the earliest limit date of all the input sources for the mode NSDefaultRunLoopMode. acceptInputForMode:beforeDate: runs the loop until that date, processing any input it receives until that time. As a convenience, you can use runMode:beforeDate: instead. It invokes acceptInputForMode:beforeDate: and limitDateForMode: with the mode you supply.
So the short answer: history.