Hi guys I need some help. I am making a c++ embedded application in an ARM. I need to get a push button event, I was looking for in internet and I find that the best way to do it is with interruptions. I know that I can set one pin through terminal like this "echo raise > /sys/.../gpio/gpio81/edge". But I need to know how can I get the interrupt from my C++ application when it happend, I just need some example, because I do not know if I have to use some special library.
Thank you guys I hope someone can help me.
Manual 'mechanical' pushbuttons require debouncing. That, and the fact that pushing buttons does not require high I/O performance, means that a GPIO interrupt is an awkward overkill. It can' of course, be done, but it's easier and safer to poll the GPIO port with a timer interrupt, storing the state of the inputs and comparing with the previous state/s. If a GPIO line has changed state for a sufficient number of samples, you have your button event and can act on it.
If you are using a tasking OS, you could hook the existing timer interrupt - it's only a few instructions to handle the GPIO poll so you should not see any noticeable performace hit. If is is decided that the button/s have been pressed/released, you can signal a semaphore so that a waiting thread can quickly process the event.
Hi guys I find the solution what I just wanted is here:
https://developer.ridgerun.com/wiki/index.php/Gpio-int-test.c
Thank you anyways
Related
I recently started experimenting with I2C-Hardware on my raspberry pi. Following this tutorial Using the I2C interface I already know how to read and set values. However, the program I want to realize needs the current value on a specific address all the time. So, I made a thread and query the value constantly in a never ending loop, which seems primitive to me. Is it possible to get notified in an event-like manner when a value on an I2C-adress changes?
A platform independend solution would also be much welcomed.
I was able to get what I wanted.
I use the following repeater for the I2C-Bus: link and it turns out there is a soldering bridge (LB2) you can set that sets a signal on GPIO17 whenever a value on the I2C-Bus changes since it has last been changed. I can now listen on this events accordingly.
Generally speaking, the I2C bus has no interrupt capability. So with only I2C, all you can do is poll the chip for a certain event to happen or value to change.
Most chips do have an interrupt line (sometimes even more than one) that can be programmed to trigger on certain events. The behavior of this line depends on the chip. Usually it needs to be enabled (using I2C commands) and it needs to be linked to a GPIO input line. For these, interrupt support is available.
TL;DR
I have written a program in C++ to close all "new" programs that start that were not running when my program started. Currently I do this by capturing all PIDs and then constantly checking all registered applications against this list. Those who are not on my list I attempt to close/kill. This is very CPU intensive for such a simple task. Is there a way to receive some sort of windows event so I don't need to have a very active thread?
I found this hook which might do what I need it to do, but it kind of seems geared towards other purposes, not quite what I need.
In a nutshell:
Is there a event I can receive from windows right after/before a process launches?
Ideally you would do this in user-mode and without polling and the only thing I can think of that comes close is WMI events.
A C++ example can be found here. You might also want to read about the differences between __InstanceCreationEvent and Win32_ProcessStartTrace.
Dears, here I have a small program need to do below action/processes sequentially. now I do below in one function, seems not good:)
init user interface, clear EDIT box, Listview; init the buttons status and so on;
power supply my devices;
need 20seconds sleep or timer, because the device need time for startup;
connect with device, read some data from it;
need 3seconds to wait feedback from device;
got reply from device, decode the data and show them on user interface;
...
For now, I just use sleep() in my program, and do the above steps one by one.
Fortunately, know from stackoverflow that my current way is not good, the feedback and user interface update is very slow, and sometimes, the program even freeze, quite stupid.
And some senior guys told me, I should use timer instead of sleep.
So, my question is:
how to use timer in my current program? (just do it like the MSDN say?)
How can I improve it base on above requirement?
Do I need multithread for it?
Sorry for so many questions:)
Indeed I want to get everything better.
Thank you very much in advance.
You don't specify if you are using a specific framework so I am going to assume a windows application using the native windows API directly:
Call SetTimer passing it your window handle (HWND), and the desired timer interval, and NULL for the TimerProc.
Your window procedure will now periodically be posted WM_TIMER message - you can use the ID parameter you passed to SetTimer in the case you have initiated multiple timers - and to eventually KillTimer when you no longer need it.
I am writing a gtk application (in C++) to communicate with motor controller through serial port. I am working with Linux Ubuntu and termios lib.
I need advice on the best solution to do it.
So here are the constraints I have:
1- when i send a request, the controler send me back a message
2- the controler can send me error notification at any time if an error occurs
3- request is ANSII characters string finished with [CR]
4- controller answer is ANSII characters string finished with [CR][NL]
Because of (3) and (4), I thought it was appropriate to configure serial port in CANONICAL mode.
Because of the GUI + (2), I thought about multi-threading: a main thread who write user request on serial port and an other infinite thread to read controller answer. Do you think it is a good idea?
Second question: if I am using multi-threading I want to be able to write data when I need it so I have to find a way to stop/sleep the reading thread during writing maybe with pthread_cond_wait. Am I right? I've seen poll and select functions but I don't really understand them and I am not sure they are compatible with canonical mode.
I am getting started with multi-threading and serial port. I read lots of things on google, forum...but the large amount of information is a little overwhelming for a beginner.
Thank you for your help.
The main thing to consider here for separating the GUI from the serial port is going to be your delays. Are you ever going to be performing any actions that will cause you to need to poll the port for a specific amount of time that would be noticeable to the user? If you are just doing request/reply and the latency of those is really low your user probably wouldn't notice any of those delays. Additionally receiving those asynchronous error messages would also not cause any sort of noticeable delay I would imagine. Unless you know for a fact that there could be numerous seconds of delay after an Init message or something like that gets sent to the controller it will probably make your life much simpler to keep the application single threaded.
On the other hand if there will be those large latencies or you just want to mess around with multi thread I would just start with 1 thread that does all the GUI work and another thread that handles all the serial IO. Use message passing or event notification between those two threads for coordinating your activities and it should be pretty straight forward.
I'm building scrobbler, and I want my program to wait 10 seconds after song change, before scrobbling. I have been using sleep but I realized that if song change during these 10 seconds, program submit old song and get new one. I want If I change song, code start all over again.
I'm using Music Player Daemon (MPD) and libmpd to get songs' tags.
Note: program is under Unix.
It depens a lot on how your program works, but in principle, the easiest way would be to keep using sleep and check whether the user changed the song before sending out that data (after sleep has returned). So, instead of "try to sleep better", the goal would be "check that the data you send is really valid before sending".
A different possibility would be to wait on an epoll using either the timeout for sleeping or better yet on a timerfd, and notify song change via an eventfd. This has the advantage that it is "free" if you need reliable inter-thread communication and readiness notification anyway, which you most probably do (obviously you must have at least one additional GUI thread, or the user would not be able to change songs while you're blocking).
Damon's suggestion is a good one and may be a better overall design. If you're looking for something quick though, you could consider simply sending a signal to your application when the song changes. That will interrupt the sleep() system call and cause it to return early. Your application would then just need to handle the early return as appropriate. Depending on your implementation, this may not be appropriate but it might give you a quick fix.