FreeRTOS Wifi down event does not call vApplicationIPNetworkEventHook - freertos

I've been trying to find a solution to get amazon-freertos to detect WIFI network down so I can reconnect. I have to say I am still not fully in understanding of how it all should work.
From reading up it looks like the intended way is to wait for callback to vApplicationIPNetworkEventHook where the programmer should implement necessary reconnects. However the problem is that this callback function does not get called for network down events, it only get called for network up events.
Reading FreeRTOS guide I see that for vApplicationIPNetworkEventHook to get a callback for network down event the underlying driver must first tell the TCPIP stack of this event, and it goes on to say not all drivers implement this, so I think I have located the problem now.
My question is how should the driver inform the TCPIP stack? The driver logs the network down event (it doesn't do much more than that) so I can add some code there to alert the TCPIP stack, but how should that be done? I cannot find any instructions for how to make this change, any help or suggestion is much appreciated.
amazon-freertos: https://github.com/MicrochipTech/amazon-freertos
MCU Test Board: Microchip curiosity_pic32mzw1
To add I think this should be the place (iot_wifi.c) to implement it:
WIFIReturnCode_t WIFI_RegisterNetworkStateChangeEventCallback( IotNetworkStateChangeEventCallback_t xCallback )
{
/** Needs to implement dispatching network state change events **/
return eWiFiNotSupported;
}
The question is just how.
Thanks,
Marcus

You can add a call to vApplicationIPNetworkEventHook() using eNetworkDown as the parameter.

Related

Swift: Show UIAlert while waiting for semaphore

I'm using CocoaAsyncSocket pod to transfer data from measurement instrument to an iOS device. The transfer works pretty well, but I get in trouble, if I have to switch between different mobile instruments.
If I need to change the instrument / connect to another instrument, I have to wait for some events:
I have to be sure to be disconnected. This is typically done by waiting for public func socketDidDisconnect(...) included in the GCDAsyncSocketDelegate
I have to connect to the other instrument. If it is still the tcp interface, I have to wait for public func socketDidConnectToHost(...)
So there are two operations which take some time. Because there is no valid connection, the user just can wait. To inform the user what's going on, I would like to present an UIAlert until the mentioned events are finished. How can I achieve this?
Semaphores seem way too low level for your case, unless you are doing it for educational purposes.
Using NotificationCenter instead:
1) Post a "didDisconnectNotification" (string name being arbitrary) from socketDidDisconnect(...) and in it's corresponding handler update your viewController UI indicating the user a connectivity problem.
2) Post a "didConnectNotification" from socketDidConnectToHost(...) and in it's handler (distinct from 1) dismiss the connectivity problem indicator^.
Note: On your viewController first appearance you would probably start with 2) so there's nothing yet to dismiss.
You can find numerous examples related to NotificationCenter on SO:
https://stackoverflow.com/a/24756761/5329717
In a scenario where the two aforementioned operations are independent (i.e. they can occur in any order relative to each other) the GCD mechanism to use would be DispatchGroup. It's somewhat closer to your attempt at using a semaphore, however you don't need it either because your 2 events (disconnect & connect) are dependent (i.e. their respective order of occurence is fixed).
An example valid usage case of DispatchGroup would be synchronising responses of many image fetch requests when you don't care about their order of arriving (you either get all of them or do not proceed).

grpc iOS stream, send only when GRXWriter.state is started?

I'm using grpc in iOS with bidirectional streams.
For the stream that I write to, I subclassed GRXWriter and I'm writing to it from a background thread.
I want to be as quick as possible. However, I see that GRXWriter's status switches between started and paused, and I sometimes get an exception when I write to it during the paused state. I found that before writing, I have to wait for GRXWriter.state to become started. Is this really a requirement? Is GRXWriter only allowed to write when its state is started? It switches very often between started and paused, and this feels like it may be slowing me down.
Another issue with this state check is that my code looks ugly. Is there any other way that I can use bidirectional streams in a nicer way? In C# grpc, I just get a stream that I write freely to.
Edit: I guess the reason I'm asking is this: in my thread that writes to GRXWriter, I have a while loop that keeps checking whether state is started and does nothing if it is not. Is there a better way to do this rather than polling the state?
The GRXWriter pauses because the gRPC Core only accepts one write operation pending at a time. The next one has to wait until the first one completes. So the GRPCCall instance will block the writer until the previous write is completed, by modifying its state!
In terms of the exception, I am not sure why you are getting the problem. GRXWriter is more like an abstract class and it seems you did your own implementation by inheriting from it. If you really want to do so, it might be helpful to refer to GRXBufferedPipe, which is an internal implementation. In particular, if you want to avoid waiting in a loop for writing, writing again in the setter of GRXWriter's state should be a good option.

Integrating Reachability with ReactiveCocoa?

I'm working on the development of an app using ReactiveCocoa and the time has came to integrate Reachability to handle Network Events.
I'm not sure about the work I've done as some of RAC design guidelines advice against it. But from what I've been researching I couldn't find a proper way to manage this (or more likely, I dind't understand how).
Our idea is to have a unique signal that sends events upon Reachability's notifications. Each of our viewcontrollers would subscribe to that signal and react each one in its specific way (ie alertview, do nothing, etc).
The thing is that we only need our visible viewcontroller to react, so we are using RACDisposable. This way, when a viewcontroller appears it subscribes to the signal, and when it dissapears we dispose it.
From the Design Guidelines of RAC the use of RACDisposable should be avoided, but I can't manage to handle this subscribe/unsubscribe cycle in any other way.
Is this approach correct for this kind of "infinite" signals?
An alternative we though of is using a signal that removes its previous subscribers when a new one joins. Does such a thing exist?
Thanks in advance for any light you can point in my direction.
From this SO post I got to trying takeUntil:[self rac_willDeallocSignal]which seems useful in theory but doesn't really work for me. As this behaviour is encapsulated within a Manager, and it's not supposed to be deallocated, I don't know how this can work in my favour.
An option that crossed my mind is takeUntila new signal fires whenever a method to stop is called; but it seems pretty much just so we don't use RACDisposable.
From this SO post I got to trying takeUntil:[self rac_willDeallocSignal]which seems useful in theory but doesn't really work for me. As this behaviour is encapsulated within a Manager, and it's not supposed to be deallocated, I don't know how this can work in my favour.
Your view controller can do something like this:
- (void)viewWillAppear
{
RACSignal *disappear = [self rac_signalForSelector:#selector(viewWillDisappear)];
[[self.manager.reachabilitySignal takeUntil:disappear] subscribeNext:^(id status) {
// do whatever needs doing with reachability status here
}];
}
and your Manager's reachabilitySignal can be implemented to register/de-register for reachability status changes as needed depending on whether there are any subscribers.

Register Errors and device drivers

I am writing a device driver where I need to read and write to a lot of registers. Is there any way I can tell if the operation as been successful? Currently we have a driver for some old HW but all of the driver functions are void and we just assume the operation was successful.
Are there any known tips or design patterns which would be good to follow when making a device driver?
Thanks,
You could do any of the following which suits you :
1) just write the register and immediately read back the same register.
2) create a function which outputs the value of each register when called.
Just make sure some registers might reset when read from it ( This might cause your code to malfunction )

Luasocket irc check to receive message

I am trying to use luasocket to connect to an Irc channel and send and receive messages within my game (Wolfenstein Enemy Territory, If that helps).
Right now I am able to do all of that, with one problem. Once I set it to listen for a message, it basically locks up. I have a fallback command if I type stoplisten in Irc it just stops the script, And I can see it got all the message, but the game itself is locked up while waiting for the messages.
Any Ideas on how I would do this without freezing the game? I have just recently learned a little of coroutines So I do not know if I am using them correctly.
I should also note I have access to a run frame functions which runs every millisecond if that helps (Though normally it is done like: if math.mod(currentTime, 50) ~= 0 then return end)
Here is the part in my code: http://pastebin.com/j1gCqm4R
(I wasnt gonna edit all my code with an indent just to post it here, so i just put it on pastebin)
Your problem is that all sockets are, by default, blocking, which means they will halt ('block') the current thread of execution (in this case, your game) until they either get the desired result or 'timeout'.
The solution is non-blocking sockets. invoke :settimeout(0) on your client socket object, and all future :send(...) :recieve(...) will return immediately, having either succeeded, or timed-out.
The LuaSocket reference contains the full details, but you will have to modify your code either to handle the 'timeout' failure state, or add calls to socket.select() to make sure that you only use sockets that are 'ready' to be used.

Resources