is there a problem on this simple code

[John Machin]

jrlen balane *TOP-POSTED*:
> On 12 Mar 2005 07:39:31 -0800, Harlin Seritt <harlinseritt at yahoo.com>
wrote:
> > hah, this code is anything but simple...
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
> @sir harlin
> so you are saying that there is nothing wrong in this simple program.

No, he is saying that it is not simple IHHO. Neither are your
explanations IMHO. What does "(enthought ed.)" mean??

Some observations:

The variable message_no is set to 1 initially, but thereafter is set to
the message_no returned from the hardware -- 168 the first time. This
is at best very confusing. I'd suggest two separate variables,
to_hw_msg_no and from_hw_msg_no. Does the hardware reject a message
with a number that is not ((previous msg no + 1) % 256)?

You have a similar problem with "command"; initially 67 but then is set
to what comes back from the hardware i.e. 70. Again confusing, maybe
wrong, use 2 variables to_hw_command and from_hw_command.

Some suggestions:

(1) read the manual for the hardware interface

(2) look at all the variables you have; what are they for? E.g. "hexed"
is computed but never used. Clean out the irrelevant stuff and it may
become simple enough for delicate folk like Harlin to be able to read
it :-)

(3) are you sure you have the check-sum right? Using a hard-coded 0x46
(= 67 + 1 + 2) is dangerous! Recall command was 67 but then changes to
70! What does the manual say happens if the check-sum fails? It would
be sensible to compute the check-sum from the *ACTUAL* data that is
being sent: check_sum = 256 - (to_hw_command + to_hw_msg_no +
total_data + data_lo + data_hi) & 0xff -- but see next point.

(4) If the program is going to become more complicated, you should get
some structure into it. For example a function
bytes_to_hardware(command, msg_no, list_or_tuple_of_ints) would be a
good idea -- it would compute the data-length and the check_sum and do
the struct.pack(), ONCE.

Then you could have another function (say)
!def item_to_hardware(command, msg_no, item):
!    bytes_to_hardware(command, msg_no, divmod(1tem, 256))

(5) Not only are the data values not changing, they appear to be all
zero; what does this mean?

(6) You are not validating the checksum coming back from the hardware;
the values printed out appear to be OK -- that is, they sum to zero
modulo 256; check the manual to see if this is the correct expectation!
-- but the point of having a CHECKsum is that you should CHECK it. It
may not be OK tomorrow.

(7) What does command=70 coming back from the hardware mean? Are there
"commands" that mean (a) invalid command received (b) failure in
message_number protocol (c) check_sum error in received message? If so,
augment your program to check for these. If not, or the h/w doesn't
respond appropriately when you send it a bad message, drop it down the
great white chute in your bathroom :-)