Nice try, but I don't think your assumptions will hold water. I have been a systems analyst, though we wouldn't know about how the Spyder systems work without having the algorithms to see, or commentary from the system developers.
I'll attempt to demonstrate that my assumptions could hold water quite well. I too have enjoyed a very successful career as a programmer/analyst, although in a quite different field than would be required here. (Manufacturing, production control, etc. on mainframe and mini-computers.)
In a system you have 2 costs: storage and processing. When storage costs more than processing, you recalculate whenever you need to. When processing is more expensive you use storage and retrieve as needed. So far, so good. Excellent, in fact! Your speculation about the system recalculating mileage each time you turn on your Spyder NO, NO, much more often than that. Every 1/10th of a mile, at least. heavily uses both storage and processing - keeping lots of mileage numbers NO. No mileage numbers, just one simple count of total wheel revolutions, as they occur. and adding them up every time you turn on the key. Again, boot-up is not described here, though it would be involved also, of course.
It's also overly complex, when all the system really has to do is store three numbers: the last odometer reading, and the Trip A and Trip B totals. This is where I believe your analysis isn't thorough enough: first the system needn't store "odometer" readings at all; this is what I say is too expensive. To do so would require computing them from the wheel-counter each time that counter increments. For an 80-inch tire tread, that counter increments 792 times per mile, which at 60mph would be 792rpm, or 47,520 times each hour. The least expensive thing for the system to be doing this often is to increment and store ONE simple counter (for the life of the machine). All other desired information is converted from this one count. But there is NO NEED to do the conversion every time the counter increments. This is what I say is an unnecessary burden on Miss Nanny, because such information is not needed with every wheel turn. It's only needed every 79.2 turns, at the event of having covered .1 linear mile. How would it know when .1 mile has been covered? This could be incorporated in the much higher-priority task that updates the speedometer display, that is also being driven by the wheel-count function, compared against elapsed time. There would be an algorithm in that routine to indicate when to invoke the odometer display task, which would within itself reset the event-indicator used by the speedometer task.
(Even though the odometer doesn't display tenths of miles, the system has to keep track of it to know when to incrementally increase the display.) No processing is needed except to retrieve those three pieces of data and put them in the appropriate area of the display.
As to prioritization of the ongoing addition of miles to the trip counters and odometer, I doubt that is necessary. The same input (not sure of this, but maybe number of rotations of the rear tire) go into a trigger to advance the three data fields. and a simple "add .1 mile" isn't that complex of a process. In fact, the same .1 mile increment probably goes into the odometer total, but it doesn't display an increase until it occurs 10 times.
:thumbup:
hyea:
