wouter van ooijen wrote:

>> I think that the software used to upload a parameter to such an
>> expensive device should have a bit more safety built in, so that it is
>> /really/ difficult to write to a wrong location. An operator should not
>> have to enter any addresses manually at all. This is considered bad
>> design on devices that cost $200...  
> 
> In the end the operator must always specify (and address, or a name, or
> whatever) and he can do that wrong. With this kind of equipment you want
> to have a full-controll option, and you can't have full control without
> full opportunity for errors...

I strongly disagree. (Come on, Wouter, I really think you know better :)

You have a restricted hardware and firmware in the device. You have an
assembler or compiler that created that firmware. You used labels or
variables for the memory locations, with descriptive names and comments
that have an even better description. The linker created a memory map with
the addresses of these labels or variables. Something like this.

Now you say the best one can do is to take a printout of the map file and
enter the raw memory addresses manually when you want to send something to
the device? I'm almost certain that you would do better.

In the simplest form, you create a map between human-readable parameter
names and their address ranges and write a standard GUI application where
the operator fills in clearly labeled fields. Or you have a command line
application that checks the address input against this map, prompts the
user with the human-readable name (and rejects address ranges that don't
match any of the defined ranges) and allows the user to proceed or cancel.

In a more elaborate form, this address map used by the software can be
automatically derived from the original firmware sources and the linker
map. You can derive the variable name, and its description in the
associated comment, and its address from the associated linker map. The
software used to upload parameters can be as elaborate as needed (range and
consistency checking, link the parameter values to a simulator and simulate
them before uploading, etc.); the hardware restrictions of the target
device are completely irrelevant here. When entering a parameter, the
operator does not enter an address range, she selects from a list of
sufficiently descriptive parameter names. It's not even possible to enter
an address range that overwrites other parameters. It's still possible to
select a wrong parameter, of course, but IMO this is much more unlikely
than it is to make a typo in the address range.

I can't imagine that we need to discuss whether it's more error prone to
enter an address range of "6A32F-6A337" or to select a field "sun ray
vertical friction" when addressing a parameter value. Of course you can say
that the underlying memory map may be wrong. It may be, of course. But it
may be generated from the source code and linker map, and after this it may
be checked by a dozen independent reviewers. With that, it's reasonably
certain that it is correct (in any case more so than the address range
that's entered manually by the operator and not checked by anybody else).
>From that point on, operator errors due to entering the wrong address range
are much more difficult to occur.

(This all doesn't preclude that you have an override option that allows an
operator to in fact enter a raw target address, for unforeseen emergencies.
But this is not needed in normal operation, and should only be used with
the utmost care and double or triple checking the entered values.)

This sort of low-level control you are talking about is not normally
needed. I use it sometimes, as I'm sure we all do on occasion, especially
during debugging, because all the effort to create the comfortable access
software is not warranted. But that's during debugging, and I'm on a tight
budget usually. I would never (well, I think... "never say never" :)
deliver a device to a user (and may it be a space device operator) that
requires entering raw addresses for changing parameters. Such a space
device should have the budget for a decent software for parameter upload --
in the end, as can be seen, it's cheaper to have it than not :)

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist