Serial Data 'pass-through'
DarrenY
Posts: 61
If I wanted to merely 'pass-through' GPS NMEA data through the prop could I just set one pin as an input and another as an output and merely just make output := input?
Is there something I am missing?
Is there something I am missing?
Comments
You could possibly use the SERIN and SEROUT commands of the uM-FPU to interface with the NMEA device ( direct or through the Propeller ) but I think you need to explain exactly what you are trying to do and want in a little more detail.
So this may only work for slow signals. I beleive the outputs are updated via the hub which is clocked every 8 clock cycles.
You may have better luck using the CNTA or CNTB hardware.
See AN001 - Propeller Counters· on this page http://www.parallax.com/tabid/442/Default.aspx
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Caught in the PropWash
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"I have always wished that my computer would be as easy to use as my telephone.· My wish has come true.· I no longer know how to use my telephone."
- Bjarne Stroustrup
It has most of what you need to communicate with the FPU. I am currently trying to expand the driver for GPS related commands. Any help appreciated.
I'm not sure this is what you're looking for, but here's a snippet I used to verify that I was getting good data from my GPS. I used the GPS_IO object (by Perry) with some modification. After starting that object:
I used the following code to just pass what was coming into the prop from the GPS to the Prop Serial Term where I could see what it was doing:
OBJ
gps : "GPS_IO" 'no COG required
uarts : "pcFullDuplexSerial4FC" '1 COG for 3 serial ports
PUB Main
Num.Init
uarts.Init
uarts.AddPort(DEBUG,31,30,-1,-1,0,0,57600) 'Add DEBUG port
uarts.AddPort(NMEA,rx_from_nmea,tx_to_nmea,-1,-1,0,%000000,NMEA_BAUD) 'Add GPS NMEA port
Pass_through(NMEA)
PUB Pass_through (port) | Rx_byte
' infinite loop which simply reads from port and spits it to the debug port which should be the PST.
repeat
Rx_byte := uarts.rxcheck(port) ' collect byte from MACM port
if Rx_byte <> -1 ' -1 means no data; don't do anything
' !outa[noparse][[/noparse]CAPTURING]
uarts.putc(debug,Rx_byte)
' uarts.hex(debug,Rx_byte,2)
Let me know if this looks useful but isn't explanatory enough. I can send more. I have to strip out the program that I'm currently working. However it shouldn't be too bad.
good luck,
pgb
The data from the gps is OK as I have watched it on other TTL serial ports. I am just trying to use the capability built-in to the Micromega uFPU v3.1 floating point chip. It would save a cog as I could also use it for float math. It is somewhat working but very intermittent and it seems like sometimes the strings return garbage. It might be a matter of timing. Micromega has published routines for other processors so I may try it on a picaxe to verify the operation and see if there is a timing issue.
The real author of the FPU object code has now joined the forum so maybe we can get some expert help. He has already submitted FPU drivers for several devices and it processes "version" SYNC and clock_ticks correctly every time from the FPU. It is only after I add the commands to start getting data from gps when it fails. There is something there I have not yet understood.
After I have my second cup of coffee this morning, I will try to start a new thread for this subject.
Donald
I have spent the better part of the weekend trying to get the NMEA decode capability of the uFPU v3.1 to work. So far, all I have seen is garbage or nothing at all. The floating point routines in the FPU seem to work fine, so I assume I have the SPI connection set up correctly. Maybe I will try the I2C or try my new copy of ViewPort to see if I can see the signal on the SPI SOUT pin. However, I've run out of week end so it may be a while. Let me know what you find. I'd hate to have to give up on this function.
Jim
I have finally managed to get something. Looking at the picaxe basic program, I see how they use the different commands and check the status byte. Here is the snippet of the routine:
PRI ReadGPS |temp
FPU.WriteCmd2Bytes (FPU#_SEROUT,0,5) '; set baud rate to 4800
Dbg.Str(string(" Baud rate set.. ",13))
FPU.WriteCmdByte(FPU#_SERIN,4) '; enable NMEA serial input
Dbg.Str(string(" NMEA enabled.. Waiting for input. ",13))
repeat
temp := 0
repeat while temp <> $80
FPU.WriteCmdByte(FPU#_SERIN,6) '; get gps string to string buffer
FPU.WriteCmd($F1) ' read status
temp := FPU.ReadByte
FPU.WriteCmd($EC) ' Select string
strPtr := FPU.ReadStr
Dbg.Str(strPtr)
Dbg.Str(string( 13))
'
It returns the NEMA message type except the "$G" is missing. I knew it stripped out the "$" but I am not getting the "G".
I will continue working with it. Maybe I cannot get the entire string at 1 time but that is OK. I will use the FPU to do the calculations anyway. At least there is progress.
Donald
PRI ReadGPS |temp FPU.WriteCmd2Bytes (FPU#_SEROUT,0,5) '; set baud rate to 4800 Dbg.Str(string(" Baud rate set.. ",13)) FPU.WriteCmdByte(FPU#_SERIN,4) '; enable NMEA serial input Dbg.Str(string(" NMEA enabled.. Waiting for input. ",13)) repeat temp := 0 repeat while temp <> $80 FPU.WriteCmdByte(FPU#_SERIN,6) '; get gps string to string buffer FPU.WriteCmd($F1) temp := FPU.ReadByte FPU.WriteCmd($EC) strPtr := FPU.ReadStr Dbg.Str(strPtr) Dbg.Str(string( 13)) '-------------------------------------------------------------------------Sorry, I forgot to do formatted
Jim
I am trying out my new LS20033 GPS @9600 baud but it doesn't work. I was getting the results above with an EM-411.
[color=#000099] FPU.WriteCmdByte(FPU#_SELECTA, 1) FPU.WriteCmdByte(FPU#_STRFIELD, 4) FPU.WriteCmd($EC) strPtr := FPU.ReadStr uarts.Str(0,strPtr) uarts.Str(0,string( 13)) [/color]I looked at the LS20033, but since I am working on robotic boats that move slowly I don't need 5 Hz. I can barely handle 1 Hz.
Jim
The "uarts.Str(0," is there since I'm using the multiple serial driver object. And the preceeding snitted goes at the end of your (shanghai_fool) code.
jim
To your original request... "merely just make output := input?" ... You can implement two software inverters that will act like a buffer. Running at 80MHz, the propagation delay is 50ns.
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▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I think your solution would only work if you did it in its own cog, preferably in asm. Otherwise, you could not do anything else. The solution by Beau is much more preferable as it uses internal hardware built in to each cog and doesn't require any sofware other than setting up the counters. I am going to try that so I can monitor both the raw gps data and the FPU results simultaneously. I'm glad to see that someone is recommending using the timers. I think they are great and intend to put them to good use as pulse width detectors and frequency measurment.
As far as the FPU, I·definitely think there may be a timing issue with my code. It works fine on the 1Hz EM-411 at 4800 baud but does not work with the 5 Hz. LS20033 @57600 baud.
I am only getting the previous "Version..." string returned. It looks like it has not had time to process the command.
I will have to work on this more.
I would also like to be able to "pass through" the gps data stream using the SERIN,1 and SERIN,3 but have not been able to make that work yet. There is too much I do not understand about the FPU.
You should be able to offload a lot of functions that deal with the gps data as these functions can be preloaded into the FPU.
Data3.zip is EM-144, Data4.zip is LS20033. As you can see, the updates are 200ms apart.
The FPU application notes are also attached.
I really like Beau's method, i'll give it a try.
You should use the FPU.WriteCmdStr(...) procedure instead of the FPU.WriteCmdByte(...). The later one writes only 1 byte after the Cmd byte. Usually no terminating zero is transmitted in this case (depending on the address of your string) and that might even cause a hang up.
It is recommended to use the "FPU.Wait" procedure before each(!) "FPU.Read..."·command, although not always necessary. In your code, however, where long NMEA strings are copied from here to there within the FPU, the FPU.Wait is definitely missing.
Actually, the Propeller / FPU / GPS / Emic Text-To-Speech combination was the first successful trial for me to use the Prop with the FPU.·This mission programmable "screen less GPS helper" ·was done after the FPU AppNotes you mentioned and·a very early version of the FPU_SPI driver was developed for it.·The device·extracted the RMC·data·and spoke out useful information like "Airfield at 3 o'clock,·5 miles", or "Restricted Airspace·1 minute ahead". However, it was not loud enough in the cockpit, and once fell apart. It is waiting now for a good audio amplifier, a robust casing, not to mention the reprogramming. After I finish and put the Flight Simulator code and hardware on Obex, I will return to this project as I see·definite interest·on the forum about GPS data processing.·
Using your code, I detect the GPMC correctly but the dbg.str still drops the first char even in the Lat/Long values.
PRMC Lat = 113.4646 Long = 2129.6787 Lat = aN Long = aN
PGGA
PGSA
PRMC Lat = 113.4643 Long = 2129.6785 Lat = aN Long = aN
Also getting NaN (Not a Valid Number) when trying to convert to FP like example.
····· FPU.WriteCmd5Bytes(_SELECTA,Latitude,_STRFIELD,4,_STRTOF,_FSET0)
Latitude = 8
I am using the "PC_Interface" object as dbg but it has the same str routine as the others.
The string from the GPS is:
·$GPRMC,083707.000,A,3113.4643,N,12129.6785,E,1.56,176.83,241108,,*04
I am not sure if the problem is in FPU or dbg.
Still working with 4800 baud GPS.
I added a FPU.WriteCmd5Bytes routine to the FPU object.
So, making some progress.
I am trying to follow the picaxe basic example to get started.
Donald
Here is the code:
FPU.WriteCmd(_READSEL) strPtr := FPU.ReadStr dbg.hex(strPtr,8) dbg.out(" ") dbg.hex(@strPtr,2) dbg.out(" ") Dbg.Str(strPtr)I am getting this:
The "string" starts at $0000128C
I thought the @strPtr should give me the first character.
Don't know if it helps much but I get exactly the same results from your code.
I switched it from "PC_Interface" to "FullDuplexSerial" and still get the same dropped initial characters.
Will fool with it some more tomorrow.
Jim
It looks like I have a timing problem with the FPU.
Any ideas? I iwll change the clock pulses first as that is the easiest.
I have changed the _Read_Byte_Delay from 1us to 2us.
I have tried different terminal program.
I have included fpu_wait before each read.
All have same result. First character missing.
Only 4 chars in buffer according to strsize.
Things to consider:
The correct data is in the FPU buffer or I would not get a match for "G1 byte "GPRMC", 0 "
I don't know where I lose it.
After looking at the AN039-GC Distance example, especially the user defined functions in the GCdistance.fpu file, I began to wonder if it isn't possible to leave most of the processing/manipulation on the uFPU. Assuming that we can retrieve floating point numbers from the appropriate registers without truncation (big assumption right now) it might be a way to sidestep the problems with the data truncation. or not, it may truncate numbers as well. I have played with it for a while and finally figured out how to load the user defined functions to the uFPU. Now if I can only figure out how to use them.
One more question to show that I am apparently brain dead from this:
In your code there is the line:
I don't see where the symbol "G" is defined. I assume that you mean the address of a string "G"? I am obviously missing something here.
Jim
Thanks for looking at this.
The G1 is from the DAT at the end of GPS_FPU_Demo.spin
You are correct that most, if not all, of the desired functions can be carried out within the FPU by loading functions into either the EEPROM or Flash. I'm not sure what the difference is but one can be loaded via SPI but the other has to be loaded using the SERIN with the FPU IDE.
That is the final result I am hoping to achieve but I am an old, slow, brute force first kind of programmer so I try to do some simple stuff first to get a handle on things. Both the prop and the FPU are new to me so I'm trying to learn the undocumented "features" stuff that makes things either work or not.
Some things that are not well documented in the FPU instruction's which are apparently important in dealing with the SERIN,6 instruction is the STATUS byte.
From the FPU manual
but it doesn't really define the STATUS byte before the STRCMP which apparently can be different for different instructions but the other demo examples use $80 as the desired result of just the SERIN,6
It looks like bit7 is always 1
Bit0 is ZERO bit
Bit1 is SIGN bit
Bit4 is OVERRUN
Bit5 is CHECKSUM ERROR
The last sentence bothers me.·It seems that if·I send (via the FPU.SPIN) a command to read the status byte before the SERIN has completed, it will terminate and return an empty string.
Some of the things I have done:
wait 180us after the SERIN,6 command and then do a READSTR command before the READSEL.
I get 1 or 2·complete GPRxx sentences, then it goes " off into the land of OoobLaDee".
I think I may have to add a special call to FPU.spin to process the SERIN that will do the necessary waits and return the Status byte. Currently, the ReadCmdByte does not return anything.
By examining the Picaxe and other examples, it queries the FPU directly and works OK.
I just want to be able to understand the FPU calls and timing, then I will try to load functions and do the processing directly.
The reading of the complete string and then the individual fields (temporarily verified by debug print) would be followed by the more complicated calculations. I am a simple-minded creature.
I keep changing things around and get different results, but I'm sure its in the timing and sequence of the commands.
I'll keep plugging away.
Donald