Assume a pci-driver for the linux-kernel. This device can have multiple channels that can be "up'ed" or "down'ed" individually.
Each "up" calls the function .ndo_open and each "down" calls .ndo_stop.
This device needs only one interrupt-line which can be requested with request_irq (). Each request will create one interrupt-line.
Important to note here is, that interrupt-lines are rare and they should not be created mindless.
My question to this situation is, where should I use request_irq()?
In my opinion I have two possible solutions for this.
Right in the probe(). This will only create one interrupt-line but it will always be created when the pc is turned on. So it might be unused.
In .ndo_open. This will create the interrupt-line only when it is needed, but a multichannel device can create mutliple calls of .ndo_open which will result in multiple calls of request_irq()
I was not able to find any information about this situation in the kernel docs. If there is some guideline for this, can you please explain/show it to me? I also checked other pci-drivers from the git-repo but none (or at least the ones I checked) had this problem.
Related
I'm learning about MQTT (specifically the paho C library) by reading and experimenting with variations on the async pub/sub examples.
What's the difference between the MQTTAsync_deliveryComplete callback that you set with MQTTAsync_setCallbacks() vs. the MQTTAsync_onSuccess or MQTTAsync_onSuccess5 callbacks that you set in the MQTTAsync_responseOptions struct that you pass to MQTTAsync_sendMessage() ?
All seem to deal with "successful delivery" of published messages, but from reading the example code and doxygen, I can't tell how they relate to or conflict with or supplement each other. Grateful for any guidance.
Basically MQTTAsync_deliveryComplete and MQTTAsync_onSuccess do the same, they notify you via callback about the delivery of a message. Both callbacks are executed asynchronously on a separate thread to the thread on which the client application is running.
(Both callbacks are even using the same thread in the case of the current version of the Paho client, but this is a non-documented implementation detail. This thread used by MQTTAsync_deliveryComplete and MQTTAsync_onSuccess is of course not the application thread otherwise it would not be an asynchronous callback).
The difference is that MQTTAsync_deliveryComplete callback is set once via MQTTAsync_setCallbacks and then you are informed about every delivery of a message.
In contrast to this, the MQTTAsync_onSuccess informs you once for exactly the message that you send out via MQTTAsync_sendMessage().
You can even define both callbacks, which will both be called when a message is delivered.
This gives you the flexibility to choose the approach that best suits your needs.
Artificial example
Suppose you have three different functions, each sending a specific type of message (e.g. sendTemperature(), sendHumidity(), sendAirPressure()) and in each function you call MQTTAsync_sendMessage, and after each delivery you want to call a matching callback function, then you would choose MQTTAsync_onSuccess. Then you do not need to keep track of MQTTAsync_token and associate that with your callbacks.
For example, if you want to implement a logging function instead, it would be more useful to use MQTTAsync_deliveryComplete because it is called for every delivery.
And of course one can imagine that one would want to have both the specific one with some actions and the generic one for logging, so in this case both variants could be used at the same time.
Documentation
You should note that MQTTAsync_deliveryComplete explicitly states in its documentation that it takes into account the Quality of Service Set. This is not the case in the MQTTAsync_onSuccess documentation, but of course it does not mean that this is not done in the implementation. But if this is important, you should explicitly check the source code.
In a professional context, I have to use the vl53L0x. This sensor was released recently, along with it's API, meaning that there's no help on the internet yet :
http://www.st.com/content/st_com/en/products/embedded-software/proximity-sensors-software/stsw-img005.html
This API contains some source and headers file, that I compiled with the gcc. It works fine, despite clearly lacking comments. I flash the memory of a stm32 (NUCLEO-F401RE), which controls a vl53L0x sensor via an I2C bus. I now want to add more vl53L0x sensors on the same I2C bus, and refer to this document (if you want to read it, go directly to the bottom half of the page 5, the wiring is already done) :
http://www.st.com/content/ccc/resource/technical/document/application_note/group0/0e/0a/96/1b/82/19/4f/c2/DM00280486/files/DM00280486.pdf/jcr:content/translations/en.DM00280486.pdf
The principle, that I already applied on other sensors, is that they all start with the same address. You then have to activate one, change it's address, then activate the next one, change it's address, etc.
Unfortunately, ST Microelectronics didn't publish the list of the I2C registers, so I have to use their API to control multiple sensors. The document linked above explains how to do so. Among other things, it specifies :
In vl53L0x_platform.h API file
• Set VL53L0x_SINGLE_DEVICE_DRIVER macro to 0 so that API implementation will
be automatically adapted to a multi-device context.
I looked everywhere in the API folder, I was not able to find any reference to a VL53L0x_SINGLE_DEVICE_DRIVER macro. Setting it to 0 won't change anything, as this string is not present anywhere in the API files. Did anyone run into a similar problem ?
I'm working on the same thing. It seems that you're further ahead than I am. However, putting this in my while(1) loop seems to make both the sensors work.
ResetAndDetectSensor(0);
TimeStamp_Reset();
The guide says that in order to use all the sensors simultaneously, you need to pull the XSHUT pin high for all the sensors, reset the timestamp and then pick up the sensor which actually detects something.
I'm guessing I'm going to need to do threading but before I teach myself some bad practices I wanted to make sure I'm going about this the correct way.
Basically I have a "chat" application that can be told to listen or ping the recipients' ip address:port (in my current case just 127.0.0.1:1300). When I open up my application twice (the first one to listen, the second to send a ping) I pick one and tell it to listen(Which is a While statement that just constantly listens until it gets a ping message) and the other one will ping it. It works just peachy!
The problem is when I click the "Listen for ping" button it will go into a glued "down" mode and freeze up "visually" however it prints the UDP packet message to the console so i know its not actually frozen. So my question is how to I make it so I can click the "Listen" button and have it "listen" while at the same time have a "working" cancel button so the user can cancel the process if its taking too long?
This most likely happens because you use synchronous (blocking) socket IO. Your server application most likely blocks on the recv()/read(), which blocks your thread's execution until some data arrives; it then processes the data and returns to blocked state. Hence, your button is rendered by GTK as pushed.
There are, basically, two generic approaches to this problem. The first one is threading. But I would recommend against it in the simpler applications; this approach is generally error-prone and pretty complicated to implement properly.
The second approach is asynchronous IO. First, you may use select()/poll() functions to wait for one of multiple FDs to be signalled (on such events as 'data received', 'data sent', 'connection accepted'). But in a GUI application where the main loop is not immediately available (I'm not sure about GTK, but this is the case in many GUI toolkits), this is usually impossible. In such cases, you may use generic asynchronous IO libraries (like boost asio). With GLIB, IIRC, you can create channels for socket interaction (g_io_channel_unix_new()) and then assign callbacks to them (g_io_add_watch()) which will be called when something interesting happens.
The idea behind asynchronous IO is pretty simple: you ask the OS to do something (send data, wait for events) and then you do other important things (GUI interaction, etc.) until something you requested is done (you have to be able to receive notifications of such events).
So, here's what you may want to study next:
select()/poll() (the latter is generally easier to use)
boost asio library
GLIB channels and asynchronous IO
I'm working on a library which implements the actor model on top of Grand Central Dispatch (specifically the C level API libdispatch). Basically a brief overview of my system is as such:
Communication happens between actors using messages
Multicast communication only (one actor to many actors)
Senders and receivers are decoupled from one another using a blackboard where messages are pushed to.
Messages are sent in the default queue asynchronously using dispatch_group_async() once a message gets pushed onto the blackboard.
I'm trying to implement futures in the language right now, so I've created a new type which holds some information:
A group of its own
The value being 'returned'
However, I have a problem since dispatch_block_t is of type void (^)(void) so it doesn't return anything. So my idea of in my future_new() function of setting up another group which can be used to execute a block returning a result, which I can store in my "value" member in my future_t structure, isn't going to work.
The rest of the futures implementation is very clear, except it all depends on being able to get the value into the future back from the actor, acting on the message.
When using the library, it would greatly reduce its usefulness if I had to ask users (and myself) to be aware when futures were going to be used by other parts of the system—It just isn't practical.
I'm wondering if anyone can think of a way around this?
Actually had Mike Ash's implementation pointed out to me, and as soon as I saw his initWithBlock: on MAFuture, I realized what I needed to do. Very much akin to what's done there, so I'll save the long winded response about how I'm doing it.
I encountered a bug that has me beat. Fortunately, I found a work around here (not necessary reading to answer this q) -
http://lists.apple.com/archives/quartz-dev/2009/Oct/msg00088.html
The problem is, I don't understand all of it. I am ok with the event taps etc, but I am supposed to 'set up a thread-safe queue) using MPQueue, add events to it pull them back off later.
Can anyone tell me what an MPQueue is, and how I create one - also how to add items and read/remove items? Google hasn't helped at all.
It's one of the Multiprocessing Services APIs.
… [A] message queue… can be used to notify (that is, send) and wait for (that is, receive) messages consisting of three pointer-sized values in a preemptively safe manner.