12-04-2023 08:44 AM
I've done surprisingly little serial device work in my time. I'm working on a driver for instrument that says the following in the documentation:
Interrupts Reported: None, must be polled for status
Data Update Frequency: Once per second
Maximum Polling Frequency: One command every 200 msec
My initial interpretation is that I can write a status query command (or any other command), immediately read serial for the response (it returns quickly), and all is good as long as I don't write another command/query until after 200ms have elapsed since my prior write. That being said, internally the device won't actually change its status (thus the data I receive may not be changed) if this were to occur more than once within the 1 second interval in which the data is updated within the device.
Is that how you guys would interpret that? I'm assuming the "read" operation is not actually requesting information from the device (thus not considered "polling") and is merely reading bits that are already present within the serial buffer memory of the computer/OS. Is that a correct understanding?
Also, since this is a driver and there is some possibility someone other than myself may use it in the future (unlikely but possible), how would you handle a situation where the driver is hit with writes faster than 200ms?
To me these are the options I'm mulling:
1) do nothing other than highlight this aspect in the document, let whatever bad/unpredictable behavior may happen just happen, let developer learn from failure/errors.
2) make the driver writes blocking for 200ms after a write so that it's impossible (could be bad for other parts of the driver users' program, not sure if this would be annoying to someone already perfectly aware of the 200ms limit but I think it would be possible to conditionally make it delay/block based on whether it would violate the 200ms rule).
3) queue commands and release them at 200ms intervals (I don't like this, how big to make the queue, could cause unpredictable behavior, something important like a "stop" command could be significantly delayed).
Any thoughts?
12-04-2023 10:09 AM
1. You have to send a request (ie command) in order to get data from the device.
2. The device can only handle a command/request every 200ms.
3. The rate at which data would update is once per second.
With this information, you could potentially send a request every 200ms, but you would then only see a potential new value every 5 requests.
As far as limiting how often a command/request is sent, this is where a class could be useful. In the private data could be the VISA session for the serial port and a ms tick count for when you sent the last command. In the Write method of the driver, you check that tick count and subtract from the current tick count and wait what is needed for the 200ms to be reached. If the difference was already more than 200, then no wait is required.
12-05-2023 03:26 AM
Is reading serial port considered "polling" a device?
Yes. Any time you ask for status instead of getting an event or interrupt it's polling. (Technically i'd say it's repeatedly asking that's polling)