jrlen balane *TOP-POSTED*: > On 12 Mar 2005 07:39:31 -0800, Harlin Seritt <[EMAIL PROTECTED]> 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 :-) -- http://mail.python.org/mailman/listinfo/python-list
