I've been assigned to upgrade an embedded application written in C. The application is configured via a web interface.
When the user modifies the web application a file is written to /var/www/settings.json and the file /var/www/UPDATE_SETTINGS is touched.
In the main application loop it checks to see if UPDATE_SETTINGS exists. If it does it parses the settings.json with json-c and then deletes UPDATE_SETTINGS.
This works well enough, however, we would prefer to move to an event-driven architecture (perhaps libev) in which settings.json is fed directly into the program by the webapp script to a plain-old UDP port and then issue a callback to perform the update.
What are some other elegant ways to solve this problem? Should we just stick with the current approach?
Just use inotify. It was created for cases like yours.
I am making some assumptions here.
1) you are connected to the internet all the time with you embedded device.
2) your device can set up interrupts on things like "USART RX buffer not empty"
note: depending on what kind of hardware you are using you could set up interrupts on things like pings and other stuff this could be another way of interrupting the embedded device.
if those two assumptions are correct you could do this, have another "script" on a server or computer somewhere that watches the /var/www/settings.json for changes you could use something like rsync to watch for changes. this "script" when it notices that the json file changes will communicate to the embedded device using tcp/ip you can either ping the device or just send the file over. If you can set an USART interrupt on the embedded device then the device will be able to detect the data coming in and therefore respond by either reading the data you are sending or going to the website to download the json file to be parsed.
this way you will have an event drive embedded device and it will not waste time checking to see if this json file has changed.
I hope this helps
Related
I have a smart card-like miniSD card (it's a javacard as far as I know) and I'm trying to write an emulator for it that runs on Windows and Linux. The emulator will be used in software integration tests. I want to test my client without using the actual hardware for several reasons. One reason is that the actual hardware will change its state irreversibly and doesn't allow a complete reset.
The device implements a mass storage with FAT32 file system. It contains a special device file that is being used for controlling the device via simple file write/read operations.
My goal is that the virtual (emulated) device appears with drive letter in Windows explorer as soon as the emulator is started, similar as if someone would actually plug a real device.
I wonder if there is any open software project that I can base my program on? The biggest challenges are obviously
Providing/developing a "virtual" (USB/SD) mass storage device
Intercepting file I/O operations on the special device file.
According to Wikipedia, device files are a common way to simplify driver development. So I wondered if there are existing emulation solutions for driver developers. At least I couldn't find any.
Simulating the device file itself would be an important first step. My first idea was to use a normal file and to communicate with the client by actually reading/writing to this file while observing it. I.e. clear the file as soon as the client wrote to it and write the response into it. I don't know if this could work at all. One problem is that the client doesn't open the file with shared mode, so my simulator cannot access it at the same time.
Then I found out that QEMU can emulate mass storage, however it seems that it only supports image files and that probably doesn't allow device file.
Microsoft has some documentation about how to write USB device emulators and drivers but it seems to be very complex and I wondered if there is an exisiting solution that could be extended:
Finally there is the USB/IP Project, but I don't know if it is helpful as I still need to develop a driver and then I'm back at the complex MS documentation above.
I am working on an application that runs on a small Linux computer with an SD card for storage. The application runs automatically on startup and we want to be able to easily check the logs that it produces. Normally I would just write to a file, since that also seems to be what most normal software would do. But I am hesitant about doing this because I think continuously writing logs is a bad idea because of the SD card for storage.
The problem is that sometimes when we want to check what is happening on the system, say for debugging purposes, we have stop the application via SSH and then start it again so that we can see the output messages.
So my question is: is there a way to say write logs to some kind of circular list that can then be viewed when connecting to the system over SSH? The application is written in C and C++ if that matters.
Is your application on a Raspberry Pi?
The Linux Operating system, and all other technology, is probably writing so much to the SD card, that your 500 KB/ hour would be next to nothing in comparison.
I would personally just have the program log to the file.
If you really do not want this, you have a few other options:
Have the application send the logs via the internet to some service, which you can then monitor
have your application store the logs in a buffer in-memory, and then write to file when you reach some threshold. Expose an endpoint on localhost which listens for a message, and when received, writes the in-memory contents to the file. This allows you to see log-files for current in-memory logs without having to wait.
First thing, I think that the SD driver care about writing and about I/O operation scheduling them in the better way for the safety of the SD card itself (using a virtual filesystem). Maybe you can work on your log level to be sure to write the necessary information and nothing more.
Based on shared inputs SD card wear-out might not happen easily, however, there are many ways to handle this scenario based on the hardware and software architecture of your system :
Check if you can write the logs to some other storage device within your system (Depends on your architecture).
If external communication peripherals are available in your system, check if logging can be done by redirecting the logs to remotes servers or other devices.
Perform selective logging based on some log-level as per your architecture / framework. Also, you can do only critical logging in SD card and the other logs can be re-directed based on your architecture. This can reduce the number of writes.
Based on your need/architecture, check if the data can be compressed and logged. This can reduce the number of times, the logs are written to SD card.
To continue working and simultaneously view the logs :
Based on your architecture/need, check if you can write to a file periodically or based on threshold so that you can view the file irrespective of operation.
Send selective logs to external server / device
i want to run 2 different BackgroundTasks - one for the communication with my arduino - and one for the communication with other devices by using a webservice. These tasks should be able to write and read from ONE database. But my problem is, that the Windows.Storage.ApplicationData does not provide the SharedLocalFolder. It is null, if I want to use it. Is there any other way where i can store my database that both BackgroundTask can connect to it?
Additionally I found now this path:(Windows.Storage.ApplicationData.Current.GetPublisherCacheFolder(...)). This look very interesting, but if i want to use it I cant write there. I think, because the resolved file path does not exist..
Any other ideas?
Sincerely,
App2App Communication via WebServer (Blinky WebServer):
You can refer Microsoft's IoT sample provided for Blinky Webserver which also depicts the concept of App2App Communication. But you need to read it thoroughly to modify and reuse it up-to your expectation.
Right now I have no experience about Windows IoT and database. Once I got my hands on it, I'll update.
I have a program (a game, really), which uses a .wad file to store its resources. Is it possible to somehow intercept access to this file, and emulate it?
For instance, I want to dynamically replace some sprites. Instead of creating a new file, is it possible to make this game think it is accessing the .wad, but actually we process its requests?
Under Windows the File System Filter Driver provides a low level I/O hook that a program can register to be passed the I/O requests to the file system.
Filter drivers can also alter the data passed via filters or deny filesystem requests.
Implementation, maintenance and support of your such kernel-mode code is non-trivial.
Anyway you could also take a look at:
Winpooch: an antivirus has to intercept file accesses so an open source antivirus can be a good starting point to study filters.
EasyHook: for Windows API hooking
The user, administrators and support staff need detailed runtime and monitoring information from a daemon developed in C.
In my case these information are e.g.
the current system health, like throughput (MB/s), already written data, ...
the current configuration
I would use JMX in the Java world and the procfs (or sysfs) interface for a kernel module. A log file doesn't seem to be the best way.
What is the best way for such a information interface for a C daemon?
I thought about opening a socket and implementing a bare-metal http or xmlrpc server, but that seems to be overkill. What are alternatives?
You can use a signal handler in your daemon that reacts to, say USR1, and dumps information to the screen/log/net. This way, you can just send the process a USR1 signal whenever you need the info.
You could listen on a UNIX-domain socket, and write regularly write the current status (say once a second) to anyone who connects to it. You don't need to implement a protocol like HTTP or XMLRPC - since the communication will be one-way just regularly write a single line of plain text containing the state.
If you are using a relational database anyway, create another table and fill it with the current status as frequent as necessary. If you don't have a relational database, write the status in a file, and implement some rotation scheme to avoid overwriting a file that somebody reads at that very moment.
Write to a file. Use a file locking protocol to force atomic reads and writes. Anything you agree on will work. There's probably a UUCP locking library floating around that you can use. In a previous life I found one for Linux. I've also implemented it from scratch. It's fairly trivial to do that too.
Check out the lockdev(3) library on Linux. It's for devices, but it may work for plain files too.
I like the socket idea best. There's no need to support HTTP or any RPC protocol. You can create a simple application specific protocol that returns requested information. If the server always returns the same info, then handling incoming requests is trivial, though the trivial approach may cause problems down the line if you ever want to expand on the possible queries. The main reason to use a pre-existing protocol is to leverage existing libraries and tools.
Speaking of leveraging, another option is to use SNMP and access the daemon as a managed component. If you need to query/manage the daemon remotely, this option has its advantages, but otherwise can turn out to be greater overkill than an HTTP server.