I am in the early stages of planning for an input device which will consist of some as-yet-to-be determined number pf physical controls. From previous experience with such devices I have found that it would be extremely advantageous to have the device return data about the state of all controls in response to a query from the system, as opposed to reporting changes as they occur.
Assuming an acceptable poll frequency of 1000 queries per second or higher, is the embedded hardware sufficiently advanced to support this? Would a driver for such a device be excessively resource-intensive? What would a good ballpark estimate for the ram/cpu required on both the “server” and “client”?
8
Assuming an acceptable poll frequency of 1000 queries per second or
higher, is the embedded hardware sufficiently advanced to support
this?
The short answer is yes :-). At 1000 queries/second, you have 1 millesecond to receive, handle, and reply to each query. There are several factors to consider. Two of the more important ones are:
- Do I have enough processing instructions to receive, handle and reply to the query. This includes reading the query, parsing the query, reading data from hardware registers, formatting the data for output, sending data, and overhead associated with handling the interrupt.
- Does the I/O channel being used have the bandwidth to carry the data?
You can get reasonably-priced dual core ARM processors on development boards running in the GHz range, which gives you a million instructions every millesecond. With a USB 2.0 interface, you can transfer up to 480K bits (15000 32 bit words) in the same period of time.
Would a driver for such a device be excessively resource-intensive?
No. Assuming a multi-core processor operating > 1 GHz, if your interrupt handling overhead and processing is 20K instructions, you are using ~ 1% of the CPU to handle your interrupts.
What would a good ballpark estimate for the ram/cpu required on both
the “server” and “client”?
The RAM requirements depend on how much your application needs to cache. On the embedded device, you might size your RAM to handle three buffers, one to read information from the physical controls, one to hold the data while it is being formatted for output, and another buffer for the output itself. Each buffer is sized based on the number of bits of information per device.
2