Problems using FullDuplexSerial
I just made a program that sends a few different strings to a serial port with the FullDuplexSerial Object. I ran into a problem when I attempted to send a string that contains the word "string". I first used the following...
ser.str(string("This is a test String"))
and I received "This " on Hyperterminal
Then I tried to split the sentence into words and send them all separately...
ser.str(string("This "))
ser.str(string("is"))
ser.str(string("a "))
ser.str(string("test "))
ser.str(string("String"))
I then received "This is a test " and nothing more.
I then tried only ser.str(string("string")) and Hyperterminal just moves the cursor ahead 1 space every time I hit the reset button
any other string contained within the quotes works fine, I only have a problem when sending the word "string"
I have in my OBJ section "ser : "fullduplexserial" and my PUB block begins with "ser.start(31,30,0,9600)"
Am I missing something obvious here??? doing anything wrong???
Also, is there a limit to the size of a string?
Thanks in advance for the help
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade
"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
ser.str(string("This is a test String"))
and I received "This " on Hyperterminal
Then I tried to split the sentence into words and send them all separately...
ser.str(string("This "))
ser.str(string("is"))
ser.str(string("a "))
ser.str(string("test "))
ser.str(string("String"))
I then received "This is a test " and nothing more.
I then tried only ser.str(string("string")) and Hyperterminal just moves the cursor ahead 1 space every time I hit the reset button
any other string contained within the quotes works fine, I only have a problem when sending the word "string"
I have in my OBJ section "ser : "fullduplexserial" and my PUB block begins with "ser.start(31,30,0,9600)"
Am I missing something obvious here??? doing anything wrong???
Also, is there a limit to the size of a string?
Thanks in advance for the help
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade
"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
Comments
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·
Check your terminal settings on HyperTerm. It needs to be set to TTY to work properly, it defaults to ANSI. I've used the FullDuplexSerial to the max and using all different speed crystals with no problems.
Oliver
I also ran a short program that I found elsewhere on this forum that transmits "It's alive....It's alive" through the same pins, no problems with that program. So my hardware setup is working properly. I'm stumped. It must be some silly error, I'm sure I'll slap my forehead when I find it.
Thanks all!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade
"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
-Martin
a fast enough data rate because the calls are non blocking.
What speed are you using? At least 115,200 is needed which is also
the highest that my hyper-terminal on XP will configure to.
Mike
Funny, I remember working with microcontrollers with max data rates of 9600!
I thought about that when I was opening Hyperterm, It asks if you want hardware flow control, Xon/Xoff or no flow control. I chose no flow control, because the only lines connected to the serial port are rx/tx/DTR and GND.
Also, the third value passed in the Start command, what is the correct value to use in that field? The first 2 are the pins to use, and the 4th is the data rate, prehaps my problem lies in that value???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade
"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
9600 baud works fine. I've been using it with XP and Windows 2000 versions of HyperTerm with no problems. Is flow control set to none on HyperTerm? If you want I can send you my settings that work for hyperterm. In fact this is the first project in the propeller book, and it works on all of my machines (and Linux too). I'll email you the spin program. It uses the latest FullDuplexObject. If it doesn't work then you have another problem.
Oliver
I also found an old thread today about a "pc-debug" object, I think I'll try that one as well...
I think I already know the answer to this next question. But when I use string("this is a string"), does it automatically append a 0 to the end of the string. I assume it does, but if it didn't, it would certainly explain the ability to tx a byte, but not a string.
I'll have a fresh start on the problem today after work.
I've been working on the hardware aspect so long, I haven't had alot of extra time to play with code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade
"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
ser.str(string("Test String",13,10))
sends a Test String followed by a CR,LF (carriage Return and Line Feed)
Ran the test to a laptop using a USB to serial adapter - all fine
note my mode though !!! i.e. the '2' in line 1
also just posted another reply noting to ensure to check
_xinfreq = 5_000_000
check it just in case..
http://forums.parallax.com/forums/default.aspx?f=25&m=166079
OBJ
DELAY : "Timing"
did you change this ?
The last line of my code is a ser.stop. This line was right after the ser.str command that sent my text string. I surmise that it was stopping the cog before it finished sending the string. It was a coincidence that it failed on the word "string" nothing more. I may have thought I saw symptoms the I didn't.
When I put a wait before the ser.stop call, it finishes the string before the cog is stopped, and problem solved.
Thank you all for you help.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade
"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
that are async (including starting a new cog, and methods like the full duplex send) and people need to
be aware of the async nature so they don't mess things up.
Do others omit the stop command? It of course is not necessary, but good practice.
If you start it, stop it. If you open it, close it... My wife even taught me to put the seat of the toilet down
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Brian Meade
"They who dream by day are cognizant of many things which escape those who dream only by night" - Edgar Poe
I see no reason to stop it. When I use serial data, it's typically a continual process of monitorin values or interacting with some device. The only time I might consider it is if I am running on battery and require the power savings. I don't want to wait the time it takes to re-load a cog simple to send another byte or 2 of data.
So, my question would be the oppposite, why stop it under normal use?
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·
http://www.parallax.com/dl/docs/prod/prop/NVSA-2006-05.zip
I believe the problem of not outputting all the data showed up when I lowered the baud rate; either set it to 9600 or 115200
I think the reason most people have not experienced this is that most programs are running a loop and are outputting·serial data and there was not a need to stop the serial data output.
Usually when I write a 'linear' program that does something, output serial data or whatever, and stops,·I just put a repeat at the bottom of the code. I guess it all depends on what your doing.
Congratulations on sticking with it and finding your problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike
Post Edited (Mike Cook) : 1/19/2007 12:36:29 AM GMT
interacts with the user or devices or whatnot.
On power savings, I'm thinking of making my SD card routines sleep in their poll loop to
make the idle cog (that just spins on a memory location waiting for a command) take something
like 1% of the running current. This will introduce a small latency, but it will be a small fraction
of the total latency for a block operation anyway.