Shop OBEX P1 Docs P2 Docs Learn Events
How to Captuure Serrial Data -PASM ? — Parallax Forums

How to Captuure Serrial Data -PASM ?

SiriSiri Posts: 220
edited 2008-10-14 17:32 in Propeller 1
To anybody who can spare a minute or two:

What I am trying to do is to capture 3 Bytes of data sent out from a pulse-ox.(measuring oxygen saturation in blood)
The data format is Baud 9600-8bits-N-1 no flow control.
I know I have to use ShiftIn routine to capture the data.This machine sends out 3 Bytes of Data representing
Heart Rate,Oxygen saturation and Status of the sensor.

My question is How do I know which Byte I am capturing(The 3 bytes are always in the same successive order) so
when I capture the 3 Bytes they are in the dame order each time I begin capturing the data?
In other words is there a some sort of a signal/instruction that does this.
Secondly How do I put them in separate variables in PASM which can be passed on to the SPIN or
if placed in one variable then the the 3 bytes to be read and put in separate variables using SPIN.

I am trying to understand by looking at various serial routines used in the serial objects but there is not much
detailed explanations given as to How and Why of it - so I can really understand the subject.

Thank you.

Regards,

Siri

Comments

  • sylvie369sylvie369 Posts: 1,622
    edited 2008-10-14 15:26
    I think this is a question to be answered by looking at the datasheets for the sensor, not from the Propeller end. The sensor probably does something in the data it sends to signal when it is starting a new set of three bytes - some kind of header code, or putting a CR after the third byte. You might try sending the data directly to a terminal so you can look at the format directly.

    If there's no header for the data, you may need to read in a byte and then figure out which it is by comparing it with whatever the valid range for that piece of data would be. The sensor status byte must have certain codes that represent certain things (valid data, etc.), and it's probably easiest to look for that one.

    Post Edited (sylvie369) : 10/14/2008 3:34:59 PM GMT
  • BTXBTX Posts: 674
    edited 2008-10-14 15:30
    Hi Siri.
    I'm not sure if I understand your question, why.

    Why not to use a FullDuplexSerial object ? (or similar)
    You'll have those recieved data in a spin program.

    I guess you're missing something with the "sender", should be some signal that advice you, when the data stream begins.
    So in that way, you'll recognize wich one is.
    Do you have a datasheet of the pulse-ox ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Regards.

    Alberto.
  • hippyhippy Posts: 1,981
    edited 2008-10-14 15:41
    There's no easy way to distinguish which data is which if each data item could be any of the data items. For example "10,11,12", "11,12,10" and "12,10,11" could all be equally valid.

    Knowing that it would be pointless to generate such a stream which cannot be determined there must be some means to do that - Perhaps a preceding synchronisation pulse, a header byte, the length of gap between sets of three bytes, or maybe data bytes have distinct value ranges.
  • Mike GreenMike Green Posts: 23,101
    edited 2008-10-14 15:55
    Use one of the existing serial I/O drivers. Simple_Serial is simpler than FullDuplexSerial, but FullDuplexSerial has the advantage that it's already buffered.

    Any of the serial I/O drivers will deliver the received information in the order it's received. You don't necessarily know what the sensor is doing when you start receiving. It may have already sent the 1st of 3 bytes, so your program may think it's received the 1st byte when it's actually received the 2nd byte. The only way to deal with this is to reset or restart the sensor after the program has started. If there's a delay between readings, you can use that to synchronize your program with the sensor.

    The receive routines in all the serial I/O drivers deliver one byte at a time. You call a receive function and it returns the next byte received. All of this is in Spin. Call the receive function 3 times and you get 3 successive byte values which you can store in different variables. If you use FullDuplexSerial, the actual receive routine is in assembly language, but the object hides that from you. All your program sees is a set of Spin routines. Simple_Serial is completely written in Spin.
  • SiriSiri Posts: 220
    edited 2008-10-14 16:50
    I am sorry for the confusion ,I should have mentioned in the first place that I have the sensor(pulse-ox) data captured and
    displayed on VGA monitor using SPIN as you all have pointed out.

    What I an trying to do is to learn to do the same display of data using PASM.

    In SPIN when ever I start the program it correctly displays the data.

    Thanks,

    Regards,
    Siri

    Here is the SPIN Code:


    {VGA- display Pulse-ox data - V1.0 - 10/14/08   """ Working Well"}
    
    
    
    CON
    'Set clock speed to 80 MHz
      _clkmode = xtal1 + pll16x        'Sets the clock speed to 80 MHz using a times 16 multiplier
      _xinfreq = 5_000_000             'Crystal speed: 5 MHz
    
    
    VAR
      Byte Sdata1                        'Declares variable for first byte of data from pulse-ox
      Byte Sdata2                        'Declares variable for second byte of data from pulse-ox
      Byte Sdata3 
                                        
    OBJ
    
       Text    : "VGA_Text"
       Exserial :"Extended_FDSerial"
    
    PUB Start
    
        Exserial.start(6,0,0,9600)  ' Rx,Tx, Mode, Baud 
        text.start(16)
        DisplayText
        DisplaySerialData
       
    
    PUB DisplayText
    
        text.out($00)
        text.out($01)
        text.str(string($A,1,$B,1))
        text.str(string("Oxygen Saturation :"))
        text.out($0D)
        text.str(string($A,1,$B,2))
        text.str(string("Heart Rate        :"))
        text.out($0D)
        text.str(string($A,1,$B,3))
        text.str(string("Probe status      :"))
    
    PUB DisplaySerialData
    
         Repeat
           Sdata1 := ExSerial.Rx                                            
           Sdata2 := ExSerial.Rx                                                 
           Sdata3 := ExSerial.Rx                                                
           text.out($0D)
           text.str(string($A,21,$B,18))
           text.str(string("           "))
           text.str(string($A,21,$B,18))
           If Sdata2 <> 127     
             text.str(string("OK"))
           Elseif Sdata1 :=  127
             text.str(string("Check probe"))
           
           text.out($0D)
           text.str(string($A,21,$B,17))
           text.str(string("   "))
           text.str(string($A,21,$B,17)) 
           text.dec(Sdata2)
           text.out($0D)
           text.str(string($A,21,$B,16))
           text.str(string("    "))
           text.str(string($A,21,$B,16)) 
           text.dec(Sdata3)
           text.str(string("%"))
    
    
  • Mike GreenMike Green Posts: 23,101
    edited 2008-10-14 17:22
    Why use assembly for this? Serial I/O is relatively slow, well matched for the speed of Spin. In addition, the editing of data for display is very messy and inefficient in assembly language. When you have a mixed language system like Spin/PASM, for any given task, you pick the "best" tool for the job. About the only things that assembly is well suited for (as opposed to Spin) is high speed and/or very closely timed operations and/or when the code and some data is best residing in the cog itself rather than the Spin interpreter in the cog and the code and data in hub memory. The bit level serial I/O (particularly faster than 9600 Baud) is well suited for this and the video generation requires it, but not the "glue" that binds it all together and provides the overall control.
  • SiriSiri Posts: 220
    edited 2008-10-14 17:32
    Mike,
    Thank you for your advise.I see the point now - all PASM routines are not superior/faster or suited for all propeller
    tasks.
    I would'nt waste any more time on this as SPIN does it well.

    Thanks to all for the time.

    Regards,
    Siri
Sign In or Register to comment.