Need help understanding FullSerialDuplex ...

[jmlprop]

Hello All,
I am new to the prop and trying to understand the code associated with serial data transfer. It is my assumption that the code below declares some varibles along with transmit & recieve buffers. Public method "Start" accepts these parameters passed to it
to set up the baud rate, mode,·ect., checks to see if a cog has started and returns its boolean value.

·Am I on track so far ?

·I need to understand this process fully for a project that I am working on.

·If so, could someone please explain the following lines of code more detail.

··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




''************************************
''*· Full-Duplex Serial Driver v1.1· *
''*· (C) 2006 Parallax, Inc.········ *
''************************************

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[16]
· byte· tx_buffer[16]·

PUB start(rxpin, txpin, mode, baudrate) : okay


'' mode bit 0 = invert rx
'' mode bit 1 = invert tx
'' mode bit 2 = open-drain/source tx
'' mode bit 3 = ignore tx echo on rx

· 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
·

[Mike Green]

The stop stops any existing running serial driver if say you reinitialized your program without previously stopping it.

The longfill initializes the first 4 longs to zero (rx_head through tx_tail).

The longmove copies the 4 parameters to start to the next 4 longs in the table (rx_pin through bit_ticks).

The assignment to bit_ticks computes the number of clock ticks for the Baud requested and the assignment
to buffer_ptr passes the address of the receive buffer (and the transmit buffer 16 bytes further).

The cognew starts the assembly driver and passes to it the starting address of this whole table which it uses
to refer to the various items in the table (rx_head through buffer_ptr).

[jmlprop]

Mike, Thank You for taking the time to explain these lines. I have a spread spectrum tranciever (TTL) that I want to interface to the prop. If I wanted to set Pin (1) of the prop to an input to recieve my serial data would I have to code another method and call
the Start method in "FullDuplexSerial" with the parmeters it needs? The end result I would like to obtain is to have (1) Cog for recieving data and another for transmitting data. I am one week into learning the prop from the standard Stamp chips, a little fasinated and a little confused :>)

Thank You again,
jmlprop

[Mike Green]

"FullDuplexSerial" is just what the name implies, a full duplex serial driver. It uses only one cog to both transmit and receive. You only need to call the start routine once to set up both directions. To use pin 0 for transmit and pin 1 for receive at 9600 Baud you'd call "serial.start(1,0,%0000,9600)". That implies Rx not inverted, Tx not inverted, not open drain on transmit, and no ignore echo on receive. This assumes that you declare 'OBJ serial : "FullDuplexSerial"'.

The return value is true if the driver was started ok, false if there were no free cogs available (rarely happens).

[jmlprop]

Thank You Mike, I will do some testing, reading, ect.
Very Helpfull,
jm;prop

[Newzed]

Mike, is the full duplex any better than the simulation object in your OS program?· I can send and receive bytes and strings with simulation - what more would you want to do?

Sid

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Don't have VGA?

Newzed@aol.com (mailto:Module?Newzed@aol.com)
·

[Mike Green]

Sid,
These have different purposes. FullDuplexSerial is intended to provide a buffered high speed serial communications channel in both directions at once using a single cog. The simulation object was intended to provide a slow to medium speed half duplex (one direction at a time) serial channel to simulate a Stamp. You could use FullDuplexSerial to do the serial I/O for simulating a Stamp, but it's more complex than you need for that task and harder to modify if you want some kind of special behavior.
Mike