I am learning some embedded programming. I am using Linux as my platform and I want to create a daemon program that will check if a particular device(magstrife, keypad, etc) is active. Like for example, my daemon program is running in the background, then when I make a keypress event, my deamon app will do something.
What implementation should I do to create this app? And how can I check the event of the devices?
Thanks.
The most common way is to use poll(2).
There is a text on how to implement it. You will need to implement open(2) as well.
Related
I have a separate process and GUI for my application. Details below. Now I am ready to bring the application "in production". Although there are likely only 2 users on this planet I want to handle the startup of the application correctly. That is, adhering to the correct Unix philosophy. Although the application might be able to run in Windows, I am not interested.
I think I have 2 options:
Starting both the player process and the GUI from their own init.d scripts. And have a third script to call both. Usually placed in an autostart directory. Or just have both the process and the gui startup script in the correct rcX.d
Start the player process from an init.d script and fork the GUI from within the process. I could pass parameters to the process to tell whether or not it should start the GUI. This does not preclude starting a GUI process manually elsewhere.
Both options have variations, but the difference between the two is fundamental.
More info on the application
The application is an internet radio player. But with the special feature it can play back previously recorded streams, introducing a time shift to compensate for time differences if the player and transmitter are in different time zones.
The recorder is part of the same project, but not part of the application.
The application consists of the player which is able to play headless, and fully controlled through configuration files. The player can also be controlled by a GUI which communicates with the player through TCP/IP. The application gracefully handles if the player runs without GUI a single GUI, or with multiple GUI's. The GUI gracefully handles the absence or re-connection of the player.
If the player runs headless I want to connect from any PC with a GUI. In some situations I want to use the application and GUI on the same laptop or PC. The main application is a dedicated RasPI player with touch screen. This RasPI should launch both the player and GUI simultaneously when I start the application. Optionally I can start another GUI from another PC to control settings I cannot access thru the touch screen.
I don't think it is relevant, but both parts are written in Tcl/Tk. The player has an extension which interfaces to the libmpv API, part of the mpv media player.
So the player and the GUI are so far independent nothing breaks if one runs without the other, and recover gracefully when they both run. The question is how to start both processes. Independent init.d scripts or forking.
Assuming both the player and the GUI are implemented as Tcl scripts, you can use the source command to load one from the other. For example, when starting the GUI, it can detect that the player is not running (because the socket connection fails). In that case it can do source player.tcl. To avoid name conflicts you can use different namespaces, or load the player in a separate interpreter. I don't expect either of the components to do any blocking actions. But if they do, you can even load the player in an interpreter in another thread.
set dir [file dirname [file normalize [info script]]]
interp create player
player eval [list source [file join $dir player.tcl]]
There are other possibilities for deciding between starting one or both components, like passing a command line option to either of the components to also load the other component.
Since you are specifically interested in linux, another strategy would be to make use of dbus. Your player could publish a dbus interface (using dbif). The GUI can then call a method of that interface, with the "-autostart" option on (the default). When set up correctly, that would cause the player to start, if it isn't already running.
In player.tcl:
package require dbif
dbif connect tk.tcl.mpvplayer
dbif method / Version {} version {return $::version}
You can add more methods, and signals and properties. But since you already have a TCP/IP interface, you don't need to implement a full API via dbus.
In your GUI application:
package require dbus
dbus connect
# Auto-start the player, if necessary
dbus call -dest tk.tcl.mpvplayer / tk.tcl.mpvplayer Version
To enable auto-starting the player, create a file ~/.local/share/dbus-1/services/tk.tcl.mpvplayer.service:
[D-BUS Service]
Name=tk.tcl.mpvplayer
Exec=/home/pi/mpvplayer/player.tcl
The examples above use the session bus, which is normally associated with the display (:0). To make it work when the player runs headless, you may need to set the DISPLAY variable for it to connect to the correct session bus. Alternatively you can use the system bus. But that will require some adjustments.
I have a main QT GUI App running in the embedded linux system. Now I need to create another APP which is to monitor a rotating knob position and send this information to the main QT GUI APP, wo what's the normal way for this two APP communicate?
There are many options, though using a pipe or socket is common. What you're looking for is Interprocess Communication.
QT has an interprocess communication abstraction that you can probably use to do this:
https://doc.qt.io/qt-5/ipc.html
Sorry if I'm using wrong terminology here.
I'd like to make an appliance for users that's running from a Raspberry Pi. When it's booted, I'd like users to see my own GUI that I'll design (hopefully in PyQT but I'm not sure about that yet.)
The thing I don't know how to do: I don't want the users to see the Linux operating system on the screen at all. I don't want them to see the desktop and launch my app. I want my app to be automatically launched on startup. I want it to be the only thing accessible and visible to the users. i.e. it should be full-screen and a user wouldn't be able to exit it or interact with the OS in any way.
How can I do that?
I'm writing a daemon that interfaces with a USB device (an Arduino). This daemon is continuously aware of the current state.
Now I want to be able to interface with this daemon through a client program, also to be written in Perl. This client must be able to query the daemon for its current state and it must be able to update the daemon with settings.
I'm on Linux (x86_64)
I don't want to use an intermediate file and preferably simultaneous queries are easily implemented.
What is the name of such a mechanism? What Perl libraries can I use or should I avoid? What should I DuckDuckGo for?
Probably, you need to implement an event loop to allow doing the tasks of your USB device communication and serve information to the new interface. This concept will change the way you solved the problem, but I think is the better approach.
You can search at CPAN for modules like POE and AnyEvent
The idea is to build an event loop that handles a TCP socket in order to send & receive information from te interface
I've written an application for an embedded linux project, and I want my application to display a particular menu when the user inserts a USB drive. I'm programming the application in C++ with Qt.
My system doesn't have d-bus but it is using udev. It seems to me that udev is the "proper" way to do this detection, but seems complicated.
Can anyone point me in the right direction to get started with this? Is there a way to do it without udev, and if not, is there a good "getting started" guide for udev I could use? I really don't need much functionality, just a way for my application to be notified when a drive is inserted (and enough info for my app to mount the drive).
Thanks
Marlon
The section "libudev - Monitoring Interface" of this document http://www.signal11.us/oss/udev/
should get you started.
Instead of a while(1) loop and a sleep, just make a function with that stuff and then set up a periodic Qt timer to call it every half second or whatever.