Ok, how did you get blank lines in your posts? Perhaps this is a Safari thing (darn macs).
Having said that, let me add that I am also very much interested in the point jywilson is making. This is a pretty neat looking product, that might interface better to my current distributed robot brain written in .NET. However, my current design has a class that accepts read requests from different brain components. The method called for a read request includes the sensor, and a boolean to indicate whether a new read is required. If this boolean is false, then the sensor class returns checks the time of the last reading against the current time, and if too much time has elapsed, it reads the sensor again. If the elapsed time is not too great, then it just sends the currently stored data. If the boolean is True, then the sensor is read, regardless of how recent the recorded data is.
Basically, this allows the sensor reading to go stale over time. While it is still fresh, it can be used, but once it has gone stale, a new read is required. This is a good system, since there are three pairs of SRF08 sensors (which will go stale quickly, but take a LONG time to read), 16 touch sensors, wich rarely go stale, a compass which need not be read all that often, etc.
I don't want to clog the communication with the board with a bunch or needless reads of the touch sensors, or the compass. Instead, I want to keep it open for the SRF08 pairs.
Jim,
Yes, that does make sense. I figured it would be easier for customers to not have to wait on the sensory response. :) I guess it is easier, but less useful.
I should be able to make a few changes to allow customers to choose the desired behavior. They could either have the properties updated automatically, or they could wait on a round trip time. There's already an internal interface in the .NET lib to send a command, and wait on the response. I could just expose it's interface via each object in the .NET lib. Some properties/values, didn't really need to get updated periodically (such as Serializer.GetFirmwareVersion), hence the reason the send command/wait on response interface was added.
Also, like Shaggy pointed out, it would reduce the amount of serial bandwidth being utilized by unneeded requests. BTW, Shaggy, do you have a dog named Scooby? Sorry, I had to ask. LoL
This seems like a reasonable request to me, so I'll add in the functionality once we return from Maker Faire. :)
We're adding a new interface to the Serializer .NET library to allow you to achieve the ability to explicitly query a component as needed, as has been discussed above.
All you will have to do is:
Each queryable Serializer component inherits this interface, and you can enable/disable each component as needed. You can poll some, you can explicitly query some, or whatever you like.
If you want to reenable polling, then just set the Enabled property to true.
We should have the updated library on the site around 6/5/07.
This is most cool, and this will be a great feature when it is released. I do have a few thoughts, however, on how the interface was modified...
1. Disable polling of the object of interest (e.g. irSensor.Enabled = false;)
I hate to overaload the use of this attribute in this manner, especially when it may be of use later to actually power down a sensor. Why not define this attribute to indicate that the sensor will be queried if set to true, or ignored if set to false, regardless of the methods called. This would essentially leave the attribute unchanged. If the UpdateFrequency was set to 0 *and* the sensor was enabled (Enabled = true) this would cause a manual update to occur. See below for more comments on the manual update process.
2. Invoke the new Update() interface, which will query the component, obtain the returned value, and (internnally) store the value in the appropriate property. (e.g. irSensor.Update();)
3. You can then read the value of the updated property and use it as needed (e.g. localValue = irSensor.Distance;)
I would suggest that simply reading the Distance attribute (or other applicable attributes for other sensor types) should cause the manual reading of the sensor value if the UpdateFrequency was already set to 0 and the Enabled attribute was set to true. If the UpdateFrequency was above zero then reading the Distance attribute would simply return the value last read from the automatic update, just as it does today.
The advantage of this approach is that you keep the number of function calls required to just the one implicit in the Distance attribute, rather than the two required for Update() followed by the Distance attribute. I would rarely query the Distance attribute without first calling Update, so why not just make it happen automatically. This also has the added advantage of being true to the existing interface design, with no additional methods required.
James Y. Wilson http://www.learningce.com Fortudine Vincimus!