Actual Full-Duplex Serial Object

cgracey · 2006-02-25 21:43

Everyone,

Attached to this post is a Spin object file you can download and view.

There are actually two files here: FullDuplexSerial.spin is the object (use NOTEPAD to view), while FullDuplexSerial.txt is an automatically-generated documentation file that is wholly a product of the .spin file. Within the Propeller.exe tool, this 'file' is generated on the fly, for viewing,·and usually not saved to disk. This way, one programming effort produces both code and downstream-user documentation. We've actually made our own TrueType·font for the Propeller tool which provides symbols for making schematics and waveforms right in your code comments (and, hence, in the automatic documentation file).

Anyway, this "FullDuplexSerial" object launches a COG in assembly language to perform background serial communications. Here's how you might use it in a higher-level object:

OBJ

· Com : "FullDuplexSerial"

PUB Go
·
· Com.start(31, 30, %0000, 115_200)
· Com.str(string("Hello World!", 13, 10, "How are you?"))

· repeat 1000···· 'Echo for a while
··· Com.tx(Com.rx)

· Com.str(string(13, 10, "Hasta la pasta..."))
· Com.stop

You could do this, too, if you wanted four of them:

OBJ

· Com[noparse][[/noparse]4] : "FullDuplexSerial"

You would then use them as 'COM[noparse][[/noparse]n].routine', where n ranges from 0 to 3. The only difference to your application size would be three more sets of variables, which amounts to 3 times 18 longs for this object. No matter where in your heirarchy you instantiate objects, the compiler squishes away redundant objects so that only one final copy of each exists in memory. Each instantiated object, though, gets its own variable space which is initialized to zero's. This keeps·every·object instance feeling·fresh and unique. It doesn't matter how many COGs might be concurrently mulling over·an·object's executable code, it's the variables that maintain the unique state of each instance.

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

Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey) : 2/25/2006 10:02:59 PM GMT

MacGeek117 · 2006-02-25 21:49

I'd say that Spin would have a steep learning curve.
RoboGeek

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Frankly, I'm scared by the Propeller. Self-modifying code!? Insert one wrong command and "What's it doing?!"

This is going to be a good chip!
www.parallax.com
www.goldmine-elec.com
www.expresspcb.com
www.startrek.com
·

Jon Williams · 2006-02-25 22:19

Spin is actually quite straightforward; it's the assembly code that will take a bit of time for us mortals. Thankfully, Chip is a great teacher and will provide us with a lot of useful examples.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

cgracey · 2006-02-25 22:48

RoboGeek said...
I'd say that Spin would have a steep learning curve.
RoboGeek

Well, I hope it doesn't seem overwhelming to people. It was made to be very easy to learn, and still be powerful. I hope that once we have good documentation, an experienced programmer will be able to get a solid grip on the language in about 10 minutes. There's really not that much to know. What's more ponderous is the implications·of having·eight processors at your disposal.

That example I posted is about as extreme as Propeller programming gets, by the way. A typical user of that object would likely not do anything so complex in his code, as he would be using objects like this one to build his application. He doesn't have to look at anything too scary, if he doesn't want to - like my brother's boys, when something scary starts to get on TV they say "Change the channel, Daddy! Change the channel!"

Most people won't initially look under the hood, but when they're ready, everything will be there.

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

Chip Gracey
Parallax, Inc.

Bean · 2006-02-25 23:28

Chip,
First of all thanks for showing me all of your "toys" when I visited.
I see they took the chains off the door and let you out of the "bat cave".

It's nice to see some real programs in spin.
I know Pascal very well so I don't think it will be too much of a learning curve for me.
I can't wait to buy a dev. kit.
I want to try doing the CORDIC ATAN and HYP in spin (I hope you haven't already done them).

Great to have you join in the forus too.

Terry Hitt (Bean)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

"Ability may get you to the top, but it takes character to keep you there."
·

daniel · 2006-02-26 00:00

This example puts several things into better·focus for me.

The assembly/compiler output describes the serial object of taking 156 longs program + 18 longs data.· This all gets loaded into a COG, starting at·the COGs $000 address.· What will be loaded to the cog for the balance of the 512 long footprint?·

I presume that the placement of the serial object is packed tightly into the global RAM.· Is the balance of the 512 long footprint the beginning of the next object(s) sequentially in RAM?·

Daniel

cgracey · 2006-02-26 00:41

daniel said...

This example puts several things into better·focus for me.

The assembly/compiler output describes the serial object of taking 156 longs program + 18 longs data.· This all gets loaded into a COG, starting at·the COGs $000 address.· What will be loaded to the cog for the balance of the 512 long footprint?·

I presume that the placement of the serial object is packed tightly into the global RAM.· Is the balance of the 512 long footprint the beginning of the next object(s) sequentially in RAM?·

Daniel

Actually, the assembly code that runs in a·separate COG·is only 83 longs. The Spin code takes the other 73 longs. The object will have·a 156-long footprint in main memory, though. When·a COG is launched, it will load from the start of the 83-long·assembly program and pick up whatever·trails the 83-long program, which will be whatever is in main memory·- probably other objects. Though your assembly program is followed by a bunch of indeterminate data, it doesn't matter because your assembly program only makes references within itself. The somewhat-exception is the RES-declared variables which extend beyond the assembled code (but don't take space in main memory), and will be initialized to whatever followed your assembly program (with who-knows-what).

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

Chip Gracey
Parallax, Inc.

daniel · 2006-02-26 01:02

Chip Gracey said...
Actually, the assembly code that runs in a·separate COG·is only 83 longs....

I missed that.

Since the compiler knows anyway, could it be made to emit the size of the assembly nuggets (perhaps global label to next)?· Perhaps even the cycle count too (thus I can avoid documentational effort of the comment notations seemingly common in well documented SX VPs)?

Uh, perhaps it just dawned on me--just count the assembly lines for the size.

Daniel

Beau Schwabe · 2006-02-26 14:56

Here is a link to a reply I posted in the "Propeller for dummies..." thread, that may help explain a few things.

http://forums.parallax.com/showthread.php?p=573114

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

geokonst · 2008-09-11 18:37

Hello everybody.
I have trouble using the the full duplex and extended serial object. I do have communication but all I get is gibberish on the other side.
I am experimenting with a propstick usb.

First of all I had to change the baud rate on the code above in order to get any activity at all. But even then I get things like random ascii. Same with bytes. I have tried using different pins, and ports other than the onboard usb, but same results. I have also tried all possible combinations of serial mode.
When sending byte 97 in mode 0 for example I get hex 99 9F or ascii ™Ÿ (in mode %0010 i get 99 9F or ™&#376[noparse];)[/noparse]. I mainly experiment at 9600.

Any ideas?
Thank you!

Mike Green · 2008-09-11 19:03

You will need to furnish more information like a schematic and a copy of your program. You may have an error in your Baud information or you may need to use inverted mode. There may be some kind of problem with your connection hardware. It's impossible to tell without much more information.

geokonst · 2008-09-11 19:09

Hello mike. Thank you for your fast response.
I am using the propstick usb with no extra hardware (just 5v in) with the onboard usb com (pins 30,31), but I have also tried using different pins into a rs485 transceiver and then into a 485 to usb com port (done this many times with other micros)

I have used a variety of codes using both the full duplex and extended full duplex object. But even the one above doesn't work.
I am using hyperterminal and com port toolkit.

I don't know what else information I could give you.

Mike Green · 2008-09-11 19:13

What's the polarity of the transceiver's inputs and outputs? Mode 0 assumes that the signal line idles at logic 1, that the start bit is a logic 0. If not, then you have to use inverted mode which would be mode 3 (%0011).

Ken Peterson · 2008-09-11 21:15

Also double check your clock rates. I spent a while pulling my hair out until I remembered that the board I was using had a 4 MHz crystal instead of 5 MHz, but my code had 5MHz in the CON section.

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

Cluso99 · 2008-09-12 01:38

@Chip:
Could you add the following to your FullDuplexSerial (and any others that may be relevant): (rather than a modified version) Didn't realise the age of this thread.

Add the following to your FullDuplexSerial object to make it easy to interchange the tv and fdx objects for output.

PUB out(txbyte)
  tx(txbyte)

This permits code written for outputting to the TV object to be simply changed to the FullDuplexObject with only changing the initialisation call and not using the TV Pins assignment

CON
  TV_PIN        = 12
OBJ
' disp          : "TV_text"
  disp          : "FullDuplexSerial2"                   'my modified version for tv.out == tv.tx
PUB
' disp.Start( TV_PIN )
  disp.start(31,30,0,115200)
 
  disp.out("?")
  disp.out($00)                                           'clear screen
  disp.Str( String( "Starting ...",$0D ) )
  disp.Hex( result, 8 )
  disp.Dec( result )

Notice how simple the change is between outputting to the serial and tv.·The user code doesn't care if it is TV or FDX.

I presume there is also a VGA driver which has similar code.

Post Edited (Cluso99) : 9/12/2008 1:46:37 AM GMT

william chan · 2008-09-12 02:21

Would declaring

OBJ
  pc  : "FullDuplexSerial"
  lcd : "FullDuplexSerial"

also squish the 2 objects into 1 copy in memory only after compilation?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

Mike Green · 2008-09-12 03:01

You can declare two or more copies of the same object file (like "FullDuplexSerial") with separate names as you've shown or as array elements or both and there will be only one copy of the code and any DAT sections. Only the VAR sections will be unique for each named object or array subscript.

geokonst · 2008-09-12 11:21

Ken you were right! I forgot to set the clock frequency. Thank you so much! I would never have thought of that.

Thanks everybody!

CarlosFandango · 2008-09-18 18:42

Can I ask a further question of this thread (which is very interesting, although obviously I don't understand everything...):

I am using a uOLED-96-Prop which has an 8MHz crystal. The objects I have for serial comms are FullDuplexSerial and Extended_FDSerial, but I haven't deployed any code yet (hoping to tomorrow). The question is, if I specify _clkmode as xtal1 + pll16x and _xinfreq 8_000_000 will the baud rates in the serial comms objects (Serial.start) still be correct, or do I have to change something somewhere?

Sorry if this should be obvious, but I am a beginner with the prop and I'm still asking a lot of stupid questions at the moment!

Mike Green · 2008-09-18 19:06

First of all, the Propeller won't work reliably with the clock settings you've indicated. It may not even work at all. The maximum clock frequency for the Propeller for reliable operation is 80MHz. The PLL multiplier times the crystal frequency have to come out to no more than that. With an 8MHz crystal, you can use up to PLL8X

Most library objects will adjust themselves for the system clock frequency specified by the _clkmode and _xinfreq values by using the clkfreq function. This is particularly true of the serial I/O, video/vga, and keyboard drivers. Note that, if _xinfreq doesn't match the actual operating conditions, the program timing will be off. The boot loader uses the _clkmode value to initialize the clock.

CarlosFandango · 2008-09-18 19:52

As I say, I obviously don't understand everything yet...! The numbers I quoted were taken directly from the 4D demo code as posted for use with the uOLED-96, I have run this and it seems to work but I will have to consider these clock speeds a little more carefully. It will probably be unstable at best... I think am going back to the manual for a while...

CarlosFandango · 2008-09-19 13:43

I'm having trouble with my serial comms. I checked everything I could think of but still no comms, so here I am again...!

Here's where I'm at:

I purchased a few prop chips (actually uOLED-96-Props) from a UK supplier, but they weren't able to supply the prop clips or plugs. So I built the transistor-based serial to propeller schematic detailed on the parallax site (attached). With this I am able to communicate with the prop quite sucessfully, program / verify etc. I'm working with Extended_FDSerial and FullDuplexSerial, using the following spin code:

CON

_clkmode = xtal1 + pll8x
_xinfreq = 8_000_000

OBJ

comms : "Extended_FDSerial"

PUB Start
comms.start(31,30,0,2400) ' Rx,Tx, Mode, Baud

REPEAT
comms.tx("-")

(I also tried putting various pauses after the tx but this hasn't made any difference).

I checked the output from the prop with a scope and it IS sending the byte repeatedly as expected, and according to my measurements is at the correct frequency (1/2400 pulses per sec). However the voltage difference between 1 and 0 is only about 500mV at the computer's serial port, so I suspect this is the problem. I admit that I'm not certain what the port expects or requires

Has anyone used the atttached circuit to achieve comms at all? In the meantime, I found a prop clip and am awaiting the arrival of that, but I'd like to get out of my current quagmire!

- CF

Mike Green · 2008-09-19 14:04

What's the voltage at DTR?

If you look at the circuit diagram, you'll see that the output transistor uses DTR as a reference. Normally, this is at -3.3V when the serial port is open. If you are able to use this circuit for programming, that's probably the case. You may not be setting DTR when testing the output voltage of the port. Try connecting it to ground or -3.3V.

Your code looks ok and wouldn't affect the output voltage anyway.

CarlosFandango · 2008-09-19 14:31

Thanks (again!) Mike for the near instantaneous response!

I have downloaded the Parallax Serial Terminal (after I noticed it was there...) and this in fact works. I can communicate with the Prop over RS232. It seems that it was Hyperterminal's behaviour, along with that of a number of other terminal emulation programs, that were preventing this from working by setting DTR high and causing the odd functionality I observed. If there is a way of changing this DTR level using the software I have used till now, then I haven't been able to determine what it is. The Parallax terminal allows this to be set explicitly via a check box; voila, problem solved... why this sort of thing has to happen after several hours of not getting anywhere, followed by a post to this forum, I don't know. It could be old age.

However, I have on order a Prop plug which I think is a better more well-rounded solution - it had better be, they cost 45 bucks here in the UK with tax and postage!

- CF

Actual Full-Duplex Serial Object

Comments