Working with the Micromega uM-FPU V3.1

shanghai_fool · 2008-11-27 03:51

Hello all,

I am fairly new to the Propeller as only having one for about 2 weeks. I have managed to drive several devices with parts of code from the OBEX and now I have come to the FPU which is also new to me. I have some experience with Intel assembly, basic and very little "C". I am still getting used to the subtleties of SPIN and new asm terms. Both seem straight forward.

I have managed to get a couple of the demo routines working with the propeller.

With a great deal of help from I.K

shanghai_fool · 2008-11-28 06:27

Given that most all the newer commercial hand held GPS units give much more information than you get from a simple module, I would like to program the FPU to give the following functions:
1 - Distance and bearing from current position to a fixed position (waypoint)
2 - Current position cross track error from start point to dest point.
3 - Time to waypoint given current (GPS) speed.
I have the formulas but I am not sure where/how to place them in FPU.
There are 2 storage areas. Flash and EEPROM. The flash can only be programed though the SERIN of the FPU. The EEPROM can only be programed through the SPI/I2C (Propeller). The flash has 2k and the EE has 1k.
My plan is to put the Propeller and FPU on PCB and I am not sure of the best method of programing the FPU. Since the FPU routines will be running on its own cog, I could use Beau's idea and possibly split the SERIN to 2 different pins:

PUB SoftwareBuffer
    DIRA[noparse][[/noparse]Bpin1]~~                                       'Make BPin1 an Output
    DIRA[noparse][[/noparse]Bpin2]~~                                       'Make BPin2 an Output
    CTRA :=  %01001 <<26 | Bpin1 <<9 | Apin1            'Setup counter A for POS detector with Feedback mode
    CTRB :=  %01001 <<26 | Bpin2 <<9 | Apin2            'Setup counter B for POS detector with Feedback mode
    FRQA := 1                                           'Start Counter A
    FRQB := 1                                           'Start Counter B

and use a separate method to interface the FPU IDE to a PC for programing the flash. This would require the GPS input on a separate pin. Since I plan on using SMD parts, I cannot preprogram the FPU flash before mounting.

The FPU IDE requires both Rx and Tx but the FPU/GPS only requires FPU Rx. I am open to use a small jumper if necessary for initial programming.

If I use EEPROM, then I could simply interrogate the FPU ID and if not correct, load a method that would program the FPU and then release. A "one time use" routine.

I don't know if this makes sense to anyone but me but I am looking for suggestions on the best method of interfacing the GPS, FPU SERIN and FPU IDE to the Propeller using the fewest pins. For programing the Propeller and FPU, I will have a USB connection to the Propeller. During normal use (not directly connected to PC), I will have the Propeller com pins (30,31) connected to wireless modem. Either Bluetooth for short range, or Xbee for longer range.

My idea is to have the FPU process all necessaary incoming GPS data and store it in specific registers which the Propeller can interrogate as desired. The FPU cog will take care of the timing and FPU instructions and place data into hub memory.

Donald

Jim Patek · 2008-12-02 01:56

Donald

How are you fairing with you efforts on the FPU. I was out of town for several days but have started experimenting with the IDE to program the FPU.
I got the GCdistance.fpu functions to work with no problem. However, at the moment I am only using 4 of the functions:

getID
readNMEA
parseGPRMC
NMEA_Degrees

So when I remove the others:

getDistance
getLocation
getLatLong
radiansToDM

The functions no longer work. Printing the lat1 register (10) returns a value too big to print ... all "******". I have fooled with it for a whil and have checked to make sure the IDE is generating the proper assembly ... calling the correct functions by number, etc. Everything looks like it should be fine, but it doesn't work.

I wanted to remove the functions I am not using to save memory space for the functions I plan to add (lat/Long to UTM conversion, for instance). Looking at the memory map, I probably have sufficient space even leaving the 4 unwanted functions in place. This, however, offends my sense oreder in the universe. Perhaps I'll just have to get over it ... won't be the first time. have you run into oddities like that ?

Jim

shanghai_fool · 2008-12-02 02:19

Hey Jim,

I am still struggling with it. I left the functions intact for the moment and am just trying to do them in spin until I get everything working. Then I plan to put them into the FPU as functions. I have not yet decided whether to use the flash or the eeprom. The flash is only accessable with the IDE and I want to plug the gps in there.

I'm not sure what happens to the function order inside the FPU if you delete some stuff. It looks like there is an internal pointer to where the functions are located but I'm not sure how it works yet. I was looking at the eeprom instructions and the EECALL,fn where fn is the function number but I'm not sure how you arrive at that. When you program the eeprom, the first byte is the length of the function and the last byte has to be a return but it doesn't say anything about function number. I suppose I'll figure it out by T&E as usual with a lot of E.

So, if you delete some functions, then the function numbers will also change. I think they are just numbered sequentually.

Also, check posts on other thread. http://forums.parallax.com/forums/default.aspx?f=25&p=1&m=310133#m310722

Donald

Jim Patek · 2008-12-05 14:55

Donald

I got the FPU to do Lat/Long to UTM conversions, albeit in single precision. So, I have a LL2UTM function for the FPU now, if anyone is interested. It's still a bit crude and I'm still polishing it, but it seems to work. It is still embedded in the GCDistance.fpu and I can't seem to remove the functions I'm not using, so I've some more experimenting to do. A caution about writing user functions for the FPU ... read the manual CAREFULLY! I missed the bit about the fact that the FPU interprets from left to right with NO operator preference ... that can mangle your math if you unaware.

Jim

Working with the Micromega uM-FPU V3.1

Comments