Hey All, So I'm about as new as it gets to kernel/device level programming, but far from new to application programming/coding in general. I've recently created some components which communicate via serial port to a host computer (server). These components are used to control a bunch of inter-connected devices for home automation; lighting/dimming packs, HVAC, security, etc - via simple commands relayed from the serial port of the server. The server runs a local instance of memcached, instantiating and copying a local fixed array and polling the memcached server comparing the values against an array there, when the values do not match the (different) value is written out the serial port and updated in the local array slot as appropriate. Multiple other sources update the memcached array via the network and that's essentially how the whole system works, (ie: user presses a button on a web-based app, and that app in turn changes the dimmer value associated as a specific slot in the memcached copy of the array). This solution works, but introduced nearly 100% CPU usage as the polling was done in a constant loop, after having added a 20 milli-second delay to the loop it's dropped the CPU usage to nearly 25% - but this still seems very wasteful to me and I can't help but wonder if there is a just plain better way to do this.
What I would like to do, is replace the above scenario with one wherein the program writing to the serial port is always connected and running, but not polling; ideally having some sort of interupt or signal triggered from within memcached when a value is altered. Sort of a 're-sync' request asserting that the program sending data out the serial port should 'loop once'. I'd like to continue with the use of memcached as it provides a simple way for multiple systems to query the values in the array as well, (ie: some devices need not change the data, but only view it; given the latency requirements memcached operates ideally). This trigger should be asynchronous in that it should be fired and forgotten by memcached (by nature of the hardware designed, no error-checking nor receipt would be needed). I'm just not sure where to start? Could someone send me the right RTFM link to start from, or perhaps suggest a better way to look at solving this problem? Ideally any example code to look at with a simple signal or interrupt type of handler would be great. What I'm leaning towards is modifying memcached daemon to send a signal or trigger an interrupt of some sort to tell the other program communicating with the device to re-poll once. It would also be nice to have a way to trigger from other programs too. The device communicating via serial port is essentially a protocol translator to a modified RS422 serial bus, the eventual goal of using a local UART with some modified hardware and changing the device driver to support the communications differences directly in the kernel would be best scenario, so any suggestions leaning towards having the sending program be integrated within the kernel in some way would be even better. I'm not looking for a handout here, just a better understanding of where to start; so any suggestions or referrals to RTFM or source examples would be greatly appreciated. Thanks. -- Nathan Vidican nat...@vidican.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
