Go to Post Whether or not you use wheel weights, if you're running a wheel at several thousand RPM, you'd better have an effective containment system to protect the outside world in case something spontaneously disassembles itself. - Alan Anderson [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
 
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 08-02-2005, 22:08
Workaphobia Workaphobia is offline
Registered User
AKA: Jon
FRC #1546 (Chaos Inc.)
Team Role: Alumni
 
Join Date: Jan 2005
Rookie Year: 2005
Location: Long Island
Posts: 26
Workaphobia will become famous soon enough
Re: Negative numbers?

You'll find that it's easier to work with the pwm values if at the beginning of your user code you copy the numbers into a signed char, manipulate those, and then at the end translate that back into the unsigned world. This eliminates all this 127 business, so for example you can simply halve your output by dividing by two.
This would look something like "signed char pwm01S = (signed char)pwm01 - 127;".

In the code you posted, it looks like both sections would have problems. You have to take into account two problems with calculations in programming: overflow and round-off error. Even if you know that the final value must fall within the proper range for the type that is expected, the intermediate values may be too extreme. Two chars multiplied by each other is not that safe - what if they're both 255? You get 65025, and even if you subtract 65000 right after that, you still overflowed and get unpredictable results from that point onward in the formula. The solution is to cast to a larger type - instead of "(p1_y - 127) * (p1_y - 127)" it would be "(int)(p1_y - 127) * (p1_y - 127)". The first term is promoted to an integer before multiplication, and the second value is implicitly promoted as well (at least I think; an integer times a smaller value should yield an integer).

Also, since you have a floating point number, you have to make sure it's treated as a float and not an int or char during calculations, using similar casts. Actually, because the float comes first in the formula, you may be in the clear - everything after it might get promoted to a float. I wouldn't be able to tell you without testing it right in front of my face.

To be safe, you can add in redundant casts all over the place for debug purposes. If that doesn't work, add a printf statement that outputs the values at different stages in the calculation, and find out where the discrepancy lies.



Remember that this is an integer processor, and floating point operations are implemented in software. You'll want to avoid calculations in floats when they can be performed using simpler types.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Field Elements errors in part numbers Mike Martus Kit & Additional Hardware 0 08-01-2005 19:05
Pneumatic Part Numbers CyberWolf_22 Pneumatics 3 01-10-2004 11:19
A couple of noodle scratchers Cheese Head Programming 11 07-12-2002 09:59
Even more interesting numbers: Division of regional winners archiver 2001 8 24-06-2002 03:10
More interesting numbers...specific to big-ball matches archiver 2001 13 24-06-2002 02:51


All times are GMT -5. The time now is 07:09.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi