[snip]
Well, my immediate concern is CPU cycles, but I'm working on a
low-power device, so I will start to worry about the battery in a few
months when the basics are operational. My immediate concern is that
the CPU is spending significant time servicing the interrupt
(constantly) for a device that I intend to read for a few minutes once
every six hours!
I could try to disable the interrupt for that serial port from the
app, but it defeats the purpose of encapsulating everything in a
device driver.
I think the solution would be a close function for devices:
Cyg_ErrNo cyg_io_close(cyg_io_handle_t handle);
This can halt the device by disabling interrupts, etc. I suppose,
though, that an empty, default implementation that does nothing would
then have to be provided for every driver currently in the repository?
And then that creates the problem of being able to open the device
again after it has been closed. Perhaps the lookup function can just
be called again, but it seems that the device lookup function performs
a "query", "initialize", and "open" function in one call. These could
maybe be split into two or three separate functions?
As you mention, there is also the issue of power-saving modes. Even
the eCos reference manual indicates future modifications:
The lookup() function is called whenever the cyg_io_lookup()
function is called with this device name. The lookup function may
cause the device to come “on line” which would then allow I/O
operations to proceed. Future versions of the I/O system will allow
for other states, including power saving modes, etc.
Devices could offer optional callbacks for power-down and power-up,
like the Linux suspend/resume callbacks. But there would probably need
to be the system-wide power management API to orchestrate the whole
thing. That sounds great, but way beyond what I was thinking at the
moment.