1 cog GPS parser

Thric

Hi,
I know there are many GPS parsers in the OBEX, and I've used a few successfully. However one of my projects is starving me of 1 cog, I've tried http://obex.parallax.com/objects/579/ as a single cog solution; however, it doesn't work. Has anyone used this object successfully or any other 1 cog GPS parser?

Thanks

pgbpsu

I've not used that object (I've always used Perry's but it requires a cog of its own). If you are starved for cogs and have more than one serial port, consider using Tim Moore's 4 ports in one. If you are using multiple cogs for Full Duplex Serial, this could help get your cog back.

What rate are you collecting gps data? And what messages? I think making Perry's code work in the serial port cog shouldn't be too bad. I've got a use for this as well, so I'd be willing to help you out. The trouble comes in the timing. Depending on your messages and update rate, there may not be enough time to do everything. In my case, I know exactly what part of the second my 2 messages come. I suspect I have enough time to parse them each before the next message comes so moving them into an existing cog is possible.

Let me know....
Peter

Cluso99

Thric: If you describe what is in each cog, perhaps we may have other solutions for you.

Thric

Thanks for the replys
@pgbpsu: Thanks for sharring that nifty object, thats really useful. I believe i'll just avoid Perry's code for now as I'm not that fond of getting into ASM too much. For the 4 ports in one, is there a way to recieve decimals like in the parallax serial terminal? I tired implementing a few changes with mild sucess.

@Cluso99: This is a quick run down on the cogs i'm using:
1 for the main program
1 for Servo control
1 for finding heading using Gyroscope information
1 for Floating Point math for finding the heading
1 to control the ADC converter bringing in sensor data
1 for PID control of the servos
2 for GPS

Thric

@pgbpsu: Thanks for that object, its really useful. I don't think I'll focus too much attention into Perry's code as I'd rather avoid getting to much into ASM anyway i suspect something is fundamentally wrong as my GPS runs at 4800 baud and the code was supposedly tested at 115200 baud. For the 4 ports in one program, have you been able to receive decimal values like in the parallax serial terminal? I've tried a little tinkering with mild success.

@Cluso99: Heres a basic run down of the cogs I'm using:
1 for the main program
1 for servo control
1 for PID control over the servos
1 floating point for the PID
1 for finding the heading
1 of the ADC brining sensor information for the heading
1 for the floating Point math to make the heading
2 for the GPS parser

if I use the 4 in one i can use 1 for the 4 in one and 0 for the GPS and 0 for Wireless Communication.

andrejk

I'm actually working on rewriting that assember-based one. But I'm a PropAsm noob so I wouldn't wait for me to finish. But I will post up what I end up with.

At 80mhz at 38400 baud, I have somewhere south of 500 operations to work with between bits. That should be plenty to do simple parsing. I woudln't expect anything fancy like floating point math though.

pgbpsu

Thric-

I use the 4 serial port object anytime I need a serial port. It's allowed me to do things with the prop that wouldn't have been possible using one cog for each (a la FullDuplexSerial).

I usually set things up like this:

CON
'***************************************
' UART Constants
'***************************************
  DEBUG             =      0
  DEBUG_TX          =     30
  DEBUG_RX          =     31
  DEBUG_BAUD        = 38_400

  PHONE             =      1
  TX_TO_PHONE       =      3       '  red wire on my phone cable is the tip = Phone RX from Prop
  RX_FROM_PHONE     =      2       '  black wire on my phone cable is the ring = Phone TX to Prop
  PHONE_BAUD        =  4_800

OBJ                                                     ' 1 cog for main
  uart              : "pcFullDuplexSerial4FC"           ' 1 COG for these 2 serial ports

VAR
  byte mainCogId
  byte serialCogId

PUB Main | 

  SETUP_SERIAL

  uart.str(DEBUG,string("Serial port cog: "))
  uart.dec(DEBUG,serialCogId)

PUB SETUP_SERIAL
  uart.Init

  uart.AddPort(DEBUG,DEBUG_RX,DEBUG_TX,-1,-1,0,0,DEBUG_BAUD) 'Add DEBUG port
  uart.AddPort(PHONE,RX_FROM_PHONE,TX_TO_PHONE,-1,-1,0,0,PHONE_BAUD) 'Add PHONE port

  serialCogId := uart.Start - 1                                           'Start the ports

  waitcnt(clkfreq * 2 + cnt)  'wait 2 seconds

return

Have a look at the addport method to get the details, but it's pretty much just like fullDuplexSerial, except that you have to declare which of the 4 ports you are adding/using. Then when you use the normal FullDuplexSerial methods (str for example) you simple have an additional argument, the port.

I know that many of my programs have multiple cogs sitting in repeat loops. That's a logical way to structure a program, but it can be wasteful of resources. Have a look at what your doing and see where there's "down" time. For instance, I have a gps in one of my project that outputs the NMEA message at the same portion of the second every time (between 50ms and 100ms after the 1PPS). Once I figured this out I was able to setup a repeat loop that kept track of where I was in the second, by grabbing the system counter every time the PPS line went high and comparing that to the current system counter. If I was close to the arrival of the NMEA message, I would wait for it and process it. Once it had arrived, I know I had almost 9/10ths of a second to do other things. That's where I intend to put the actual parsing of the NMEA message (although I haven't yet). In your case, maybe you can do your PID control there if once/second is fast enough for that. Just a thought....

Peter

Thric

Sorry for the double post, I pressed back so I thought it didn't send the post.

@pgbpsu: I've got 4 in one program up and running and it works fairly well in sending strings and decimals to the parallax serial terminal, the only problem is in receiving decimals.

PUB decin : Value | place, ptr, xsw

    Delimiter := ","
    place := 1                                           
    ptr := 0
    value :=0                                             
    dataIn[ptr] := RX(1)       
    ptr++
    repeat while (DataIn[ptr-1] <> 13) and (DataIn[ptr-1] <> Delimiter)                     
       dataIn[ptr] := RX(1)                             
       ptr++
    if ptr > 2 
      repeat xsw from (ptr-2) to 1                            
        if (dataIn[xsw] => ("0")) and (datain[xsw] =< ("9"))
          value := value + ((DataIn[xsw]-"0") * place)       
          place := place * 10                               
    if (dataIn[0] => ("0")) and (datain[0] =< ("9")) 
      value := value + (DataIn[0]-48) * place
    elseif dataIn[0] == "-"                                  
         value := value * -1
    elseif dataIn[0] == "+"                               
         value := value 
    
Pub Rx(port)
    '' See FullDuplex Serial Documentation
    '' xsw := Serial.RX   ' receives a byte of data  
    return (uarts.rx(port))

This is just something I tried to alter from the extended full duplex serial program as a subroutine in my main program. Its not really working, probably a careless mistake, but any pointers is appreciated.

pgbpsu

Thric-

My version (old admittedly) of FullDuplexSerial doesn't have any methods for receiving decimal strings. Could you be talking about another object?

I'll hunt around, but if there's an example to work from it shouldn't be too bad to convert that.

p

pgbpsu

Thric-

You might be referring to Martin's Extended Full Duplex Serial. It looks like a wrapper for Full Duplex Serial. I've altered Tim Moore's 4-ports-in-one-cog to include only one if Martin's functions: rxDec. If you need others, you should be able to follow that example. I didn't have an opportunity to check that it works correctly which is why I didn't do the others, but it looks pretty straight forward.

Let me know how you get on.

Peter