Using FPU_SPI_Driver with GPS_IO_Mini

Kschulz

I am having issues with running both the uM-FPU 3.1.2 and a serial input from a gps. I am using the SPI driver for the FPU and GPS_IO_Mini for the GPS input. GPS_IO_Mini uses fullduplexserial_mini which causes the FPU to stop functioning. I am running fullduplexserial on a separate cog, so how could this cause the FPU to stop working? Is there some synchronization I am missing?

GPS_IO_Mini functions properly when both GPS_IO_Mini and FPU_SPI_Driver are running, but the FPU_SPI_Driver doesn't function. However, The FPU_SPI_Driver will function properly when GPS_IO_Mini is commented out.

Has anyone ran into this before?

cessnapilot

Kshulz -
Perhaps you are the first to run into that. For the others it helps a lot if you are I bit more specific about the problem. Please give some info about
-What is the task?
-What is the hardware? Is the understanding of that crystal clear? If so than
-What are the concrete and relevant details of the software solution?
·
By the way, you can stop FPU easily, e.g. by sending an unterminated string to it. As far as I know FullDuplexSerial (and descendants) does not send the terminating zero byte. Take care (send it).
·
For me it is interesting to know that if you have a working GPS_IO_Mini object and a functioning FPU than why do you need the other? Both of them can handle GPS data easily.
·
One more question: (please don't be angry with me but I sometime teach EE students in lab practice)·Do··the GPS and FPU·use separate IO lines with the Prop?

Kschulz

Thanks for the Reply. I am working on an Autopilot for an RC airplane. I want to read in GPS data through the propeller chip and calculated the bearing to waypoint using an ATAN2 function on the uM-FPU V3.1 chip. I will also will be doing some other navigation math using the FPU. The section of code I am struggling with is getting both the FPU and GPS input to function at the same time. I attached a JPG of the debug output with both the FPU and GPS code running. You can see that the FPU debug shows nothing but the GPS debug shows the current latitude in ddmm.mmmm. I then commented out the GPS section of code without changing any of the FPU code and the FPU calculation works as seen on the second JPG file. The problem is, I cant get both to work at the same time.

As you stated in your reply, I could use the FPU to receive the GPS data and pass it to the propeller. I haven't tried this mainly because it seems more difficult to code and I am still a novice at spin. As a learing experience would like to figure out why the two inputs won't function at the same time. The final program will be reading serial data from an A/D converter for acc/gyro so I will probably have the same issue.

Your question about the input line is very valid. I have the GPS on pin 8 and the FPU is on 3, 4, 5

Any help greatly appreciated...

shanghai_fool

Amazing,

I am working on exactly the same thing.
So far everything is working except I am having trouble with the ATAN2 function also. (for getting bearing to target).
The distance part, I just basically copied from the GCDistance.fpu file

I'm not sure why you should be having trouble with the ports EXCEPT, I did have a problem with the SERIN port connected to a second USB port on the pc. I did have to change the
_Read_Setup_Delay long 14_400
in the FPU driver when using trace or debug. 15us is too short for reading string.

Let me know if you get the bearing formula worked out.

Post Edited (shanghai_fool) : 12/1/2008 6:08:38 AM GMT

shanghai_fool

Finally got it to work via brute force. Made some temp registers so I could check intermediate results with Excel. Still have to add 360° and then modulo 360. Close tho.

shanghai_fool

I thoughht everything was working but when I compared it with GoogleEarth, my bearing reading doesn't look right. I'm not a math person so I'm not sure of the formula.

More work tomorrow.

cessnapilot

Kshultz -
Yes I see the problem, and I see some problems in the code, too. (And that's good. For me the real problems begin when I have a "prefect" code but the program doesn't work.)
In the Autopilot 09 v4 test.spin:
-You call the FPU.ReadRaAsString with the argument 128 for the format byte. That’s probably not a valid value. 12 digits and 8 decimals (I guess) when the maximum digits is 9. FPU might translate it as zero because only the sign bit is one. Use zero instead to be sure.
-It's maybe a minor issue but FSET0 command is a single byte one and does not need a following zero. So, instead of calling FPU.WriteCmdByte(FPU#_FSET0,0) use FPU.WriteCmd(FPU#_FSET0). Zero is a NOP but one never knows...
I am going to reassemble my Prop/GPS/FPU combination to replicate the hardware you described (and those of shanghai_fool's) to allow a better check. That will take few days.

Kschulz

CessnaPilot -
Thanks so much for trying it out for me.· I will make those changes you sugested.··I am interested to hear about what you find out.

shanghai_fool -
How are you getting your GPS data into the propeller?· Are you going through the FPU chip?

Kschulz

shanghai_fool

Hi Kschulz,
Currently I am using "FullDuplexSerialPlus". I plan to bring it in directly to the FPU after I have finished verifying all the instructions. I did set up the demo GC and GPS programs to check out the operation and to verify they would work with my 57600 baud 5 Hz. GPS. Right now, since I am learning both the Propeller and uM-FPU, I am taking this one step at a time. Having the FPU Serin available for debug purposes has been great once I figured out how to use it. I use a temporary repeat instructiion after the FPU code I want to test. This effectively "stops" the propeller so I can examine the FPU registers to see if what I think I am doing is what is really happening.

I am hoping the FPU can handle the GPS directly and still have time left for handling the Kalman filter floating point so I don't have to use another cog for that application. I think I will combine the FPU.spin with the GPS stuff to speed things up. It can stuff data into core memory so that other objects can use it, I hope. If not, I can just call the FPU/GPS object for the addresses.

Keep us informed with your progress since we are doing the same things. Maybe we can help each other.
Cessnapilot is the person that wrote the FPU routines and he knows the FPU. He is a valuable resource for this project. I'm not sure why there aren't more people using the FPU to do high speed floating point. Since it also has a couple of 12 bit A/D pins as well, it could be the only external device needed for some projects.
I use "PC_Interface" driver for my terminal program at the moment as it gives about the same size screen as the MAX7456 so I can see the screen coverage for FPV (First Person view) inside the model aircraft. The data presented to the pilot is not necessarily what you send to the ground or to an SD data file.
For instance, the pilot doesn't need the Lat/Long data on display but he needs to know his altititude and how far away the plane is and which direction it is traveling. I plan on using compass/arrow type graphics to show direction/distance to home and to preprogrammed "waypoints". If the data is also being transmitted to the ground, then a second person can track the plane real-time on GoogleEarth laptop.

Now, I have to go troubleshoot my bearing routine after my second cup of coffee.

Donald

Kschulz

Shanghai_fool,

This is another basic question, but I need to eliminate a variable before I try using the FPU to get GPS data.· I am reading on the micromegacorp website that an rs-232 converter is required to interface the FPU chip with a GPS.· I have succefully ran my GPS straight into the propeller (with a small resistor) to get the data.· Is the input on the FPU chip any diffrent from an input on the Propeller?· I am thinking that the output of my GPS is already formated to work with the FPU chip withoutht the rs-232 converter; is this correct?· My gps has an output that will connect dirrectly to a PC serial port·(DB-9 connector).

Mike Green

If you use the GPS output designed to connect to a PC serial port (DB-9) and connect that directly to either a Propeller or the FPU chip, you will damage the chip. A serial port has voltages that can go from -3V to -15V up to +3V to +15V. You need either a MAX232 type RS232 to logic converter or, in the case of the Propeller (and maybe the FPU chip), you can get away with using a series resistor to limit the current to about 500uA. A 33K resistor should work.

Kschulz

Thanks for the help. Good to know it is just a voltage issue. I will try just the resistor.

Karl

Kschulz

I tried using the FPU to receive the GPS data and I can't get it to work. I used the basic stamp code on the micromega site as an algorithm but something is causing the status byte to show as $82 but I think it should be $80. There is a wait command in the basic stamp program that is used when getting the status byte which I assumed is not necessary using the propeller FPU driver but could be wrong. Any help would be greatly appreciated.

Karl

shanghai_fool

Yes, the status byte should be $80. Notice that "SERIN,6" is in a loop until it gets the $80. And my get status routine does have a wait. The complete file is in my previous "files.zip"

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000
IS_ZERO        = $81  ' positive zero
IS_NZERO       = $83  ' negative zero
IS_NEGATIVE    = $82  ' negative
PRI ReadGPS     |temp
  FPU.WriteCmd2Bytes (_SEROUT,0,5) '; set baud rate to 4800
  Dbg.Str(string(" Baud rate set.. ",13))
  FPU.WriteCmdByte(_SERIN,4) '; enable NMEA serial input
  Dbg.Str(string(" NMEA enabled.. Waiting for input. ",13))
  repeat
    statusbyte := 0
    repeat while statusbyte <> $80
      FPU.WriteCmdByte(_SERIN,6) '; get gps string to string buffer
      read_status
    fpu_wait
    FPU.WriteCmd(_READSEL)
    strPtr := FPU.ReadStr
    Dbg.Str(strPtr)
    FPU.WriteCmdStr(_STRCMP,@G1)
    read_status
    if statusbyte == IS_ZERO

        dbg.str(string(" Lat = "))
        FPU.WriteCmdByte(_SELECTA, 1)
        FPU.WriteCmdByte(_STRFIELD, 4)
        FPU.WriteCmd(_READSEL)
        strPtr := FPU.ReadStr
        Dbg.Str(strPtr)
        dbg.str(string(" Long = "))
        FPU.WriteCmdByte(_SELECTA, 1)
        FPU.WriteCmdByte(_STRFIELD, 6)
        FPU.WriteCmd(_READSEL)
        Dbg.Str(FPU.ReadStr)
 
{ More code here
.
.
.
.
}
PRI read_status | temp
    fpu_wait
    FPU.WriteCmd(_READSTAT)
 
 
DAT
G1      byte  "GPRMC", 0
G2      byte  "Degrees"
statusbyte    byte      0

 

Jim Patek

I have successfully gotten the FPU to read the GPS, parse out the lat and long, convert them to decimal degrees, and am part of the way through converting the decimal lats and longs to UTM northings and eastings utilizing user defined functions on the FPU itself. It is mostly the code from the CGdistance.fpu with the addition of a boatload of register definitions for the UTM conversion. Right now I am debugging the the rather long and convoluted equations for the UTM conversion and have a bug about a third of the way through. This is looking promising though. Have either of you discovered a way to retrieve floating point numbers that gets around the ridiculous 9 digit limit ? It is very difficult to debug the UTM conversions when the problems are occurring at more than 9 significant digits (8 if the number is negative). I have thought about converting the floating point to Long integers (and moving the decimal accordingly) to see if I can retrieve Long Integers, but haven't gotten to that yet. Oh, yeah ... the GPS is hooked directly to the FPU ... of course, mine is only running at 1 Hz and, at least for now, 4800 bps.

Jim

Mike Green

The uM-FPU is a 32-bit processor that handles 32-bit single precision IEEE floating point format which provides for about 7 digits of accuracy. You can't even get 9 digits of accuracy, let alone more. Using 32-bit integers will give you another 2 to 3 digits of accuracy. If you need more, you'll need to do your own multiple precision arithmetic.

Jim Patek

Correct, I should have said 9 character limit. It is difficult to get all 7 significant digits of the 23 bit mantissa plus the sign bit and the 8 bit exponent into a 9 character string.

Kschulz

I see how the status byte works now, the FPU_wait command is still a bit puzzling though.· Dose the FPU_wait command delay the sending of the next FPU instruction to prevent interruption of the serial input?
·
Jim,
What is the advantage of using UTM coordinates?
·
Karl
·

Jim Patek

Well, UTMs are basically Cartesian coordinates and the math to navigate in a Cartesian world is simple. However, I have begun to wonder whether it might not be simpler to program the math to navigate in polar coordinates. Or,given the distances over which my robots have to navigate, just assume that lats and longs are effectively orthogonal. I haven't actually decided, but would prefer the UTM route. There are many other Cartesian coordinate systems that could be used as well, State Plane for example. All, however require transformation.

Jim

H2O2

Hi, Kschultz!

I saw that you are using the GPS_mini.spin code.
I have found some glitches in that code, which I hopefully corrected.

The main problem is that you have to inhibit the possibility of retrieving the pointers to the various NMEA fields when the copy_buffer object is running. You may otherwise, sooner or later, end up with a field with only nulls.

//G