Shop OBEX P1 Docs P2 Docs Learn Events
FullDuplexSerialPlus Object question — Parallax Forums

FullDuplexSerialPlus Object question

RontopiaRontopia Posts: 139
edited 2007-04-15 21:22 in Propeller 1
ok i know this a total noob question but;

Im reading the propeller education kit lab "objects". as most of you know this lab uses the object FullDuplexSerialPlus object that comes with the lab. Im afraid that its the text/lab is moving rather fast through some of the details of how the FullDuplexSerialPlus object actaully works.. im sure many of you are quite skilled with this object and understand its parameters well. I have many questions being new.



{{
───────────────────────────────────────────────────────────────────────────────
File: FullDuplexSerialPlus.spin

This is the FullDuplexSerial object v1.1 from the Propeller Tool's Library
folder with modified documentation and methods for converting text strings
into numeric values in several bases.

───────────────────────────────────────────────────────────────────────────────
}}



VAR

· long· cog···················· 'cog flag/id

· long· rx_head················ '9 contiguous longs
· long· rx_tail
· long· tx_head
· long· tx_tail
· long· rx_pin
· long· tx_pin
· long· rxtx_mode
· long· bit_ticks
· long· buffer_ptr
····················
· byte· rx_buffer[noparse][[/noparse]16]·········· 'transmit and receive buffers
· byte· tx_buffer[noparse][[/noparse]16]·



PUB start(rxpin, txpin, mode, baudrate) : okay
· {{
· Starts serial driver in a new cog


··· rxpin - input receives signals from peripheral's TX pin
··· txpin - output sends signals to peripheral's RX pin
··· mode· - bits in this variable configure signaling
·············· bit 0 inverts rx
·············· bit 1 inverts tx
·············· bit 2 open drain/source tx
·············· bit 3 ignor tx echo on rx
··· baudrate - bits per second
···········
··· okay - returns false if no cog is available.
· }}


· stop
· longfill(@rx_head, 0, 4)
· longmove(@rx_pin, @rxpin, 3)
· bit_ticks := clkfreq / baudrate
· buffer_ptr := @rx_buffer
· okay := cog := cognew(@entry, @rx_head) + 1



in this bit of code:

how does the method Start reserve memory on the stack? or does it?

what is the bit_ticks:=clkfreq / baudrate for?

is stop a method? or do it send the focus to the stop method?

I dont see longfill defined anywhere so how is that you can pass parameters to it? is it a method? sorry abou that.. I see its a keyword now.

actually this whole bottom half of the start method is greek to me.··maybe I dont need to understand how it works just that it does work right? im a bit of a control freek tho[noparse]:)[/noparse] and understanding how the method works is kind of key when you trying to learn how to write your own. maybe im making this to hard?

thanks for your time



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



IC layout designer
Austin Texas

Post Edited (Rontopia) : 4/15/2007 2:42:51 AM GMT

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2007-04-15 03:20
    1) start does not reserve memory on the stack

    2) The bit_ticks assignment calculates the number of system clock cycles per bit time.
    Spin has a division operator while assembly does not and it's easier to calculate this in Spin.

    3) stop is a method

    4) The cognew passes the starting address of a block of parameters (@rx_head) to the assembly routine being copied to the cog and started (@entry).
    The assembly routine copies just the parameters into the cog's memory. The buffer pointers and the buffers themselves are included in this area
    which is left in main (hub) memory where the Spin code can refer to it as well.
  • RontopiaRontopia Posts: 139
    edited 2007-04-15 20:32
    thanks mike..

    heres the thing tho.. stop comes before everything else. in my simple mind, it looks like this method gets stoped before the memory gets reserved in cog memory. I know this is not the case becasue i have used the method. but like I said in the first post, im reading what others have done in an attempt to learn how to write my own code/methods.

    I also understand that this is most likely as simple a question as it can be. im sure things like this are obvious to folks like you. to me however it the code looks upsidedown. im sure im making this harder then need be.

    thanks in advance.
    Ron

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



    IC layout designer
    Austin Texas
  • Mike GreenMike Green Posts: 23,101
    edited 2007-04-15 20:41
    The reason the "stop" is there is that these object are intended to be used in all sorts of programs and it's possible that a program may have already started a cog with this driver. The "stop" assures that any existing cog is stopped before an attempt is made to initialize and start a "new" one. When a Spin program is loaded into memory and started, the VAR area is initialized to zero. The "stop" routine doesn't do anything if the "cog" variable is zero (it stores the cog # + 1 in its global variable).
  • RontopiaRontopia Posts: 139
    edited 2007-04-15 21:10
    wow thats smart. I would have never thought of that!!

    thanks for answering these simple questions. I have one more tho.. am I making this to hard? are there things that i just dont need to know?

    thanks again

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



    IC layout designer
    Austin Texas
  • Mike GreenMike Green Posts: 23,101
    edited 2007-04-15 21:22
    That may be smart. I can't take credit for it.

    If you have to wonder about it, you probably are indeed making things too hard.

    How can you know whether you need to know something or not until you notice that you know it or don't when you need it?

    Common sense and straightforwardness goes a long way

    (Let's see ... there must be some more "guru-ish" platitudes I can throw in here ...)
Sign In or Register to comment.