uMFPUV2 math co-processor, data conversion problems

TimN

For the project i am working on, i need to use a uMFPUV2 math co-processor. but, currently, i can only read data from it in zero-terminated string format. but i later need to be able to view that data as a decimal instead of a string. I used the sample program included in the co-processor documentation for BS2 series microcontrollers to base my program off of, just to let you know as background in case that might help anyone answer my question, which is: does anyone have any suggestions as to how i can either read the data from the co-processor in a format that can be convertered to decimal, or know of a way to convert string data from the co-processor to decimal form?

Mike Green

The Stamp processors only handle 16 bit integers. If you want some result from the uMFPUV2 in a form that you can use numerically, don't convert the final floating point value to ASCII. Convert it to an integer value less than 65536, then do a FIX and READWORD operation with the uMFPUV2. Obviously, if the value is not from 0 to 65535, you will have to somehow reduce it to that range for the Stamp to be able to do arithmetic on it. If you only want to display it, you could store the ASCII characters in the Stamp for later display, but you wouldn't do calculations on it.

TimN

would that work even if the number being sent from the co-processor over to the basic stamp is not an integer? and if that would work, what would be the coding for that?

Mike Green

Again, the Stamp can only handle 16 bit integers. It can store other things, but not directly manipulate them. For example, if you had a 32 bit integer in the uMFPUV2, you could transfer it to the Stamp which could hold it as two 16 bit integers, but not directly manipulate it as a 32 bit integer (strictly speaking, you could do 32 bit arithmetic on the Stamp, but it would be slow and awkward). You could theoretically store the ASCII strings and do floating point arithmetic on them using the Stamp, but it would be exceedingly slow and complex. I wouldn't recommend it.

On the other hand, you could take a value from 0.000 to 9.999 and represent it on the Stamp as an integer from 0 to 9999 and easily do fixed point arithmetic on it. For example, you could take a value of 0.628 and multiply it by 2.3. On the Stamp, you would represent this as 628 (an integer) and 23 (another integer). You would multiply them and scale the result back to 3 decimals as 628*23/10. If you were displaying the results from the Stamp, you could insert the decimal point character on output in a routine that would check for the number of significant digits, add leading zeros, etc.

TimN

ok. what would be the coding to be able to bring the data from the coproccessor in to the basic stamp in the manner you were describing?

Mike Green

Which example are you referring to?

If it's the last one, you do most of the work on the uMFPUV2. Let's say you had a floating point value ranging from 0.000 to 0.999. You'd multiply it by 1000.0 to change the range to 000.0 to 999.0, then use the FIX operation to convert floating point to integer, then READWORD to read in the two byte value most significant byte first (look in the uMFPUV2 instruction manual for the descriptions of these operations).

There's an example of reading an integer from the uMFPUV2 on page 11 of the tutorial manual. Be sure to specify that you're reading 16 bits into a word variable (look at the SHIFTOUT Stamp command description).

Post Edited (Mike Green) : 10/8/2006 3:44:20 AM GMT

TimN

Thanks alot! maybe i should have added this before, but what i am doing is sending that data from one basic stamp to a second stamp via serial wire connecting the two. when i was sending it as a zero-terminated string, i was not able to read the data correctly on the other stamp. hopefully it won't change anything, but just to be sure, does it?

and to answer your question, the example i was basing my program off of the example program that used the uMFPUV2 to calculate the temperature in farenheit based off of data collected from a DS1620 temperature sensor. the only changes i made were to remove all debug lines of code, add in a SEROUT command to send the data and a prefix HIGH signal to trigger the POLL function in the receiving stamp.

Mike Green

Well, you can send zero-terminated strings from one Stamp to another (and you should make sure that it was received correctly ... that's needed first), but that doesn't mean that the second Stamp can make sense of what you've sent. You can use the ASCII output formatting capability of the uMFPUV2 (FTOA command with format byte of 50) to build an ASCII string with an integer value less than 32768, read it with the READSTR command and send it to the other Stamp. The second Stamp should be able to read it in using the DEC formatter in the SERIN command because it's an integer value.

TimN

i tried your suggestions and they did not work, and i noticed that the problems that arose were the same as before... as a question, what is the actual syntax for the FIX command? also, the problem with the stamp being acle to read it with the DEC format is that the number coming out of the co-processor is a decimal, and if i were to change it to an integer somehow, it would be a word, and i have had the same problems with that

Mike Green

Please post your code (at least the portion having to do with this discussion), a simple diagram or detailed description of how the Stamps are connected, and what you're receiving at the 2nd Stamp (the actual characters).

What problems have you had before with trying to read a word from the co-processor? What was the actual code you used? Please look at the examples in the tutorial for the use of FIX and READBYTE. READWORD is similar, just transfers two bytes.

What is the range of values you want to transfer? You might be able to transmit the string from the co-processor with the decimal point and do the conversion to a fixed point value at the 2nd Stamp by using the decimal point just as punctuation. For example, if you had values with 2 decimal places always and they were from 0.00 to 250.00, you could use a SERIN statement like "SERIN pin,Baud,[noparse][[/noparse]DEC first,DEC second]" followed by "result = first * 100 + second". This would give an integer from 0 to 25000 which would represent your fixed point value.

TimN

the part from the stamp running the co-processor is as follows: "Main:
LOW 6
GOSUB Read_DS1620 ' get temperature reading from DS1620

' send rawTemp to uM-FPU
' convert to floating point
' store in register
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [noparse][[/noparse]DegC, LOADWORD, rawTemp\16, FSET]
' divide by 2 to get degrees Celsius
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [noparse][[/noparse]LOADBYTE, 2, FDIV]
' degF = degC * 1.8 + 32
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [noparse][[/noparse]DegF, FSET+DegC, ATOF, "1.8", 0, FMUL]
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [noparse][[/noparse]DegF, FSET+DegF, LOADBYTE, 32, FADD]
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [noparse][[/noparse]DegF, FSET+DegF, ROUND]
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [noparse][[/noparse]DegF, FSET+DegF, FIX]
SHIFTOUT FpuOut, FpuClk, MSBFIRST, [noparse][[/noparse]DegF]
format = 51
GOSUB Print_FloatFormat
HIGH 6
PAUSE 100
SEROUT 6, 188, [noparse][[/noparse]dataByte]
LOW 6
PAUSE 1900 ' delay, then get the next reading
GOTO Main"

the part receiving the data is: "reciever PIN 10

inches VAR Word
inputtemp VAR Word

SERIN 10, 188, [noparse][[/noparse]DEC3 inputtemp]
DEBUG CRSRXY, 0, 1, "temp input received"
READ 0, Word inches

DEBUG CRSRXY, 0, 3, "distance = ", DEC3 inches
DEBUG CRSRXY, 0, 4, "temp = ", DEC3 inputtemp

RUN 0"

in terms of how the stamps are connected, the sending basic stamp, as you can see, has a wire going from pin 6 to pin 10 on the receiving stamp. i have been able to get this system to work, if both stamps are running the same type of data. so far, all i receive is "255," "048," or "000" depending on where i place the DEC formatter